Dead Programs Tell No Lies

Mở đầu

Ảnh: cottonbro studio — Pexels

Mấy bạn ơi, series cảm nhận về cuốn The Pragmatic Programmer của mình đang tiếp tục nè. Mình đang đọc đến chương 4 Pragmatic Paranoia (tạm dịch là "Lập trình viên hoang tưởng một cách thực tế"). Chương này nói về việc phải luôn nghi ngờ, kiểm tra mọi thứ, vì phần mềm thì phức tạp lắm, lỗi có thể xảy ra bất cứ lúc nào. Mình thấy cuốn sách này hay thật, đọc xong là thấy mình trưởng thành hơn trong cách nghĩ về code. Hôm nay mình nói về topic 24: Dead Programs Tell No Lies.

Ảnh: cottonbro studio — Pexels

Ý chính của topic này là: Khi chương trình của bạn phát hiện ra điều gì đó "không thể xảy ra" (như case selector không rơi vào bất kỳ case nào, file không đóng được, network error, hay data bị hỏng), thì đừng cố cứu vãn, đừng ignore lỗi. Hãy để nó crash ngay lập tức.

Tại sao vậy? Vì "chương trình chết thì không nói dối". Nếu bạn tiếp tục chạy dù biết có vấn đề, nó có thể viết data hỏng vào database, gửi lệnh sai cho hardware, hoặc gây ra những lỗi khó debug hơn rất nhiều sau này. Crash sớm giúp bạn phát hiện vấn đề ngay từ gốc rễ (fail fast).

Tác giả đưa ví dụ về Erlang và Elixir, họ có supervisor tree để quản lý crash — khi một process chết, supervisor sẽ restart nó một cách sạch sẽ. Trong các ngôn ngữ khác, nguyên tắc vẫn là: một khi phát hiện impossible condition, chương trình không còn đáng tin cậy nữa, terminate nó đi.

Họ cũng khuyên đừng viết quá nhiều try-catch defensive programming kiểu log rồi raise lại, vì nó làm code rối, che lấp logic chính, và dễ miss exception mới. Thay vào đó, để exception propagate tự nhiên.

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

Ảnh: cottonbro studio — Pexels

Mình đồng ý với topic này lắm. Trong thực tế, mình từng gặp trường hợp code ignore exception "vì chắc không xảy ra", rồi sau đó production bị corrupt data, debug cả tuần mới ra. Đau thật sự. Fail fast giúp mình debug dễ hơn nhiều, vì stack trace chỉ thẳng vào vấn đề.

Nhưng cũng phải cân bằng nha mấy bạn. Trong GUI app hay web service, crash hoàn toàn có thể làm user experience tệ. Lúc đó thì cần graceful degradation hoặc supervisor pattern. Mình thích quote của Joe Armstrong (cha đẻ Erlang): "Defensive programming is a waste of time. Let it crash!" Nghe oai vl.

Topic này kết nối tốt với Assertive Programming và Design by Contract ở các topic trước. Nó làm mình suy nghĩ lại cách handle error trong project hiện tại của mình.

Kết

Tóm lại, dead programs tell no lies — crash sớm, crash clean, đừng để chương trình "bị thương" mà vẫn lết đi gây thêm hại. Rất thực tế và đáng áp dụng.

Bài sau mình sẽ nói tiếp về Assertive Programming nha. Mấy bạn theo dõi series này thì like share ủng hộ mình với. Cảm ơn mấy bạn đã đọc!

Phong