Lời Của Người Già

Những lời khuyên vàng từ bậc thầy Sách “The Elements of Programming Style” có lịch sử hơn 30 năm tuổi, nhưng những nguyên tắc trong đó vẫn nguyên giá trị như kim chỉ nam cho các lập trình viên hiện đại. Dù ngôn ngữ lập trình Fortran ngày nay ít được sử dụng và công nghệ thay đổi chóng mặt, những điều được đúc kết từ năm 1978 vẫn mang tính thời sự.

Dưới đây là tuyển chọn những nguyên tắc bất hủ được chuyển thể sang góc nhìn mới:

Nghệ thuật viết mã đẹp

• Trình bày mã nguồn như một tác phẩm văn học: Mỗi dòng code nên tựa như câu văn mạch lạc, tránh những mẹo vặt thông minh chết người
• Truyền đạt ý đồ thiết kế bằng cách đơn giản nhất: Hãy dùng ngôn ngữ lập trình như ngôn ngữ tự nhiên, diễn đạt trực tiếp mục đích cần đạt
• Tận dụng sức mạnh từ thư viện chuẩn: Đừng tái phát minh bánh xe khi đã có hàm thư viện được kiểm chứng qua thời gian
• Kiểm soát biến tạm thời: Mỗi biến tạm thêm vào là một nơ-ron cần kích hoạt trong bộ nhớ làm việc của lập trình viên
• Minh bạch không nên đánh đổi: Hiệu năng chỉ nên cân nhắc khi rõ ràng code đã trong trạng thái tối ưu về mặt logic

Kiến trúc tư duy

• Giao việc nhà cho máy tính: Hãy để compiler xử lý những công việc lặp nhàm chán thay vì tự giải quyết thủ công
• Thay thế biểu thức lặp bằng hàm: Mỗi đoạn code trùng lặp là một cơ hội để tạo ra thành phần có thể tái sử dụng
• Ưu tiên độ rõ ràng hơn tốc độ: Đừng hy sinh tính dễ bảo trì vì những cải tiến hiệu năng vi mô chưa chứng minh được giá trị
• Thiết kế dữ liệu quyết định tốc độ: Kiểu biểu diễn dữ liệu phù hợp có thể biến đổi hoàn toàn hiệu năng hệ thống
• Xây dựng từ giả mã: Trước khi viết code thật, hãy phác thảo giải pháp bằng ngôn ngữ tự nhiên

Nghệ thuật lập trình hướng đối tượng

• Tổ chức thành mô-đun logic: Mỗi chức năng nên được gói gọn trong các hàm/procedure độc lập, có trách nhiệm duy nhất
• Hạn chế dùng lệnh nhảy (goto): Chỉ dùng khi thật sự cần phá vỡ luồng thực thi thông thường, và phải ghi chú rõ ràng
• Tái cấu trúc thay vì vá lỗi: Khi gặp code xấu, đừng cố sửa chữa - hãy viết lại từ đầu với cách tiếp cận đúng đắn
• Xử lý cấu trúc đệ quy bằng đệ quy: Với dữ liệu định nghĩa theo cách đệ quy, hãy dùng kỹ thuật đệ quy để xử lý tự nhiên

Quy trình kiểm thử chuyên nghiệp

• Kiểm thử cả “dữ liệu kỳ dị”: Không chỉ test với input lý tưởng, hãy chuẩn bị cho mọi tình huống “bất thường” có thể xảy ra
• Bảo vệ biên giới hệ thống: Xác minh tất cả dữ liệu đầu vào trước khi xử lý, đừng tin tưởng blind vào nguồn bên ngoài
• Xử lý EOF đúng cách: Khi đọc file, đừng dựa vào việc đếm trước số dòng - hãy xử lý tín hiệu kết thúc tập tin một cách thanh lịch

Nghệ thuật gỡ lỗi

• Debug bằng tư duy chiến lược: Mở công cụ debug của compiler, không nên sửa từng bug một cách cảm tính
• Khởi tạo biến cẩn trọng: Đảm bảo mọi biến đều có giá trị ban đầu rõ ràng trước khi sử dụng
• Đối mặt với bug cứng: Đừng để một lỗi nhỏ làm chậm tiến độ - hãy chấp nhận tạm bỏ qua để nghiên cứu sâu hơn

Xử lý số học chính xác

• Cẩn trọng với số thực: Đừng so sánh bằng trực tiếp các số dấu phẩy động - hãy dùng kỹ thuật so sánh trong ngưỡng epsilon
• Hiểu bản chất toán học: 7/8 trong lập trình là 0, nhưng 7.0/8.0 sẽ là 0.875 - sự khác biệt nằm ở kiểu dữ liệu
• Tính toán định kỳ: Đừng giả định 10.0*0.1 luôn bằng 1.0 do lỗi làm tròn số học máy tính

Tối ưu hóa hợp lý

• Làm đúng trước, làm nhanh sau: Tập trung vào tính chính xác trước khi nghĩ đến hiệu năng
• Cải tiến có cơ sở: Dùng công cụ phân tích để xác định bottleneck thực sự, đừng tối ưu theo cảm tính
• Giữ code sạch sẽ: Đừng đánh đổi tính trong sáng của code vì những cải tiến hiệu năng vi mô chưa được chứng minh

Ghi chú và tài liệu

• Biến là tài liệu sống: Mỗi tên biến nên tự nó đã mang ý nghĩa rõ ràng
• Ghi chú chỉ khi cần thiết: Đừng lặp lại những gì code đã nói, hãy dùng chú thích để giải thích “tại sao” chứ không phải “cái gì”
• Tài liệu hóa thiết kế: Ghi lại chiến lược tổ chức dữ liệu và kiến trúc hệ thống để người khác dễ tiếp quản

Triết lý lập trình

• Kỹ nghệ hơn là nghệ thuật: Dù lập trình có tính sáng tạo, nhưng cần tuân thủ các nguyên tắc kỹ thuật cơ bản
• Tinh thần cải tiến liên tục: Luôn tìm cách làm cho code dễ đọc hơn, cấu trúc rõ ràng hơn, hiệu năng tốt hơn
• Sự khiêm tốn trong thiết kế: Đừng cố gắng viết code “thông minh” hay “tài tình” - hãy viết code dễ hiểu cho đồng nghiệp và chính bản thân mình trong tương lai

Những nguyên tắc này không phải là chân lý tuyệt đối, mà là kim chỉ nam để chúng ta cân nhắc trong từng tình huống thực tế. Quan trọng là hiểu rõ bản chất vấn đề, từ đó đưa ra quyết định sáng suốt phù hợp với bối cảnh cụ thể.