5 Triết lý 'vả mặt' của cụ tổ Rob Pike: Đừng làm màu khi code chưa chạy!

Hồi mới vào nghề, tôi cũng như bao anh em dev khác, cứ thích nhồi nhét đủ loại design patterns, thuật toán phức tạp vào project cho nó "pro". Kết quả là gì? Bug lòi mắt, server cắn RAM như cắn kẹo, mà sếp thì gào thét vì tiến độ chậm. Hóa ra, những bài học từ năm 1989 của cụ Rob Pike (cha đẻ của Go, UTF-8) đến tận bây giờ vẫn còn nguyên giá trị "vả mặt" những ai thích làm màu.

5 cái 'vả mặt' từ năm 1989 nhưng đến giờ vẫn còn rát

Nếu anh em chưa biết thì Rob Pike không chỉ là một lão làng, cụ là một huyền thoại sống. Những quy tắc của cụ đơn giản đến mức... thô lỗ, nhưng lại cực kỳ thực dụng:

Đừng có đoán mò chỗ nào chậm: Anh em đừng có ngồi đó mà "phán" rằng đoạn code này sẽ tốn tài nguyên. Trong bóng tối của sự phức tạp, bottleneck (điểm nghẽn) luôn xuất hiện ở những chỗ ảo ma nhất. Đừng vội vã tối ưu (optimize) khi chưa thấy nó chậm thật sự.
Đo đi rồi hãy gáy: Muốn biết code nhanh hay chậm? Hãy dùng tool mà đo. Đừng bao giờ bỏ thời gian để tăng tốc một đoạn code trừ khi nó chiếm phần lớn thời gian chạy của cả hệ thống.
Thuật toán xịn thường tỷ lệ nghịch với độ hiệu quả khi n nhỏ: Mấy ông hay lôi thuật toán O(log n) ra để xử lý danh sách có 10 phần tử làm gì? Lúc đó overhead của thuật toán còn tốn hơn cả việc chạy vòng lặp đơn giản. Nhớ lấy: Dữ liệu thực tế thường nhỏ hơn anh em tưởng.
Càng phức tạp càng dễ toang: Thuật toán càng ảo diệu thì càng khó code, khó debug và dễ dính bug ẩn. Hãy chọn những cấu trúc dữ liệu đơn giản nhất có thể để giải quyết vấn đề.
Data mới là linh hồn, không phải thuật toán: Đây là cú chốt hạ. Nếu ông chọn đúng cấu trúc dữ liệu và tổ chức nó tốt, thuật toán sẽ tự nhiên mà lộ diện. Data structures, không phải algorithms, mới là trung tâm của lập trình.

Dân mạng Hacker News thi nhau 'hứng gạch'

Bài viết này dù từ đời tống nhưng vừa được đào lại trên Hacker News và gây ra một cuộc combat cực gắt giữa các thế hệ dev. Có vài luồng quan điểm khiến tôi khá tâm đắc:

Phe 'Càng già càng thấm': Đa số các Senior lâu năm đều đồng ý rằng 90% lỗi của dev trẻ là "tối ưu sớm" (premature optimization). Cứ thích build một cái Ferrari để đi chợ cách nhà 500m.
Phe 'Thời đại đã khác': Một số anh em cãi lại rằng thời nay RAM rẻ, CPU khỏe, cứ dùng mấy cái framework cồng kềnh cho nhanh, quan tâm gì mấy cái rule cổ lỗ sĩ. Nhưng ngay lập tức bị vả lại: "Chính vì tư duy đó mà cái app máy tính (calculator) bây giờ cũng tốn 200MB RAM đấy!".
Góc nhìn thực tế: Nhiều người nhấn mạnh vào Rule 5 - Data dominates. Trong kỷ nguyên Big Data và AI, việc tổ chức dữ liệu chuẩn chỉ quan trọng hơn gấp vạn lần mấy cái tiểu xảo code lặt vặt.

Bài học sinh tồn: Từ dòng code đến chuyện vận hành SME

Nhìn từ góc độ của một Dev từng trải và giờ đang làm việc tại WorkCloud, tôi thấy triết lý của cụ Rob Pike không chỉ áp dụng cho code. Các doanh nghiệp SME nhà mình cũng hay mắc kẹt trong cái bẫy "làm màu" tương tự.

