28: Đừng cố gắng rập khuôn chương trình của bạn.

Tôi đã từng viết một bài kiểm tra C++, trong bài kiểm tra đó tôi đề xuất một cách để xử lý ngoại lệ ⚠: Đó là thêm rất nhiều cấu trúc try…catch ở trong toàn bộ codebase. Thi thoảng chúng tôi đã ngăn chặn lỗi trong ứng dụng của chúng tôi. Do đó chúng tôi đã nghĩ về trạng thái kết quả là “rập khuôn” đã nhận được từ những kinh nghiệm rất cay đắng.

Đó là 1 ứng dụng hết sức cơ bản trong thư viện mà chúng tôi tự làm nên, … Nó chứa các đoạn mã để có thể đối phó với tất cả các ngoại lệ ⚠. Và dẫn đầu từ Yossian trong cuốn tiểu thuyết Catch-22. Vì thế chúng tôi quyết định rằng, hay đúng hơn là cảm thấy chúng tôi nên tiếp tục phát triển thư viện này hoặc để nó chết dần chết mòn trong sự cố gắng và nỗ lực.

Đến cuối cùng, chúng tôi đan xen nhiều trình xử lý ngoại lệ ⚠. Chúng tôi đã trộn cấu trúc xử lý ngoại lệ ⚠ của Windows với loại ngôn ngữ khác. (Bạn nhớ cấu trúc try … except trong C++ chứ? , tôi nhớ đấy) . Khi xảy ra ngoại lệ ⚠ một cách không mong muốn, chúng tôi đã cố gắng gọi lại chúng một lần nữa, và cho chúng nhận các tham số khó hơn. Và nhìn lại, chúng tôi thấy khi viết một chuỗi xử lý try … catch trong khối catch của một chuỗi try…catch khác. Một loại nhận thức nào đó len lỏi vào tôi rằng tôi có thể đã vô tình đi từ con đường cao tốc trơn của sự thực hành tốt vào một con đường vô cảm của sự mất trí. Tuy nhiên, đây có lẽ là hồi tưởng khôn ngoan.

Không cần phải nói, bất cứ khi nào có sự cố xảy ra trong ứng dụng mà có sử dụng thư viện của chúng tôi. Những sự cố đó sẽ biến mất như các nạn nhân của mafia ở bến cảng. Không để lại bất cứ một dấu vết nào để dẫn đến những sự kinh khủng kế tiếp xảy ra. Bất chấp các thói quen được cho là thảm họa. Cuối cùng chúng tôi đã lưu lại những gì chúng tôi đã làm, một sự đáng hổ thẹn. Chúng tôi đã thay thế toàn bộ mỡ hỗn độn ở trong thư viện đó bằng một cơ chế thông báo lỗi tốt và mạnh mẽ. Nhưng có rất nhiều tai nạn có thể xảy ra.

Tôi sẽ không làm phiền bạn về điều này — bởi vì tôi biết không ai có thể ngu ngốc như chúng tôi. Nhưng trong một cuộc tranh luận trực tuyến gần đây với một người có chức danh học thuật nên hiển nhiên anh ta biết rõ hơn. Chúng tôi đã thảo luận về đoạn mã Java khi giao dịch từ xa. Và nếu không thành công, anh ta đã lập luận, nên bắt và chặn ngoại lệ ngay tại chỗ. (Và sau đó làm gì với nó? Tôi hỏi: “Nấu cho nó bữa tối?”

Anh ta đã trích nguyên văn nguyên tắc thiết kế giao diện người dùng. KHÔNG BAO GIỜ CHO NGƯỜI DÙNG NHÌN THẤY THÔNG BÁO NGOẠI LỆ ⚠. Thay vì giải quyết vấn đề, liệu chuyện gì sẽ xảy ra khi làm phức tạp mọi thứ. Tôi tự hỏi liệu anh ta có chịu trách nhiệm về mã ở một trong những máy ATM bị màn hình xanh ở trong những bức ảnh được đăng trên blog không, và có thể chúng đã bị hỏng vĩnh viễn. Dù sao thì khi gặp anh ta bạn nên cúi đầu cười, giống như đi về phía cửa.

Chú thích:
Catch-22 là một cụm từ chỉ một hoàn cảnh, tình huống khó xử mà người ta không thể thoát ra được vì bị mắc kẹt bởi những logic và ràng buộc mâu thuẫn nội tại. Từ này bắt nguồn từ tên cuốn tiểu thuyết Catch-22 (1961) của Joseph Heller kể về một anh chàng phi công tên là Yossarian. Yossarian là phi công lái máy bay chiến đấu cho quân đội Ý trong Thế Chiến II. Do lo sợ, Yossarian đã cố tìm cách không phải bay bằng cách tuyên bố mình bị điên. Tuy nhiên, người ta lại bảo anh ta rằng, chỉ có người điên mới muốn bay lúc đó, vì anh ta không muốn bay nên điều đó chứng tỏ anh ta không bị điên, và vì anh ta không bị điên nên anh ta phải tiếp tục bay!