5 kỹ năng mà mọi Developer cần có ngoài việc viết code

Học lập trình thường xoay quanh việc, đương nhiên rồi, lập trình. Khi tôi bắt đầu tiếp cận khoa học máy tính, việc tự viết những chương trình nhỏ từ đầu đã trở thành phương thức chính để tôi củng cố các khái niệm đã học, và cách luyện tập thực hành này đã đóng một vai trò vô cùng quan trọng trong quá trình phát triển các kỹ năng của tôi. Tuy nhiên, chỉ khi tôi bắt đầu công việc lập trình viên thực thụ đầu tiên của mình, tôi mới nhận thấy rằng tôi dành phần lớn thời gian của mình cho các nhiệm vụ chẳng phải viết code, những nhiệm vụ yêu cầu những bộ kỹ năng hoàn toàn khác.

Một cách tự nhiên, các kỹ năng cụ thể cần thiết cho các công việc liên quan đến lập trình khác nhau có thể khác nhau. Người phân tích dữ liệu viết script để xử lý thông tin sẽ không sử dụng thời gian trong ngày của mình giống hệt như một nhân viên dịch vụ kỹ thuật khác làm việc để giải quyết các vấn đề cho khách hàng. Ngay cả hai kỹ sư phần mềm trong cùng một tổ chức cũng có thể có nhiệm vụ hàng ngày hoàn toàn khác nhau.

Tuy nhiên, các kỹ năng được mô tả dưới đây rất quan trọng trong nhiều loại vị trí tương tự như vậy, vì vậy bắt đầu thực hành chúng ngay bây giờ có thể sẽ giúp bạn có lợi thế khi tìm việc và giúp bạn thành công trong sự nghiệp của mình.

Đọc Code của người khác

Cho dù là tìm lỗi hay tìm cách thêm tính năng mới vào phần mềm hiện có, các lập trình viên dành rất nhiều thời gian để đọc mã nguồn của người khác. Đây có thể nghe như là một nhiệm vụ tương đối dễ dàng. Suy cho cùng, viết mã khó hơn đọc mã, phải không?

Không nhất thiết là như vậy. Các ứng dụng phần mềm lớn có thể chứa hàng triệu dòng mã, thường hoạt động theo những cách rất phức tạp hoặc khó hiểu. Đào sâu vào một trong những ứng dụng này và cố gắng hiểu nó có thể khiến bạn cảm thấy cực kỳ áp lực, đặc biệt là nếu các comments và tài liệu kèm theo là không đủ (điều này không phải là điều hiếm gặp). Ngay cả các chương trình nhỏ cũng có thể là một cực hình để đọc qua nếu logic bên trong chúng không rõ ràng, hoặc nếu chúng được viết bởi người trong văn phòng kế bên bạn, người đặt tên cho tất cả các hàm của mình dựa trên các nhân vật trong Game of Thrones nhưng lại là con ông cháu cha của CEO.

Học cách truy xuất mã nguồn và rút ra thông tin liên quan mà không bị rối mắt đòi hỏi thời gian, và đọc qua các đoạn mã nguồn nhỏ chỉ đủ để phát triển những kỹ năng này một phần. May mắn thay, các ứng dụng mã nguồn mở (như những ứng dụng được lưu trữ trên GitHub) cung cấp một nguồn tài nguyên luyện tập tuyệt vời.

Hoàn thành một số sửa chữa nhỏ trên các dự án mã nguồn mở lớn sẽ giúp bạn học cách tiếp cận một cơ sở mã nguồn lớn, đồng thời cung cấp cơ hội để cải thiện phần mềm được sử dụng bởi nhiều người. Hoặc, nếu bạn cảm thấy chưa sẵn sàng để đóng góp, chỉ cố gắng tìm hiểu cách các đoạn mã trong các ứng dụng hoạt động cũng đã là một trải nghiệm học tập tuyệt vời.

Một điểm cộng là, khi bạn cố gắng học hỏi thông quá các ứng dụng mã nguồn mở khác nhau, bạn sẽ nhận ra sự khác biệt giữa mã nguồn tốt và mã nguồn không tốt. Việc viết code dễ đọc sẽ tiết kiệm thời gian và cứu đồng nghiệp của bạn khỏi sự đau đầu, vì vậy học bằng cách xem ví dụ về kiểu mã chính xác và các comment rõ ràng, đầy đủ thông tin sẽ giúp bạn trở nên càng có giá trị hơn với vai trò là một lập trình viên.

Viết các Comments và Documentation rõ ràng

