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.
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.
- Tôi thường không lên kế hoạch tỉ mỉ cho tất cả mọi thứ ngay từ bước ban đầu. Trái lại, tôi sẽ vừa làm vừa quan sát và rút kinh nghiệm.
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ứ.
- Hay nói cách khác, hãy dùng các vòng lặp (iteration) ngắn. Chọn tác động lên chỉ một thứ thôi. Bảo đảm là nó hoạt động như ý đã, rồi hãy tác động lên cái tiếp theo.
- Nguyên tắc này cũng áp dụng được cho cả việc commit code.
- Nếu bạn phải refactor code trước khi gắn tính năng mới vào sản phẩm, thì hãy commit phần code đã được refactor trước. Sau đó, (trong một commit mới) hãy gắn cái tính năng mới vào.
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.
- Với mọi hệ thống lớn hơn vài dòng code, lập trình viên đều cần phải chuẩn bị sẵn phương án để biết được chuyện gì đang diễn ra trong chương trình.
- Lúc bình thường, điều này có vẻ không cần thiết.
- Song, chỉ cần chương trình chạy “trật đường rày” chút xíu là bạn sẽ thấy rõ ngay tầm quan trọng của logging.
Cũng tương tự với xử lý lỗi.
- Lỗi và các ngoại lệ (exceptions) cũng thường xuất hiện ngay từ đầu.
- Do đó, bạn cần có cách để xử lý chúng một cách hệ thống càng sớm càng tốt.
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?
- Thông thường thì automated test sẽ là lựa chọn tốt nhất (dù không hẳn lúc nào cũng vậy).
- Song, dù chọn cách nào đi chăng nữa, thì điều quan trọng là mỗi dòng code mới đều buộc phải được test ít nhất một lầ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.
- Ví dụ, để kiểm tra phần xử lý lỗi khi gọi đến cơ sở dữ liệu, lập trình viên có thể giả vờ viết sai tên của một column.
- Hoặc, một câu lệnh if có thể tạm thời được đảo lại (“if error” trở thành “if not error”) để kích hoạt một điều kiện hiếm khi xảy ra.
- 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.
- Ví như interface của các modules không thống nhất/bị hiểu lầm.
- 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.
- Ví dụ, một thao tác merge code trông có vẻ đơn giản, song hoàn toàn có thể gây ra một bug tiềm ẩn.
- Hoặc, nâng cấp một framework cũng đồng nghĩa với việc buộc phải thay đổi một vài chức năng.
- Hay là một API không hoạt động như kì vọng.
- 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.
- Vậy thì, trước khi tích hợp phần mới vào, bạn cần phải hiểu được giải pháp hiện thời đã.
- Nếu không, rất có thể bạn sẽ vô tình làm hỏng, hoặc gây ảnh hưởng đến các tính năng hiện có.
- Đ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.
- Và đây cũng là một trong những nguyên nhân dẫn đến việc, đôi khi thực hiện các thay đổi nhỏ lại ngốn khá nhiều thời gian.
- Bởi vì lập trình viên phải hiểu ngữ cảnh mà bạn đang thực hiện sự thay đổi.
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.
- Chạy thử code là cách rất hữu ích để hiểu được code đó là để làm gì.
- 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.
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.
- Trong tình huống này, thay vì cứ cố tìm hiểu tường tận tất cả mọi chuyện cùng một lúc, thì bạn nên fix những bug đã biết, giải quyết những vấn đề “lộ thiên” trước đã.
- Rồi hãy từ từ kiểm tra xem những phần còn lại như thế nào.
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.
- Bạn thay một giá trị trong bộ định thời (timer value), và giờ hệ thống cứ tự khởi động lại thường xuyên hơn? Chẳng ngẫu nhiên tí nào.
- Một tính năng mới được thêm vào, và một tính năng khác (vốn chẳng liên quan gì) tự dưng chạy chậm hơn? Không ngẫu nhiên đâu. Trái lại, rất đáng ngờ.
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.
- Ví dụ, khi hệ thống khởi động lại, và một yêu cầu được gửi ra khoảng 3000 miliseconds trước đó, thì rất có khả năng là một bộ định thời đã gây ra điều gì đó, dẫn đến việc khởi động lại.
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.
- Rất nhiều khi, trong lúc tìm cách để giảng giải, bạn sẽ nhìn mọi chuyện thấu suốt hơn, và nhận ra khúc mắc nằm ở đâu. Thậm chí, kể cả khi đồng nghiệp của bạn chưa kịp nói lấy một lời.
- 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.
- Hãy hỏi những câu hỏi thật chi tiết, cụ thể. Hãy đào sâu thông tin. Có thể bạn sẽ “moi” được thông tin hữu ích chỉ trong vòng vài phút, thay vì phải bỏ ra vài ngày để cặm cụi tự mò ra.
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.
- Hãy nói: “Marcus đã nghĩ ra ý tưởng để thử ABC…” (nếu anh ấy nghĩ ra); thay vì: “Chúng tôi đã thử…”
- 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
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.
- Chuyện gì sẽ xảy ra nếu tôi điều chỉnh thông số này xuống -1? Chuyện gì sẽ xảy ra nếu dịch vụ bị gián đoạn khi tôi khởi động lại hệ thống?
- 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.
- Theo tôi, có quá nhiều lập trình viên chỉ thụ động làm cùng một công việc từ năm này qua năm khác, và họ chỉ chịu thay đổi khi bị buộc làm vậy.
- Điều đó khiến họ mất đi lợi thế khi thương lượng, đồng thời bó hẹp lựa chọn của họ lại.
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.
BTV.Trần Thị Thu Huyền
Phòng Truyền Thông IMicroSoft Việt Nam
Hotline: 0916 878 224
Email: huyenttt@imicrosoft.edu.vn
Bạn đang muốn tìm kiếm 1 công việc với mức thu nhập cao.
✅ Hoặc là bạn đang muốn chuyển đổi công việc mà chưa biết theo học ngành nghề gì cho tốt.
✅ Giới thiệu với bạn Chương trình đào tạo nhân sự dài hạn trong 12 tháng với những điều đặc biệt mà chỉ có tại IMIC và đây cũng chính là sự lựa chọn phù hợp nhất dành cho bạn:
👉 Thứ nhất: Học viên được đào tạo bài bản kỹ năng, kiến thức chuyên môn lý thuyết, thực hành, thực chiến nhiều dự án và chia sẻ những kinh nghiệm thực tế từ Chuyên gia có nhiều năm kinh nghiệm dự án cũng như tâm huyết truyền nghề.
👉 Thứ hai: Được ký hợp đồng cam kết chất lượng đào tạo cũng như mức lương sau tốt nghiệp và đi làm tại các đối tác tuyển dụng của IMIC. Trả lại học phí nếu không đúng những gì đã ký kết.
👉 Thứ ba: Cam kết hỗ trợ giới thiệu công việc sang đối tác tuyển dụng trong vòng 10 năm liên tục.
👉 Thứ tư: Được hỗ trợ tài chính với mức lãi suất 0 đồng qua ngân hàng VIB Bank.
👉 Có 4 Chương trình đào tạo nhân sự dài hạn dành cho bạn lựa chọn theo học. Gồm có:
1) Data Scientist full-stack
2) Embedded System & IoT development full-stack
3) Game development full-stack
4) Web development full-stack
✅ Cảm ơn bạn đã dành thời gian lắng nghe những chia sẻ của mình. Và tuyệt vời hơn nữa nếu IMIC được góp phần vào sự thành công của bạn.
✅ Hãy liên hệ ngay với Phòng tư vấn tuyển sinh để được hỗ trợ về thủ tục nhập học.
✅ Chúc bạn luôn có nhiều sức khỏe và thành công!