Lập trình viên và những bài học xương máu
Là lập trình viên với hơn 20 năm kinh nghiệm trong ngành, tôi đã đúc rút ra 22 nguyên tắc sau đây cho bản thân, nhằm: Tiết kiệm thời gian và công sức, tránh những sai lầm không đáng. Hợp tác với đồng nghiệp hiệu quả hơn. Phát triển bản thân và sự nghiệp. Hi vọng những nguyên tắc này cũng ...
Là lập trình viên với hơn 20 năm kinh nghiệm trong ngành, tôi đã đúc rút ra 22 nguyên tắc sau đây cho bản thân, nhằm:
- Tiết kiệm thời gian và công sức, tránh những sai lầm không đáng.
- Hợp tác với đồng nghiệp hiệu quả hơn.
- Phát triển bản thân và sự nghiệp.
Hi vọng những nguyên tắc này cũng sẽ giúp ích cho bạn.
You can read the English version here.
Tham khảo việc làm Developer chất tại ITviec
I. NGUYÊN TẮC PHÁT TRIỂN SẢN PHẨM
Đi từng bước nhỏ rồi phát triển dần lên – một trong những nguyên tắc quan trọng nhất trong phát triển phần mềm.
1. Đi từng bước nhỏ, rồi phát triển dần lên.
Dù là xây dựng hệ thống mới, hay là gắn tính năng mới vào hệ thống sẵn có, thì tôi luôn bắt đầu bằng việc tạo ra một phiên bản vô cùng đơn giản. Phiên bản này sẽ hầu như không có tính năng nào cả.
Sau đó, tôi mới mở rộng dần giải pháp, từng chút từng chút một, cho tới khi đạt được như mong muốn.
2. Mỗi lần chỉ thay đổi một thứ.
Nói chung, khi test thất bại, hoặc khi một tính năng bị trục trặc, thì việc tìm nguyên nhân gây ra bug sẽ dễ dàng hơn nhiều nếu như bạn chỉ thay đổi duy nhất một thứ.
Nguyên tắc này cũng áp dụng được cho cả việc commit code.
3. Sớm thêm phần logging và xử lý lỗi.
Khi phát triển một hệ thống, một trong những việc đầu tiên tôi làm là thêm vào phần logging và xử lý lỗi. Bởi vì chúng rất hữu ích, ngay cả ở giai đoạn đầu.
Cũng tương tự với xử lý lỗi.
4. Mọi dòng code viết mới đều phải được test ít nhất một lần.
Trước khi một tính năng được coi là hoàn tất, nó buộc phải được test trước đã. Nếu không test, làm sao bạn biết chắc nó sẽ hoạt động như mong muốn?
Dĩ nhiên, chọn trúng điều kiện để kiểm thử không phải là dễ. Nhưng may là chúng ta có thể dùng vài mẹo.
Nhờ vậy, bạn có thể chắc chắn rằng code sẽ chạy đúng như mong muốn.
Thi thoảng, tôi bắt được những bugs, mà nhờ đó, lần ra được những dòng code đáng lý không bao giờ được phép viết/chạy bởi một lập trình viên. Có thể lúc review thì trông có vẻ ổn, song rốt cuộc nó không chạy.
Cho nên, nếu nghiêm khắc tuân theo nguyên tắc “luôn luôn kiểm thử mọi dòng code mới ít nhất một lần”, bạn sẽ tránh được vô khối tình huống bẽ mặt.
5. Test từng phần trước khi test toàn bộ.
Test kĩ từng phần sẽ giúp lập trình viên tiết kiệm được rất nhiều thời gian.
Bởi vì, thông thường vấn đề phát sinh khi tích hợp các phần khác nhau lại.
Nếu bạn có thể yên tâm rằng từng phần nhỏ đều hoạt động đúng như ý muốn, thì khi tích hợp hệ thống sẽ dễ tìm lỗi hơn nhiều.
6. Mọi thứ ngốn thời gian nhiều hơn bạn tưởng.
Đặc biệt là trong nghề lập trình.
Ước tính thời gian cần thiết để hoàn thành một tính năng và bảo đảm nó chạy ổn vốn đã chẳng dễ dàng gì. Huống chi, trong phát triển phần mềm, vấn đề phát sinh ngoài dự liệu lại rất phổ biến.
Bởi vậy, tôi rất tâm đắc với định luật Hofstadter: mọi thứ luôn tốn thời gian hơn bạn nghĩ, kể cả khi bạn áp dụng định luật Hofstadter.
7. Hãy hiểu phần code hiện có trước đã.
Hầu hết công việc lập trình đều đòi hỏi phải thay đổi code hiện có, theo cách này hoặc cách khác.
Mà nếu bạn phát triển tính năng mới đi chăng nữa, thì nó cũng cần phải tương thích với một chương trình đã có sẵn.
Điều này có nghĩa là, đọc code cũng quan trọng và cần thiết ngang với viết code.
8. Hãy đọc và chạy thử code.
May thay, có hai phương pháp bổ trợ lẫn nhau cực kì hiệu quả để hiểu code: đọc code và chạy thử code.
Hãy chắc chắn rằng bạn dùng cả hai phương pháp này.
II. NGUYÊN TẮC TÌM VÀ SỬA BUG
Sửa những bug đã biết trước, rồi hãy xem những phần còn lại.
9. Sẽ luôn có bug.
Tôi không thích cách tiếp cận việc phát triển phần mềm theo kiểu “phải đúng ngay từ bước đầu tiên”.
Nói thật, dù lập trình viên có đổ bao nhiêu công sức ra đi chăng nữa, thì vẫn sẽ luôn luôn có bugs. (Định nghĩa bugs: những vấn đề xảy ra ngoài dự liệu).
Thế nên, theo tôi, tốt hơn hết, hãy:
- Chấp nhận sự thật đắng cay đó.
- Chuẩn bị sẵn một hệ thống, để giúp bạn nhanh chóng tìm, sửa lỗi, và triển khai phần đã sửa.
10. Hãy giải quyết các báo cáo bug.
Mọi lập trình viên đều nên dành một phần thời gian để xem báo cáo bugs của khách hàng, và để sửa lỗi.
Việc này sẽ giúp bạn hiểu rõ hơn:
- Những gì khách hàng đang cố gắng thực hiện.
- Hệ thống được dùng như thế nào.
- Khả năng phát hiện vấn đề khó/dễ ra sao.
- Hệ thống được thiết kế tốt đến đâu.
Đây cũng là cách tuyệt vời để chịu trách nhiệm cho những gì bạn phát triển.
Đừng dại dột bỏ lỡ những lợi ích này.
11. Tái hiện lại bug.
Để fix bug thì bước đầu tiên là phải tái hiện lại được bug. Nhờ đó, lập trình viên có thể yên tâm rằng, một khi bug đã được fix thì vấn đề cũng sẽ thực sự được giải quyết.
Nguyên tắc cơ bản này giúp bảo đảm rằng:
- Bạn không đoán mò, đoán nhầm một vấn đề nào đó là bug, trong khi thực ra không phải thế.
- Giải pháp thực sự hiệu quả như bạn nghĩ.
12. Sửa những bug đã biết trước, rồi hãy xem những phần còn lại.
Đôi khi, có hàng loạt vấn đề xuất hiện ngoài dự đoán. Những bug khó nhằn có thể “cấu kết” với nhau và gây nên nhiều chuyện kì quái.
13. Đừng tin vào trùng hợp ngẫu nhiên.
Khi test và tìm lỗi, đừng bao giờ tin vào trùng hợp ngẫu nhiên.
14. Liên kết với timestamp.
Khi tìm lỗi, hãy dùng timestamp của các sự kiện để trợ giúp. Hãy để ý thậm chí cả những sự tăng trưởng.
III. NGUYÊN TẮC ĐỂ HỢP TÁC VỚI LẬP TRÌNH VIÊN KHÁC
Hãy công nhận sự đóng góp của người khác đúng lúc.
15. Nói chuyện trực tiếp là tốt nhất.
Nếu cần thảo luận về một vấn đề, theo tôi, nói chuyện trực tiếp thì tốt hơn là dùng video, call, chat, hay email.
Cá nhân tôi vẫn thường kinh ngạc trước việc các giải pháp trở nên tuyệt vời như thế nào – nhờ thảo luận trực tiếp với đồng nghiệp.
16. Rubber ducking.
Rubber Ducking là một phương pháp tìm bug trong phát triển phần mềm, bắt nguồn từ câu chuyện trong cuốn sách The Pragmatic Programmer.
Theo đó, để tìm bug của chương trình, lập trình viên sẽ tìm cách để giải thích từng dòng code cho một chú vịt bằng cao su.
Nguyên tắc này đơn giản chỉ là, bất cứ khi nào “ăn bí”, bạn hãy gặp một đồng nghiệp và cố giải thích vấn đề đang gặp phải cho họ hiểu.
Nghe thì có vẻ huyền bí, song chiêu này lại thường hiệu quả bất ngờ.
17. Hãy hỏi.
Để tìm hiểu code cũng như cách nó hoạt động, thì đọc và chạy thử code là hai phương pháp rất thú vị.
Tuy nhiên, nếu có cơ hội để hỏi một ai đó hiểu biết hơn (tác giả của chính đoạn code chẳng hạn), thì hãy dùng cả phương án này nữa.
18. Công nhận sự đóng góp của người khác.
Hãy đảm bảo là sự đóng góp của mọi người được ghi nhận đúng lúc.
Khi ghi nhận sự đóng góp của một ai đó, cách tốt nhất là hãy nêu đích danh họ, và hãy gạt bản thân bạn sang một bên.
IV. NGUYÊN TẮC ĐỂ PHÁT TRIỂN BẢN THÂN
Hãy dám thay đổi.
19. Hãy thử.
Nếu chưa chắc chắn về cách thức hoạt động của một tính năng ABC nào đó, sao bạn không viết một chương trình nhỏ để chạy thử xem sao?
Cũng tương tự khi test hệ thống mà bạn đang phát triển.
Và, thường thì click chỗ nọ chỗ kia một tí sẽ giúp khui ra hàng tá bug. Ngoài ra, nó cũng sẽ giúp bạn hiểu sâu hơn về cách hệ thống vận hành.
20. Đừng vội ra quyết định.
Nếu đang phải giải quyết một vấn đề khó, đừng vội ra quyết định ngay lập tức. Hãy tạm gác nó qua ngày hôm sau.
Tiềm thức của bạn vẫn sẽ làm việc ngay cả khi bạn không chủ động suy nghĩ về vấn đề đó. Và kết quả là, sau một đêm ngon giấc, giải pháp sẽ hiện ra rõ ràng, cụ thể hơn nhiều.
21. Hãy dám thay đổi.
Đừng e sợ sự thay đổi, dù là vai trò, vị trí, hay công việc.
Được làm việc với những con người khác nhau, trên những sản phẩm khác nhau, trong những công ty khác nhau là những trải nghiệm rất thú vị và phấn khích.
22. Hãy không ngừng học hỏi.
Một trong những điều tuyệt vời nhất của phát triển phần mềm là luôn có không gian để học hỏi và hiểu biết nhiều hơn.
- Hãy thử những ngôn ngữ lập trình cũng như công cụ khác nhau.
- Hãy đọc sách về phát triển phần mềm, tham gia các khóa học online MOOC.
Những bước tiến nhỏ này, một lúc nào đó, sớm thôi, sẽ tạo nên những thay đổi đột phá trong khả năng cũng như hiểu biết của bạn.
