Tại Sao Không Nên Viết Các Chương Trình Lớn

Tại Sao Nên Tránh Viết Chương Trình Cồng Kềnh

Trong cuốn “Nghệ Thuật Lập Trình Unix”, triết lý Unix được tóm lược bởi nguyên tắc: “Nếu không phải là giải pháp duy nhất, hãy tránh viết chương trình cồng kềnh”. Chương 13 của sách - mang tên “Độ Phức Tạp: Đơn Giản Đến Mức Tối Ưu Nhưng Không Thiếu Sót” - dành riêng để phân tích sâu sắc về vấn đề này.

Tuần sau, đội ngũ của tôi sẽ đối mặt với một mốc tiến độ quan trọng. Vì vậy, tôi quyết định tăng cường làm việc vào cuối tuần. Thực tế, gần hai năm nay, tôi coi ngày nghỉ như cơ hội để tập trung vào công việc một cách chủ động, không còn phân biệt rõ ràng giữa thứ Bảy - Chủ Nhật. Tuy nhiên, việc yêu cầu cả nhóm làm thêm giờ là điều tôi rất ít khi áp dụng.

Mỗi cá nhân đều có những ưu tiên cuộc sống riêng, và tôi luôn đề cao triết lý: “Cuộc sống quan trọng hơn công việc”. Nếu ai đó có việc cá nhân vào cuối tuần, tôi hoàn toàn ủng hộ việc họ từ chối tăng ca. Về phía dự án, chúng tôi nỗ lực để không phụ thuộc quá mức vào bất kỳ cá nhân nào. Dù việc để người viết module đó trực tiếp bảo trì có thể hiệu quả hơn, nhưng mọi thành viên cần có khả năng thay thế nhau khi cần thiết.

Khả năng nắm bắt nhanh code không phải do mình viết là kỹ năng mà bất kỳ lập trình viên nào cũng nên có. Nhưng thực tế, đội ngũ chúng tôi vẫn chưa đạt đến trình độ này. Điều này không chỉ do năng lực cá nhân, mà còn liên quan đến cách tổ chức dự án: phân chia module rõ ràng, tài liệu hóa chi tiết, và quy chuẩn code nhất quán.

Tôi thường tự nhắc nhở: “Hãy viết những chương trình nhỏ gọn, trừ khi không còn lựa chọn nào khác”. Các hệ thống đơn giản không chỉ dễ bảo trì mà còn giúp lập trình viên nhanh chóng nắm bắt nội dung. Khi tôi nói “nhanh chóng nắm bắt”, ý tôi là trong vòng 30 phút đầu tiên đọc code lạ, bạn đã có thể hiểu được cấu trúc và bắt tay vào sửa lỗi. Nếu phải mất vài giờ mơ hồ với code, thà đợi đến giờ làm việc chính để nhờ tác giả trực tiếp giải quyết còn hiệu quả hơn.

Không chỉ cuối tuần này, mà suốt nhiều tháng qua, chúng tôi thường xuyên làm việc vào ban đêm với nhân sự không đầy đủ. Những lúc ấy, khả năng tự giải quyết vấn đề trở nên đặc biệt quan trọng. Dù vẫn có lúc cần gọi điện nhờ tác giả code hỗ trợ, nhưng phần lớn các lỗi đều được xử lý nội bộ. Điều này có được nhờ triết lý không xây dựng hệ thống to lớn. Ngay cả khi buộc phải làm game client phức tạp, chúng tôi vẫn phân tầng kiến trúc rõ ràng, giữ các module ở quy mô vừa phải.

Tôi muốn nhấn mạnh thêm: Đừng ngại tiếp cận code của người khác. Dù không phải dự án của mình, khi phát hiện vấn đề, hãy chủ động tìm cách giải quyết - đây chính là tinh thần của cộng đồng mã nguồn mở. Quá trình sửa chữa những đoạn code không đạt chuẩn thẩm mỹ của bản thân lại là cơ hội tuyệt vời để nâng cao trình độ. Ví dụ, dù đã từ bỏ C++ trong phát triển phần mềm, tôi vẫn thường xuyên nghiên cứu các dự án C++. Thay vì chỉ trích các thiết kế “tinh vi”, tôi cố gắng hiểu bối cảnh thực tế dẫn đến kiến trúc đó.

Gần đây vì công việc quá tải, tôi không có thời gian đọc sách như trước. Chỉ có cuốn “Nghệ thuật lập trình Unix” luôn trong tầm tay, để thỉnh thoảng mở ra xem khi mệt mỏi. Nhiều nguyên tắc đọc xong mới thấy: Không phải điều gì mới mẻ, mà là những chân lý đã hiểu nhưng được diễn giải rõ ràng hơn. Năm qua, tôi cảm nhận rõ sự trưởng thành trong tư duy kỹ thuật - không phải là học được thứ gì hoàn toàn mới, mà là nhìn nhận lại những điều đã biết với góc nhìn sâu sắc hơn.

Một so sánh thú vị:
Dự án của chúng tôi khi build trên Windows bằng MinGW mất 47 giây (trên hệ thống sạch sẽ Windows XP không cài phần mềm diệt virus). Trong khi đó, cùng phần mềm và phần cứng, build trên FreeBSD chỉ cần 18 giây.
Bạn có thể lý giải sự khác biệt này không?
Liệu có phải do tốc độ khởi tạo tiến trình chậm trên Windows? Hệ thống file kém hiệu suất? Console hoạt động ì ạch? Hay đơn giản là MinGW GCC chạy chậm hơn?