"Ngày còn sinh viên, LeetCode gần như làm hỏng cả não mình. Nhìn thấy mấy giải pháp một dòng siêu ngắn gọn kỳ lạ của mấy top coder, mình từng oán thầm 'Sao đời mình không bao giờ giỏi thế được?'"

Cái này thường được gọi là "code golfing". Nó là một trò giải trí thú vị, nhưng nó cách xa "mã code tốt" cả một trời xa.

Mọi người (bao gồm cả những người trên LeetCode) đều biết đây không phải là mã code tốt. Trong ngành, nó là thứ tồi tệ nhất mà một người có thể viết.

Cuối cùng tôi nhận ra rằng mã code rõ ràng nhất thực sự là thứ khó viết nhất.

Nghĩ lại thì cũng hợp lý. Xem lại mã code của một kỹ sư phần mềm cao cấp dễ hiểu và đánh giá hơn nhiều so với mã code của một kỹ sư mới vào nghề.

Clear code: tốt và xấu

Cái "sức mạnh" của code rõ ràng, dù tốt hay xấu, đã hoàn toàn được bộc lộ sau một sự cố nọ ở công ty.

Tôi từng viết một module xử lý dữ liệu trong C++, một ngôn ngữ nói chung khó đọc hơn so với các ngôn ngữ khác do tính rườm rà của nó.

Tôi bắt đầu chỉ với hai file (.h/.cpp) và tất cả code implement đều nằm trong hai file này.

Kết quả là một "mớ mì spaghetti" khổng lồ, kinh khủng bên trong, nhưng lại là một chương trình hoạt động hoàn hảo bên ngoài.

Điều này chắc chắn sẽ không bao giờ vượt qua được khâu review code.

Sau đó mình đã chia code implement thành hơn 30 diff (Diff stack thường được sử dụng trong các hệ thống kiểm soát phiên bản phân tán, chẳng hạn như Git và Mercurial. Các hệ thống này cho phép nhiều người làm việc trên cùng một tệp hoặc thư mục, đồng thời theo dõi các thay đổi đã được thực hiện bởi từng người) .

Mỗi diff là một đoạn code gọn gàng, đóng gói, với chỗ để chèn các phụ thuộc sẽ có trong các diff sau. Nó có code được chia tách cẩn thận thành các hàm phụ và file phụ khi cần thiết.

Mỗi diff đều có coverage unit test - bao gồm các trường hợp cơ bản và một số trường hợp ngoại vi, nhưng không bị lạm dụng một cách lãng phí.

Mỗi diff cũng khiến mình phải trải qua nhiều vòng lặp "dọn code", refactor và hơn thế nữa. Việc đạt được "code rõ ràng" đòi hỏi nhiều công sức hơn so với dự kiến, đặc biệt là đối với một chương trình lớn như vậy.

Kết quả? Một cú hạ cánh đẹp mắt của module xử lý dữ liệu, với code dễ đọc và rõ ràng.

Mặc dù tự hào về thành quả, bất ngờ lại có một vấn đề khi mình nói chuyện với sếp về nó.

"Anh hiểu là module này phức tạp thế nào, nhưng xét trên phương diện đánh giá performance, code này trông khá tầm thường. Nó có vẻ quá dễ dàng, quá đơn giản.

Vì vậy, anh đề xuất viết một document giải thích chi tiết về cách implementation của module này để có thể chứng minh thực tế nó khá phức tạp.”

Mình đã bị sốc nặng. Đây không phải startup, mà là một trong những công ty lớn nhất thế giới, nổi tiếng với văn hóa kỹ sư.

Lúc đó mình mới hiểu vì sao Big Tech dường như có vô số tài liệu. Một nửa những tài liệu mình viết chẳng cần phải viết, nhưng… mình buộc phải làm vậy. Bởi vì mình muốn tăng lương và thăng chức.

Mặc dù văn hóa thăng chức ở Big Tech là câu chuyện khác, điều chính ở đây là: code tuyệt vời là code rất rõ ràng và dễ đọc.

Còn có câu thành ngữ hay ho "debug code khó gấp đôi viết code". Chính vì thế, khi ChatGPT phơi ra một mớ hỗn độ, thường thì người ta sẽ bấm nhắc lại yêu cầu hoặc tự viết lại từ đầu cho nhanh, thay vì cố gỡ rối cho con code lỗi tùm lum của nó.

Code "hay ho" thì khó đọc và trông bí ẩn.

Code "rõ ràng" thì khó viết nhưng dễ đọc.

Một số suy nghĩ khác về clear code

Cái cách duy nhất mình giỏi hơn trong việc viết code rõ ràng, dễ đọc là... chăm viết code, cực kỳ siêng năng, trong khi tuân theo nghiêm ngặt một style guide rõ ràng.

Ngoài ra, nhờ có các dev nhiều kinh nghiệm soi code mình bằng kính lúp. Ban đầu, nhận cả tấn comment và "nitpicking" về những thứ stylistic tưởng như vô nghĩa thật là đau đớn, nhưng về sau cũng bõ công.

Coding style quan trọng hơn mình nghĩ lúc ban đầu. Hành trình kỹ sư phần mềm của mình bắt đầu từ thiên hướng "lắm nghĩ sản phẩm" rồi dần dịch chuyển sang " thiên về kỹ thuật".

Mình bắt đầu học code chỉ để khởi nghiệp, nên ban đầu chỉ quan tâm code như công cụ, dẫn đến code cẩu thả, khó maintain.

Phải sau này, khi quen việc viết code và làm việc trong team, thì tầm quan trọng của code rõ ràng, dễ đọc mới dần rõ ràng.

Không chỉ mình đâu, đây là điều hiển nhiên với bất kỳ ai đã làm code trong ngành hơn 1 năm.

John Carmack từng viết một email dài về coding style vào năm 2007, khá thú vị đấy.

Google chắc là có style guide công khai nhất. Vercel cũng vừa mới ra mắt style guide của họ, và hầu như mọi công ty đều dùng linter và trình format code nào đó.

Tổng kết

Nếu bạn quan tâm đến việc phát triển trong vai trò kỹ sư phần mềm, bạn có thể tham khảo khóa học của Jordan Cutler Mid-level to Senior for high-growth engineers..