🧹 Software Entropy — Tại sao "cửa sổ vỡ" lại nguy hiểm?

Mở đầu

Mấy bạn ơi, mình tiếp tục series cảm nhận về cuốn "The Pragmatic Programmer" — cuốn sách mà lập trình viên nào cũng nên đọc ít nhất một lần trong đời. Hôm nay mình sẽ nói về Topic 3: Software Entropy (suy thoái phần mềm), một chủ đề mà mình nghĩ bất kỳ ai từng làm việc trong một dự án code lâu năm đều sẽ "gật gù" ngay lập tức.

Ảnh: Lukas Blazek — Pexels

Software Entropy — "Cửa sổ vỡ" trong code

Chắc mấy bạn đã từng nghe đến Broken Window Theory (lý thuyết cửa sổ vỡ) phải không? Gốc của nó là từ ngành tội phạm học: một tòa nhà có vài cửa sổ vỡ mà không được sửa, chẳng mấy chốc sẽ có thêm nhiều cửa sổ khác bị đập vỡ, và dần dần cả khu phố sẽ đi xuống. Điều này cũng hoàn toàn đúng với phần mềm.

Software Entropy là một khái niệm mượn từ vật lý — entropy là thước đo độ hỗn loạn trong một hệ thống. Và trong phần mềm, entropy luôn tăng dần theo thời gian nếu chúng ta không chủ động chống lại nó. Code mới hôm qua còn sạch sẽ, hôm nay đã thấy lộn xộn, và ngày mai thì... thôi khỏi nói.

Hai tác giả Hunt & Thomas đưa ra lời khuyên cực kỳ thực tế: đừng bao giờ để "cửa sổ vỡ" tồn tại trong code của bạn. Một đoạn code xấu, một design tệ, một bug để qua ngày — tất cả đều là những "cửa sổ vỡ". Cứ để càng lâu, nó càng khuyến khích người khác làm bậy thêm.

Ảnh: Dries Augustyns — Pexels

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

Mình từng tham gia một dự án mà hồi đầu ai cũng hăng hái giữ code sạch sẽ. Nhưng rồi sếp thuyết trình "deadline gấp quá — fix tạm đi sau refactor sau". Thế là một cái "patch tạm" xuất hiện. Rồi hai, rồi ba... Chưa đầy 2 tháng, codebase biến thành một mớ spaghetti mà ai mở vào cũng muốn drop luôn.

Đây không phải là chuyện về kỹ thuật — mà là chuyện về văn hóa team. Khi mọi người thấy code xấu tồn tại mà không ai fix, họ tự nhiên nghĩ "à, ở đây nó thế, mình cũng xàm xàm tí cũng chẳng sao". Đó chính là cái bẫy nguy hiểm nhất của software entropy: nó lây lan như một thái độ, chứ không chỉ là một đoạn code.

Cái mình thích nhất ở topic này là tác giả không bảo bạn phải sửa tất cả mọi thứ ngay lập tức. Có những lúc bạn không đủ thời gian để fix hoàn toàn một cái "cửa sổ vỡ" — nhưng ít nhất hãy "lấy tấm ván bịt tạm lại": comment rõ ràng, chặn cái bug đó lại, báo cho team biết, tạo ticket trên backlog. Hành động nhỏ đó đã đủ để gửi tín hiệu: "Tao biết cái này hỏng, tao không chấp nhận nó, và tao sẽ quay lại sửa."

Ảnh: Christina Morillo — Pexels

Kết

Software Entropy là một topic nhỏ nhưng ầm ĩ không kém trong Pragmatic Programmer. Nó nhắc mình rằng: code không chỉ là tập hợp các dòng lệnh — nó là một hệ sinh thái. Nếu không chăm sóc, nó sẽ mục ruỗng từ bên trong, dù bên ngoài có vẫn chạy "ngon lành".

Lời khuyên: hôm nay, hãy kiếm một "cửa sổ vỡ" trong codebase của bạn và sửa nó. Một cái tên biến xấu, một function quá dài, thiếu unit test chỗ nào, hoặc đơn giản là xóa mấy dòng comment vô dụng. Hành động nhỏ, nhưng có sức lan tỏa hơn bạn nghĩ đấy.

Hẹn mấy bạn ở bài sau với một topic thú vị tiếp theo nha! 📚