7 Thói quen của một lập trình viên thành công

Để chuẩn bị cho một buổi phỏng vấn, các kỹ sư phần mềm thường dành nhiều thời gian tập code trên leetcode (https://leetcode.com/) và tút tát lại CV.

Và rồi sau khi nhận được một công việc hấp dẫn, họ mới nhận ra những kỹ năng hiện có lại chưa phù hợp với những gì hằng ngày mình đương đầu.

Làm thế nào để rèn luyện và nâng cao những kỹ năng cần thiết luôn là chủ đề lập trình viên quan tâm. Hãy cùng Gambaru tìm hiểu:

7 Thói quen của lập trình viên thành công

1. Học cách đọc code người khác viết

Cho dù code được viết bởi một dev làm trước bạn hay thậm chí là do bạn viết một năm trước có lộn xộn thế nào, bạn vẫn cần phải học cách hiểu được nó.

Kỹ năng này mang đến nhiều lợi ích.

Thứ nhất, có thể đọc được code người khác viết là cơ hội tuyệt vời để hiểu về cách code, những gì nên và không nên khi code.

Quan trọng hơn, bạn biết thêm rằng loại code nào thì dễ dàng cho dev hiểu và kế thừa sử dụng.

Có thể đọc được những đoạn code lộn xộn người khác viết cũng giúp bạn dễ dàng cập nhật khi cần, đôi khi là cập nhật những đoạn code bạn có ít kinh nghiệm.

Tôi đã từng đọc một script từ Powershell sang Python sang Perl.

Dù có kinh nghiệm hạn chế về Perl, nhưng tôi vẫn có đủ nền tảng để hiểu những gì đang diễn ra và thực hiện các thay đổi cần thiết.

Điều này xuất phát từ việc có độ am hiểu về tất cả các code cũng như có thể đọc được các Perl script.

2. Độ nhạy đối với các dự án tệ

Có nhiều kỹ năng cần mất nhiều thời gian để học nhưng xứng đáng. Một trong những kỹ năng đó là hiểu những dự án nào không đáng làm và chỉ đi vào ngõ cụt.

Một số dự án có thể chẳng có giá trị kinh doanh nào và được quản lý rất kém. Điều này không có nghĩa là bạn nên từ bỏ ngay khi cảm thấy không đồng tình với nó.

Tuy nhiên, nếu các bên liên quan không thể giải thích chính xác những gì họ sẽ làm với kết quả cuối cùng, thì có lẽ dự án đấy không đáng tham gia.

Ngoài ra, một số dự án có thể tập trung vào công nghệ thay vì giải pháp đến mức có thể rõ ràng ngay từ đầu rằng dự án đấy không mang được nhiều tác động.

Kỹ năng này đòi hỏi phải thực hiện rất nhiều dự án tệ trước khi bạn nhận ra được ngay một dự án có ổn hay không. Tại một số thời điểm trong sự nghiệp của mình, tự khắc bạn sẽ có dự cảm đúng.

3. Tránh các cuộc họp không cần thiết

Dù bạn là software engineer hay data scientist, các cuộc họp là cần thiết bởi ta cần phải thống nhất quan điểm với PM, end-user và client của mình. Tuy nhiên, cũng có lúc những cuộc họp không cần thiết chiếm lấy toàn bộ lịch trình trong ngày.

Mục tiêu ở đây là đảm bảo bạn dành thời gian cho các cuộc họp quan trọng, thúc đẩy được quyết định và giúp team phát triển.

Phương pháp phổ biến nhất là sắp xếp hai giờ mỗi ngày cho việc họp hành.

Thông thường, hầu hết mọi người sẽ có một cuộc họp định kỳ tại thời điểm họ thấy có lợi và dùng thời gian đó để nắm được tiến độ công việc.

Một cách khác là đi làm sớm. Điều này hữu ích với tôi vì lúc đó văn phòng yên tĩnh hơn, ít ai làm phiền mình.

Quản lý thời gian tốt là rất quan trọng đối với dev vì công việc đòi hỏi họ những lúc phải tập trung và không nói chuyện với người khác.

Vào thời điểm đang tập trung, có rất nhiều ý tưởng phức tạp trong đầu và nếu liên tục dừng lại, có thể rất khó để để họ nối lại dòng suy nghĩ trước đó.

4. Sử dụng Git

Đối với kỹ sư phần mềm, Git chứa các lệnh và quy trình phức tạp. Không ai chắc chắn 100% những gì mình đang làm (lý do tại sao cheat sheet lại phổ biến).

Cho dù công ty của bạn sử dụng hệ thống lưu trữ nào, sử dụng Git sẽ hữu ích nếu dùng đúng cách và gây trở ngại nếu ngược lại.

Push và commit sai, bạn phải dành hàng giờ cố mà gỡ rối nhiều branch chồng chéo. Ngoài ra, nếu liên tục quên pull bản repo mới nhất, bạn sẽ phải xử lý các merge conflict chẳng vui chút nào.

Hãy làm cuộc sống dễ thở hơn bằng việc giữ một bản Git command cheat sheet chẳng hạn.

5. Viết code đơn giản, dễ maintain

Các dev trẻ tuổi hay có xu hướng cố thực hiện tất thảy điều mình biết vào một giải pháp, áp dụng hiểu biết về lập trình hướng đối tượng, cấu trúc dữ liệu, design pattern và công nghệ mới vào mọi code họ viết ra.

Thực tế, điều này tạo ra một sự phức tạp không cần thiết bởi vì nó rất dễ bị gắn quá nhiều vào một giải pháp hoặc design pattern bạn đã từng sử dụng.

Có một sự cân bằng giữa các khái niệm design phức tạp và code đơn giản.

Các design pattern và object-oriented design được cho là để đơn giản hóa code trong bức tranh tổng thể. Quá trình càng được trừu tượng hóa (abstracted), đóng gói (encapsulated) và black-box, thì càng khó để debug.

6. Học cách từ chối và ưu tiên

Kỹ năng này thực sự phù hợp với bất kỳ vai trò nào, dù bạn là nhà phân tích tài chính hay kỹ sư phần mềm.

Ưu tiên và từ chối có thể là hai kỹ năng khác nhau, nhưng chúng có mối liên hệ chặt chẽ.

Ưu tiên có nghĩa là bạn chỉ dành thời gian tạo ra tác động lớn cho công ty. Từ chối đôi khi chỉ có nghĩa là tránh nhận việc nên được xử lý bởi một team khác.

Chúng thường xảy ra song song cho tất cả các vai trò.

Đây có thể là một kỹ năng khó đạt được vì ai trong chúng ta cũng thường có mong muốn hoàn thành mọi yêu cầu được đặt cho mình.

Đặc biệt là nếu vừa tốt nghiệp đại học, bạn sẽ muốn tránh làm người khác thất vọng.

7. Tư duy thiết kế vận hành

Một kỹ năng khó để kiểm tra khi phỏng vấn và khó có thể học theo khi học đại học là suy nghĩ về cách end-user có thể sử dụng phần mềm của bạn không chính xác.

Tôi gọi đó là suy nghĩ thấu đáo về các kịch bản vận hành. Tuy nhiên, đây chỉ là một cách lịch sự để nói rằng bạn phải cố gắng viết code sao cho dễ hiểu và sử dụng nhất thôi.

Ví dụ, vì phần lớn việc lập trình là maintain nên ta thường phải thay đổi code bị rối bằng code khác.

Ngay cả một thay đổi đơn giản cũng yêu cầu truy tìm mọi tham chiếu có thể có của một object, method, và/hoặc API.

Nếu không, ta có thể dễ dàng vô tình break các mô-đun được đính kèm mà không nhận ra, ngay cả khi chỉ thay đổi một loại dữ liệu trong database.

Nó cũng bao gồm nghĩ thấu đáo về các các edge case và toàn bộ thiết kế cấp cao trước khi lập trình.

Đối với các trường hợp phức tạp hơn khi đang phát triển các mô-đun hoặc microservice mới, điều quan trọng là phải dành thời gian nghĩ về các kịch bản vận hành của những gì đang xây dựng.

Hãy hình dung cách người dùng trong tương lai có thể cần sử dụng mô-đun mới, cách họ có thể sử dụng nó không chính xác, những tham số nào có thể cần thiết và những cách khác nhau một dev có thể cần code của bạn trong tương lai.

Rất dễ tạo ra phần mềm hoạt động tốt trên máy tính của bạn, nhưng có rất nhiều cách code có thể bị triển khai sai.

Ở quá trình production, bạn khó có thể nói code sẽ được sử dụng như thế nào và code nào khác sẽ được gắn vào code gốc của bạn.

Năm năm kể từ bây giờ, một dev có thể cảm thấy khó chịu về những hạn chế bởi code bạn viết ra.

Theo SeattleDataGuy