Viết những lời giải thích ngắn gọn nhưng đầy đủ thông tin để mô tả tác dụng những dòng code của bạn làm công việc của đồng nghiệp trở nên dễ dàng hơn đáng kể. Mặc dù các tổ chức khác nhau sẽ có những quy ước riêng về tài liệu và comment cụ thể, tuy nhiên có vài nguyên tắc cơ bản bạn cần ghi nhớ:

Trước hết, khi mô tả mục đích của một đoạn mã mới, hãy đảm bảo giải thích rõ ràng những gì đoạn code này thực hiện được mà code cũ thì không.

Ví dụ, nếu có một hàm hiện có thực hiện công việc x, và bạn viết một hàm mới call hàm hiện có đó và định dạng lại đầu ra, mô tả của bạn về hàm mới này nên đề cập đến việc định dạng lại (tức là chức năng mới được thêm bởi hàm này), thay vì chỉ nói nó thực hiện công việc x (mà nó chỉ có thể thực hiện được bằng cách call hàm hiện có).

Nếu chúng ta không làm như vậy, việc tìm hiểu cách một chương trình hoạt động hoặc nơi để chèn mã sẽ trở nên phức tạp hơn rất nhiều. Tôi từng gặp một chuỗi sáu hàm (hàm đầu tiên call hàm thứ hai, hàm thứ hai call hàm thứ ba, v.v.) mà tất cả đều có cùng kiểu mô tả rất mập mờ, và tôi chắc chắn tôi không phải là người duy nhất mất thời gian quý báu để tìm hiểu thực sự mỗi hàm đó làm gì.

Thứ hai, đối với các inline comment, tập trung nhiều hơn vào "tại sao" hơn là "làm thế nào".

Giải thích mục đích của một non-intuitive line hoặc algorithm có thể làm tăng tốc quá trình đọc, trong khi việc dịch mỗi dòng mã thành tiếng Anh có thể sẽ làm cho việc đọc trở nên chậm chạp.

Cuối cùng, hãy luôn nghĩ đến khán giả của bạn và mục tiêu của họ.

Nếu bạn đang viết tài liệu chính thức về một tính năng mới để khách hàng có thể phê duyệt, đội kiểm thử có thể xác nhận và một nhóm phát triển khác có thể tìm hiểu cách dự án của họ tương tác với nó, bạn nên cung cấp thông tin cụ thể mà mỗi bên cần. Ghi nhớ mục đích của tài liệu sẽ giúp đảm bảo nó đáp ứng được những mục tiêu này.

Bạn có thể thực hành những kỹ năng này trong quá trình làm các bài tập . Thêm các comment vào mã của bạn hoặc viết một số tài liệu đơn giản mô tả những gì dự án của bạn làm trong khi làm. Sau này, khi bạn đã quên đi những chi tiết cụ thể của các bài tập này, hãy đọc lại chúng. Các comment của bạn có làm cho việc hiểu công việc của bạn dễ dàng hơn không? Bạn có thể nhanh chóng hiểu được thông tin về mỗi hàm hoặc class làm gì không? Bạn có thể tìm được cách để kiểm thử mã của mình từ tài liệu không?

Kiểm tra Code của bạn

Công việc của một lập trình viên không chỉ dừng lại ở việc viết code, mà còn bao gồm cả việc kiểm tra và xác nhận rằng code của bạn hoạt động như mong đợi. Ngay cả khi bạn làm việc cho một tổ chức có các nhóm chuyên môn chịu trách nhiệm testing, việc biết cách chạy một số kiểm tra cơ bản có thể ngăn bạn gửi những đoạn Code với những lỗi rõ ràng đến nhóm kiểm thử. Vì việc làm lại để bắt kịp tốc độ của một dự án mất thời gian, điều này sẽ có thể giúp cả bạn và nhóm testing tiết kiệm được hàng tiếng đồng hồ quý giá gửi đi gửi lại cùng một dự án một cách không cần thiết.

Testing có thể có nhiều hình thức khác nhau, từ việc chạy chương trình theo cách thủ công đến việc sử dụng các kịch bản testing đã được viết trước đó. Nó có thể bao gồm unit tests (kiểm tra xem các module hoặc hàm cá nhân có hoạt động hay không), integration tests (kiểm tra xem các module khác nhau hoạt động được cùng nhau không) và system tests (xác định xem hệ thống tổng thể đáp ứng các thông số kỹ thuật hay không).

Dù trong bất kỳ hình thức nào, điều quan trọng là tiếp cận công việc testing một cách có trình tự và kỷ luật, và suy xét qua cả các đầu vào khác nhau và các cách tương tác với chương trình mà chúng ta cần biết. Liệt kê tất cả những gì bạn cần kiểm tra trước khi bắt đầu và tham khảo danh sách này trong quá trình kiểm thử để đảm bảo bạn không quên điều gì. Hơn nữa, hãy đảm bảo bạn kiểm tra các edge cases và thử làm sai . Người dùng có thể mắc sai lầm, vì vậy quá trình kiểm thử của chúng ta cần khám phá cách phần mềm xử lý chúng.

