Điều đầu tiên phải nói đến là triết lý “không có móc cài” (hook). Đừng cố gắng để lại những điểm mở trong mã nguồn, đừng mơ tưởng rằng tương lai khi vấn đề thay đổi sẽ dễ dàng chèn thêm logic mới. Vì thực tế, vấn đề sẽ biến hóa theo những cách mà bạn không thể lường trước. Khi ấy, những cố gắng phòng xa kia chỉ là sự lãng phí vô ích. Hãy từ bỏ thói quen dự đoán, chỉ tập trung giải quyết những vấn đề đang hiển hiện trước mắt. Đây chính là nguyên tắc vàng mà cha đẻ Forth - Charles Moore đã đúc kết.

Chuyện buồn cười với bà chủ nhà hôm nay thật sự khiến tôi không biết nên khóc hay cười. Sự việc bắt đầu từ tuần trước khi tôi đang bận rộn với công việc, đến nỗi quên đóng vòi nước sau khi phát hiện mất nước vào buổi trưa. Kết quả là nước tràn ngập phòng tắm vì rãnh thoát nước bị nghẹt, khiến nước thấm sang nhà dưới.

Chưa kịp ăn tối, tôi đã nhận được cuộc gọi tức giận từ hàng xóm tầng dưới. Vội vã từ công ty trở về, cảnh tượng trước mắt khiến tôi không khỏi áy náy - trần nhà họ ngập nước như mưa rào, đồ đạc ngổn ngang. Dù thiệt hại thực tế không lớn (nhà họ gần như chưa trang trí gì), tôi vẫn quyết định bồi thường ngay 10 triệu đồng để dẹp yên chuyện. Thật lòng mà nói, con số 3 triệu đã là quá hào phóng rồi, nhưng vì tự nhận mình sai nên tôi sẵn sàng gánh vác hậu quả.

Kỹ thuật nhỏ trong Lua để kiểm tra tiền tố chuỗi
Khi xây dựng bộ gỡ lỗi Lua, mình gặp bài toán kiểm tra xem một chuỗi có bắt đầu bằng ký tự “@” hay không. Có 3 cách tiếp cận thú vị như sau:

1. Dùng string.sub()

1

string.sub(str, 1, 1) == "@"  

Cách này trực quan dễ hiểu, nhưng mỗi lần gọi sẽ tạo ra chuỗi con mới và thực hiện hashing. Trong môi trường xử lý hiệu năng cao, việc này có thể tạo ra độ trễ nhỏ.

Cách đây vài năm, tôi đã từng thử xây dựng một trình gỡ lỗi cho ngôn ngữ Lua và có đăng hình ảnh chụp màn hình lên blog cá nhân. Tuy nhiên, tôi nhanh chóng nhận ra rằng thiết kế giao diện không phải là yếu tố cốt lõi - mà chính giao thức truyền thông giữa các thành phần mới là phần quan trọng nhất. Phiên bản trước đây mà tôi hoàn thành còn tồn tại nhiều thiếu sót trong thiết kế.

Cảnh báo: Những nội dung dưới đây chỉ mang tính chất giải trí cá nhân, vui lòng không sử dụng vào dự án thật. Bản thân tôi cũng không ủng hộ việc tùy tiện dùng syntactic sugar để biến đổi ngôn ngữ.

Chúng ta đều biết rằng C++ hỗ trợ tính năng nạp chồng hàm (function overloading), cho phép các lập trình viên viết nhiều phiên bản hàm cùng tên nhưng khác tham số. Trình biên dịch sẽ tự động chọn hàm phù hợp dựa trên kiểu dữ liệu của đối số khi gọi hàm. Đối với các lập trình viên C++ trung thành, đây là một công cụ không thể thiếu. Nếu thiếu tính năng này, các mẫu template (template meta-programming) sẽ không thể tạo ra vô số biến thể phức tạp như hiện nay, và đương nhiên, các lập trình viên cũng sẽ không còn cơ hội ngắm nghía những đoạn mã template “thông minh” đầy hoa mỹ để tự sướng về chỉ số IQ nữa.

Trong PHP có một hàm tiện ích tên là print_r cho phép hiển thị cấu trúc bảng một cách đệ quy. Hàm này được nhiều lập trình viên PHP ưa chuộng khi debug chương trình.

Theo kinh nghiệm cá nhân, tôi tin rằng bất kỳ ai từng lập trình Lua với quy mô vừa phải đều sẽ tự xây dựng một công cụ tương tự để dùng lâu dài. Trong quá trình debug code Lua gần đây, tôi nhận ra phiên bản print_r đơn giản trước đây không đáp ứng tốt khi xử lý các bảng có cấu trúc phức tạp - đầu ra quá dài và thiếu trực quan. Thế là tôi tạm gác công việc chính lại, dành trọn 1 tiếng đồng hồ để viết lại hàm mới với hơn chục dòng code tinh gọn, giúp hiển thị bảng dữ liệu dưới dạng sơ đồ cây phân cấp.