Programming by Coincidence — Đừng để may mắn quyết định chất lượng code (Pragmatic Programmer #38)

Chào mấy bạn, lại là mình đây — Phong đây! Cuốn "The Pragmatic Programmer" (20th Anniversary Edition) đang dần trở thành cuốn sách mình đọc chậm nhất từ trước tới giờ, nhưng mỗi lần gấp sách lại mình đều thấy thấm thía thêm một điều gì đó. Hôm nay tụi mình sẽ nói về một cái bẫy tâm lý mà hầu như lập trình viên nào cũng từng mắc phải, dù ít dù nhiều: Programming by Coincidence — Lập trình dựa vào sự tình cờ.

Ảnh: luis gomes — Pexels

Programming by Coincidence — Lập trình nhờ… may mắn?

Cuốn sách mở đầu chương này bằng một hình ảnh rất ấn tượng: một người lính già đi qua bãi mìn, thử từng bước một. Anh ta chọc lưỡi lê xuống đất, không thấy nổ, lại chọc tiếp, vẫn không thấy nổ. Cứ thế, anh ta bắt đầu tự tin hơn, bước nhanh hơn. Và rồi… ĐOÀNG!.

Cái kết là anh ta nổ tung vì tưởng bãi an toàn, nhưng thực ra chỉ là do mấy bước trước đó anh ta chưa giẫm trúng mìn thôi.

Chính xác đó là cảm giác của Programming by Coincidence.

Bạn viết một đoạn code, chạy thử, nó chạy được. Bạn không chắc tại sao nó chạy được, nhưng nó chạy, thế là bạn move on. Vài ngày sau, một bug xuất hiện ở đúng chỗ đó, và bạn chẳng biết sửa từ đâu.

Hay một ví dụ kinh điển khác: bạn thêm linh tinh một dòng log ở cuối function, bug tự dưng hết, bỏ dòng log đó ra, bug lại quay về. Bạn không hiểu tại sao, nhưng 10 giờ tối rồi, đói meo, chỉ muốn commit cái pull lên về ngủ. Thế là dòng log vô nghĩa ở nguyên đó, được ship lên production, và không biết bao nhiêu tháng sau ai đó mới phát hiện ra nó chẳng liên quan gì đến bug.

Đó là lập trình bằng sự tình cờ — và nó nguy hiểm hơn bạn nghĩ rất nhiều.

Ảnh: Markus Spiske — Pexels

Cảm nhận của mình

Mình thú thật là có một thời gian dài mình cũng "lập trình bằng tình cờ" khá nhiều, nhất là hồi mới bắt đầu. Hồi đó mình code PHP thuần, gặp bug thì thử vài cách, thấy cách nào chạy được là xong, không cần hiểu tại sao. Viết xong function, test thấy nó trả ra đúng kết quả là thôi, chẳng thèm viết unit test, chẳng thèm đọc lại code.

Bạn biết hậu quả là gì không? Mấy tháng sau, quay lại project, mình nhìn code của chính mình mà không hiểu nó đang làm cái quái gì. "Sao chỗ này lại check điều kiện kiểu này?" "Sao lại gọi API ở chỗ này?" — toàn là những câu hỏi không lời giải, bởi vì lúc viết mình cũng chỉ đang thử, và nó "tình cờ" chạy.

Thực ra, Programming by Coincidence cũng chỉ là triệu chứng của một vấn đề sâu hơn: chúng ta KHÔNG BIẾT code của mình đang làm gì. Và cái nguy hiểm là, code chạy được một lần không có nghĩa là nó đúng. Nó chỉ có nghĩa là nó chưa kịp sai — giống như người lính kia chưa kịp dẫm trúng mìn vậy.

Cuốn sách cũng đưa ra một số dấu hiệu nhận biết bạn đang "programming by coincidence":

• Bạn luôn luôn thử code xong mới hiểu nó hoạt động như thế nào (thay vì hiểu trước rồi mới viết).
• Bạn thấy "à, thêm cái này cũng không sao, lỡ không cần thì xóa sau" — và rồi nó ở đó mãi mãi.
• Bạn hoảng loạn khi phải giải thích code của mình cho người khác — bởi vì tự bạn cũng không hiểu hết.

Nếu bạn thấy mình trong đó, đừng lo — mình cũng vậy mà. Cái quan trọng là làm sao để thoát ra.

Ảnh: Luca Bravo — Pexels

Kết

Topic này nhắc nhở mình rằng: hãy lập trình một cách có chủ đích (program deliberately). Trước khi viết code, hãy dành 30 giây suy nghĩ: "Mình muốn code này làm gì? Nó sẽ làm điều đó như thế nào?" Thay vì thử đủ mọi cách rồi giữ lại cái chạy được, hãy đọc document, hiểu API, viết test trước.

Một tip nhỏ từ cuốn sách: hãy luôn tỉnh táo về những gì bạn không biết. Trong lập trình, biết rõ giới hạn của mình còn an toàn hơn là tưởng mình biết hết nhưng thực ra đang đứng trong bãi mìn.

Hẹn các bạn ở topic sau nha! 🚀