Thay vì tập trung vào cấu trúc dữ liệu cốt lõi của doanh nghiệp (khách hàng, dòng tiền, công việc), nhiều sếp lại thích mua những hệ thống ERP nghìn đô, phức tạp vcl về rồi bỏ xó vì nhân viên không biết dùng. Đó chính là cái bẫy "Fancy Algorithms" mà cụ Rob đã cảnh báo.

Tại WorkCloud, chúng tôi build nền tảng theo đúng Rule 5: Tập trung vào việc tổ chức dữ liệu vận hành sao cho đơn giản, mượt mà nhất. Không cần bạn phải là thiên tài công nghệ, chỉ cần dữ liệu chuẩn, mọi quy trình (thuật toán) sẽ tự động chạy trơn tru. Đừng cố gắng cài đặt một hệ thống quá tầm khi quy mô doanh nghiệp còn nhỏ. Hãy bắt đầu từ những thứ đơn giản, đo lường hiệu quả, rồi mới tính chuyện mở rộng.

Chốt lại: Đừng làm phức tạp hóa vấn đề. Dù là code hay là quản trị, sự đơn giản và thực dụng luôn là chìa khóa để tồn tại qua các mùa trăng.

Nguồn: Rob Pike’s Rules of Programming (1989)

5 cái 'vả mặt' từ năm 1989 nhưng đến giờ vẫn còn rát

Đừng có đoán mò chỗ nào chậm: Anh em đừng có ngồi đó mà "phán" rằng đoạn code này sẽ tốn tài nguyên. Trong bóng tối của sự phức tạp, bottleneck (điểm nghẽn) luôn xuất hiện ở những chỗ ảo ma nhất. Đừng vội vã tối ưu (optimize) khi chưa thấy nó chậm thật sự.

Đo đi rồi hãy gáy: Muốn biết code nhanh hay chậm? Hãy dùng tool mà đo. Đừng bao giờ bỏ thời gian để tăng tốc một đoạn code trừ khi nó chiếm phần lớn thời gian chạy của cả hệ thống.

Thuật toán xịn thường tỷ lệ nghịch với độ hiệu quả khi n nhỏ: Mấy ông hay lôi thuật toán O(log n) ra để xử lý danh sách có 10 phần tử làm gì? Lúc đó overhead của thuật toán còn tốn hơn cả việc chạy vòng lặp đơn giản. Nhớ lấy: Dữ liệu thực tế thường nhỏ hơn anh em tưởng.

Càng phức tạp càng dễ toang: Thuật toán càng ảo diệu thì càng khó code, khó debug và dễ dính bug ẩn. Hãy chọn những cấu trúc dữ liệu đơn giản nhất có thể để giải quyết vấn đề.

Data mới là linh hồn, không phải thuật toán: Đây là cú chốt hạ. Nếu ông chọn đúng cấu trúc dữ liệu và tổ chức nó tốt, thuật toán sẽ tự nhiên mà lộ diện. Data structures, không phải algorithms, mới là trung tâm của lập trình.

Dân mạng Hacker News thi nhau 'hứng gạch'

Phe 'Càng già càng thấm': Đa số các Senior lâu năm đều đồng ý rằng 90% lỗi của dev trẻ là "tối ưu sớm" (premature optimization). Cứ thích build một cái Ferrari để đi chợ cách nhà 500m.

Phe 'Thời đại đã khác': Một số anh em cãi lại rằng thời nay RAM rẻ, CPU khỏe, cứ dùng mấy cái framework cồng kềnh cho nhanh, quan tâm gì mấy cái rule cổ lỗ sĩ. Nhưng ngay lập tức bị vả lại: "Chính vì tư duy đó mà cái app máy tính (calculator) bây giờ cũng tốn 200MB RAM đấy!".

Góc nhìn thực tế: Nhiều người nhấn mạnh vào Rule 5 - Data dominates. Trong kỷ nguyên Big Data và AI, việc tổ chức dữ liệu chuẩn chỉ quan trọng hơn gấp vạn lần mấy cái tiểu xảo code lặt vặt.

Bài học sinh tồn: Từ dòng code đến chuyện vận hành SME

Chốt lại: Đừng làm phức tạp hóa vấn đề. Dù là code hay là quản trị, sự đơn giản và thực dụng luôn là chìa khóa để tồn tại qua các mùa trăng.