Giao tiếp một cách hiệu quả với Đội nhóm và Khách hàng của bạn

Lập trình thường đòi hỏi giao tiếp với người khác. Khi viết phần mềm cho khách hàng hoặc public, chúng ta cần biết về nhu cầu và sở thích của họ để đảm bảo rằng chương trình của chúng ta sẽ thực sự hữu ích và dễ sử dụng.

Khi làm việc như một phần của một nhóm develop, chúng ta cần đảm bảo rằng tất cả chúng ta đều hiểu nhau về cách chương trình sẽ được cấu trúc, các quy ước chung mà chúng ta sẽ sử dụng, tiến độ và trách nhiệm cá nhân của mỗi người. Khi giúp đỡ người dùng gặp sự cố phần mềm, một người ở vị trí hỗ trợ khách hàng có thể sẽ cần thu thập tất cả thông tin có liên quan về vấn đề từ người dùng và truyền thông tin này cho một developer, người có thể sẽ cần kiểm tra với các thành viên khác của các nhóm khác để xác định tính chất của vấn đề và đảm bảo rằng giải pháp của họ không gây ra vấn đề mới. Nếu quá trình giao tiếp này gặp trục trặc, có thể gây hậu quả nghiêm trọng.

Giao tiếp hiệu quả không chỉ đòi hỏi lắng nghe và nói ra những gì ta đang nghĩ. Nó yêu cầu đặt những câu hỏi sâu để xác nhận rằng chúng ta thực sự đang nói về cùng một vấn đề, và cẩn thận tránh sử dụng thuật ngữ chuyên môn trong ngữ cảnh sai. Một lỗi dễ mắc phải đến mức bất ngờ là việc nói mà đối phương không hiểu gì, đặc biệt nếu chúng ta đang hiểu ở các ngữ cảnh khác nhau.

Tôi đã tham gia một cuộc họp với khách hàng trong đó nhóm của tôi hỏi liệu một mục dữ liệu cụ thể có cần "reportable" hay không, một thuật ngữ mà chúng tôi sử dụng để chỉ các mục hạn chế các giá trị có thể tới một tập xác định. Khách hàng trả lời "có", nghĩ rằng "reportable" chỉ đơn giản là nghĩa là họ có thể truy cập và in bất kỳ giá trị nào được nhập cho mục đó. Nếu chúng tôi không hỏi những câu hỏi để làm rõ vấn đề này, việc sử dụng thuật ngữ chuyên môn có thể dẫn đến việc chúng tôi tạo ra một trường giới hạn tùy chọn trong khi khách hàng muốn một trường nhập dữ liệu tự do.

Giao tiếp không chỉ giới hạn ở việc tìm hiểu những gì chúng ta cần làm và cách chúng ta làm những việc đó. Nó còn bao gồm quản lý kỳ vọng. Nếu một khách hàng nghĩ rằng chúng ta sẽ triển khai một tính năng trí tuệ nhân tạo tiên tiến mà thực tế vượt ngoài khả năng, đó là một vấn đề. Nếu đồng nghiệp của chúng ta nghĩ rằng chúng ta sẽ có phần giao diện sẵn sàng trong tuần này trong khi nó sẽ cần một tháng nữa trong thực tế, đó cũng là một vấn đề.

Quản lý kỳ vọng yêu cầu sự trung thực đối với những vấn đề mà ta không chắc chắn và sự chủ động báo cáo các vấn đề hoặc sự trì hoãn phát sinh không thể đoán trước. Đôi khi, điều này có thể khá khó chịu. Chúng ta có thể sẽ cảm thấy như đang làm các cổ đông thất vọng hay đang chấp nhận sự thất bại. Hoặc, chúng ta đơn giản là không muốn khách hàng hoặc quản lý gào lên mắng nhiếc chúng ta. Những dù có thế nào, lên tiếng thường là hành động tốt nhất. Những vấn đề ẩn phát triển và gặm nhấm, trong khi những vấn đề mà chúng ta biết có thể được giải quyết.

Nếu bạn nhận thấy một deadline là không thực tế, hãy lên tiếng trước khi các bên liên quan lập (thêm) kế hoạch dựa trên kỳ vọng rằng công việc của bạn sẽ được hoàn thành đúng thời hạn. Và nếu bạn cần giúp đỡ, hãy yêu cầu khi vẫn còn thời gian.

