Các quy tắc lập trình của Rob Pike (1989)

• Bài viết về 5 quy tắc lập trình của Rob Pike năm 1989
• Quy tắc 1: Đừng giả định chương trình sẽ dành phần lớn thời gian ở đâu; điểm nghẽn có thể xuất hiện ngoài dự kiến. Hãy tránh các mẹo tối ưu tốc độ cho đến khi điểm nghẽn được chứng minh.
• Quy tắc 2: Luôn đo đạc trước khi tinh chỉnh vì tốc độ. Chỉ tối ưu hóa khi một phần của mã có ảnh hưởng đáng kể đến phần còn lại.
• Quy tắc 3: Khi n nhỏ, các thuật toán phức tạp sẽ chậm. Đây là trường hợp của hầu hết tình huống. Chỉ dùng thuật toán phức tạp khi n thường xuyên lớn, và ngay cả khi đó cũng hãy áp dụng Quy tắc 2 trước.
• Quy tắc 4: Các thuật toán và cấu trúc dữ liệu đơn giản là điều đáng mong muốn. Chúng ít dễ phát sinh lỗi hơn và dễ triển khai hơn so với những thứ phức tạp.
• Quy tắc 5: Cấu trúc dữ liệu đúng là yếu tố mang tính quyết định trong lập trình. Nếu dữ liệu được tổ chức tốt, thuật toán sẽ trở nên hiển nhiên.
• Quy tắc 1 và 2 của Pike phản ánh châm ngôn của Tony Hoare: "tối ưu hóa sớm là cội nguồn của mọi điều xấu".
• Ken Thompson diễn đạt lại Quy tắc 3 và 4 của Pike thành: "khi còn nghi ngờ, hãy dùng sức mạnh thô bạo".
• Quy tắc 3 và 4 hiện thực hóa triết lý thiết kế KISS (Keep It Simple, Stupid).
• Quy tắc 5 phù hợp với phát biểu trong 'The Mythical Man-Month' của Fred Brooks, thường được rút gọn thành "hãy viết đoạn mã ngốc sử dụng các đối tượng thông minh".

[GN⁺]

Ý kiến trên Hacker News

• Bài viết về các quy tắc lập trình của Rob Pike năm 1989
• Những người bình luận đồng ý rằng cốt lõi của lập trình là cấu trúc dữ liệu chứ không phải thuật toán
• Chỉ trích việc các buổi phỏng vấn kiểu LeetCode không tập trung vào cấu trúc dữ liệu nhiều hơn là thuật toán
• Lập luận rằng khi n nhỏ thì các thuật toán phức tạp lại chậm, và trong đa số trường hợp n thường nhỏ
• Người bình luận nhấn mạnh tầm quan trọng của việc chọn cấu trúc dữ liệu phù hợp và tổ chức mọi thứ gọn gàng
• Thảo luận về việc lạm dụng cơ sở dữ liệu và tác động tiêu cực của các schema DB do ORM tạo ra
• Các hướng dẫn này có vẻ là một chiến lược để ngăn chặn over-engineering và tối ưu hóa quá sớm
• Một số người bình luận cho rằng sự lãng phí hiệu năng nhỏ nếu tích tụ lại có thể làm chương trình chậm đi
• Tranh luận về câu trích dẫn "tối ưu hóa quá sớm là nguồn gốc của mọi điều xấu xa" và bối cảnh của nó
• Một số người bình luận cho rằng lập trình viên giỏi có thể dự đoán điều gì sẽ trở nên chậm và thậm chí đặt ra những vụ cá cược mang tính giáo dục từ trước
• Ý kiến phản biện rằng các thuật toán phức tạp áp dụng cho dữ liệu đơn giản có thể mang lại cải thiện hiệu năng lớn và thậm chí còn giúp đơn giản hóa
• Bài viết đã tạo ảnh hưởng lâu dài đến cách một số độc giả tiếp cận thiết kế và độ phức tạp
• Thảo luận về cách diễn giải quy tắc số 5, với một số bất đồng quanh cụm từ "hãy viết mã ngu sử dụng các đối tượng thông minh"