Biết khi nào nên nhờ giúp đỡ

"Nhưng khi nào thì chúng ta cần sự giúp đỡ? Chắc chắn, có những tình huống đòi hỏi sự hỗ trợ, một góc nhìn mới, kiến thức chuyên môn hoặc đơn giản là lợi ích từ lời khuyên của ai đó có kinh nghiệm hơn (hoặc khác biệt). Tuy nhiên, việc giải quyết vấn đề là một phần quan trọng của lập trình, và nếu giải pháp mà chúng ta luôn hướng đến là "hỏi ý kiến sếp," cô ấy có thể sẽ tự hỏi liệu chúng ta có đóng góp được gì cho công việc.

Một cách tự nhiên, sự cân bằng hợp lý giữa cố gắng tự giải quyết vấn đề và tìm sự trợ giúp sẽ thay đổi tùy thuộc vào vai trò và tổ chức của bạn, nhưng tuân theo một số nguyên tắc chung có thể làm cho việc tìm được sự cân bằng này dễ dàng hơn:

Đầu tiên, hãy trân trọng thời gian của mọi người, bao gồm cả bạn*.*

Làm ngắt quãng suy nghĩ của đồng nghiệp để hỏi một câu hỏi mà bạn có thể tìm được câu trả lời bằng cách đọc tài liệu liên quan không phải là sự tôn trọng đối với thời gian của họ, nhưng dành hàng giờ tìm kiếm trên các nguồn thông tin không rõ ràng nhằm tìm một câu trả lời cho một câu hỏi cụ thể trong lĩnh vực mà đồng nghiệp của bạn có thể biết lại không phải là sự tôn trọng đối với thời gian của bạn.

Thứ hai, luôn ý thức được sự quan trọng của một vấn đề.

Chúng ta đều mắc sai lầm, vì vậy, khi bạn không chắc chắn về một vấn đề quan trọng cho công việc, việc nhờ ý kiến ​​thứ hai (hoặc thứ ba) là điều khôn ngoan. Nhưng nhờ ý kiến ​​thứ ba về việc bạn nên đặt tên biến là "grades" hay "grade_list"? Không nên chút nào.

Y thức được về lĩnh vực chuyên môn của người khác, cũng như những lĩnh vực không phải là chuyên môn của họ.

Nếu đồng nghiệp của bạn biết về một chủ đề cụ thể nhiều hơn bạn, tìm hiểu ý kiến ​​của họ về một vấn đề liên quan có thể ngăn bạn khỏi mắc phải những sai lầm nghiêm trọng. Tuy nhiên, nếu không có ai trong tổ chức của bạn biết về chủ đề đó nhiều hơn so với bạn, thì yêu cầu họ tìm hiểu điều gì bạn nên làm về một vấn đề liên quan sẽ khiến họ cảm thấy như bạn đang yêu cầu họ làm công việc của bạn.

Cuối cùng, hãy hiểu rõ khả năng và giới hạn của bản thân.

Phát triển một cái nhìn đúng về tốc độ làm việc mà bạn có thể làm trên thực tế sẽ giúp bạn dễ dàng nhận biết xem một deadline gấp có đang tạo ra vấn đề hay không, và biết được loại vấn đề nào mà bạn có thể tự giải quyết sẽ giúp bạn có được cái nhìn rõ ràng hơn về việc bạn đang gặp vấn đề thực sự hay chỉ cần thêm thời gian để làm việc.

Kết luận

Một bộ kỹ năng không thể phù hợp cho tất cả mọi thứ khi nói đến lập trình. Một nhà dịch tễ học sử dụng một đoạn mã để phân tích dữ liệu bệnh nhân có một công việc rất khác biệt so với các nhà phát triển ứng dụng di động mới hoặc kỹ sư phần mềm tại một ngân hàng lớn. Tuy nhiên các kỹ năng trên là khá quan trọng và cần được học hỏi dù cho bạn đang làm việc cho các dự án lớn hay đang luyện tập.

Cre: sontung445

---

Trong thực tế tuyển dụng, sự khác biệt không nằm ở việc bạn biết bao nhiêu kiến thức, mà ở việc bạn đã từng làm việc trong môi trường giống doanh nghiệp đến mức nào. Chính trải nghiệm thực chiến mới là thứ giúp bạn nổi bật. Nếu bạn muốn không chỉ hiểu lý thuyết mà còn được rèn luyện những kỹ năng này trong môi trường làm việc thực tế, Internship OneConnect (IOC) là lựa chọn đáng để bạn bắt đầu ngay từ bây giờ để bứt phá nhanh hơn trên lộ trình sự nghiệp.