Chắc hẳn là bất kì ai trong lĩnh vực IT, dù là developer hay tester, cũng đã từng nghe nói tới cuốn sách Clean code của tác giả Robert Cecil Martin – mọi người gọi thân mật là Uncle Bob – một trong những người nổi tiếng và có nhiều đóng góp thiết thực trong lĩnh vực software engineering. Cuốn này nói về việc làm thế nào để viết code cho “sạch” và chuyên nghiệp hơn, đại loại là code của bạn sẽ “xịn” hơn, mình chưa đọc cuốn này, nhưng có đọc qua một cuốn tương tự, đó là cuốn sách mà mình giới thiệu hôm nay: The art of readable code.

(Nhân tiện mình quảng cáo 1 cuốn khác của Uncle Bob, là cuốn The clean coder nói về phong cách chuyên nghiệp và con đường phát triển của lập trình viên, rất nên đọc ^^)
The art of readable code – Cái tên đã nói lên tất cả
Có lẽ, chỉ cần cái chạm mắt đầu tiên, các bạn cũng đã đoán ra được cuốn sách này muốn nói tới điều gì: readable code – tính dễ đọc của code. Bấy lâu nay, chúng ta vẫn luôn mang một quan điểm lầm lẫn về việc viết code, chúng ta thường viết code cốt chỉ để cho máy tính biên dịch và chạy được, mà vô tình quên mất rằng: viết code còn để cho con người đọc và hiểu nữa. Lí do ư: việc phát triển phần mềm không chỉ dừng lại ở việc viết code ban đầu, mà còn cần phải được bảo trì và tiếp tục phát triển sau này. Rất nhiều người khác tham gia vào chu trình này chứ không chỉ một mình bạn.

Đã bao giờ bạn lâm vào tình trạng code của chính mình viết vài tháng trước đây nhưng hôm nay đọc lại bỗng không hiểu nó là gì, đã code xong tính năng sếp yêu cầu nhưng khi review cứ bị reviewer trả lại hoài. Hay đã bao giờ bạn đọc các đoạn code của người khác viết và tự hỏi: code như thế này thực sự “chuyên nghiệp” hay chưa nhỉ? ..v.v. Nếu đã từng 1 lần thắc mắc hoặc gặp phải những điều đó, có lẽ cuốn sách The art of readable code này là dành cho bạn.
Những vấn đề chính mà cuốn sách đề cập
Nếu như bạn còn có định kiến rằng: sách vở chỉ toàn nói chuyện hàn lâm, viết code là thực hành cơ mà, và cho rằng đọc sách không giúp cải thiện kĩ năng code thì bạn đã nhầm. Hãy nhìn vào slogan của cuốn sách: simple and practical techniques for writing better code, cuốn sách này chứa đựng những lời khuyên và ví dụ rất thiết thực, rất đúng chất “practical”.
Như mình đã nói ở trên, cảnh giới tối thượng của việc viết code cần phải đạt được là: code should be easy to understand – code cần phải dễ hiểu. Với tiêu chí này dẫn đường, sách đưa chúng ta qua ba cấp độ của việc viết code:
Cấp độ 1 – nhập môn viết code
Có thể nói, đây là phần dễ nhất nhưng cũng là phần gây đau đầu nhất trong lập trình. Thuở bắt đầu mới học code, bạn được hướng dẫn cách viết code để chương trình chạy, và chỉ thế thôi. Có ai từng dạy bạn cách đặt tên biến không nhỉ? Đã bao giờ bạn tốn mất hàng giờ đồng hồ để chọn ra một cái tên ưng ý cho biến, hay đã bao giờ bạn đặt tên biến kiểu temp1, temp2, final_result, … không? Một tuần sau, rồi một tháng sau, liệu bạn còn nhớ được ý nghĩa của cúng là gì không?

Đặt tên biến là một chuyện, rồi nếu giả sử code khó hiểu thì có nên comment không? Mà thế nào là code khó hiểu? Rồi thì comment thì viết cái gì bây giờ .v.v.. Thẩm mĩ của code cũng rất quan trọng, nghiên cứu chỉ ra rằng code được format rõ ràng sẽ dễ hiểu hơn so với viết cách lộn xộn, .v.v. Tóm lại, ở cấp độ một, cuốn sách sẽ hướng dẫn cho bạn cách để:
- Đặt tên biến thế nào là hợp lí, làm thế nào để đặt tên có tính gợi nhớ cao, …
- Có nên comment code hay không, nếu có thì comment như thế nào, viết ra sao, …
- Cách format code sao cho đẹp, dễ đọc, có tính mô tả cao, …
Cấp độ 2 – tối ưu hoá các luồng xử lí và biểu đạt ngữ nghĩa logic
Ở cấp độ này, bạn được cung cấp cái nhìn ở mức bao phủ rộng hơn một chút. Hai vấn đề lớn mà chúng ta mà chúng ta hay gặp nhất trong quá trình viết code đó là việc kiểm soát luồng xử lí và việc mô hình hoá các biểu diễn logic.

Trong phần kiểm soát luồng xử lí, tác giả có đưa ra so sánh các loại vòng lặp khác nhau, ưu nhược điểm của chúng và khi nào thì loại này nên được sử dụng thay cho vòng lặp khác, cách xử lí vòng lặp lồng nhau, …. Không chỉ thế, các cấu trúc xử lí khác như if-else, switch-case, goto, … cũng được đưa ra bàn luận, tất cả đều kèm với ví dụ cụ thể để bạn có thể hình dung được vấn đề.
Đi song song với các luồng xử lí logic, là các biểu diễn logic. Chúng có thể là chuỗi các điều kiện so sánh, chuỗi kết hợp biểu thị logic đúng sai, … Cuốn sách đưa ra cho chúng ta một vài cách để tối ưu hoá các điều kiện so sánh cũng như biểu diễn lại logic mệnh đề thông qua luật De-Morgan, kĩ thuật dùng biến mô tả, phân rã các chuỗi biểu diễn phức tạp, …
Cấp độ 3 – Tái cấu trúc lại source code
Nếu đã đạt tới cảnh giới cấp độ 2, thì code của bạn trông cũng đã khá ngon lành rồi. Tuy nhiên, có thể phần mềm của bạn sẽ có nhu cầu mở rộng ra, kiến trúc thiết kế của phần mềm cần phải được tái cấu trúc để đạt được hiệu suất cao hơn, … Do vậy mà chúng ta sẽ cần nâng cấp khả năng viết code lên tới cấp độ 3. Ở cấp độ này, các tác giả sẽ giúp bạn viết code ở một mức trừu tượng hơn rất nhiều:
- Tách source code lớn thành các module con: phần này sẽ hướng dẫn bạn cách để tái cấu trúc lại ứng dụng, khi nào thì nên tách các xử lí ra riêng biệt, …
- Tính đơn nhiệm trong thiết kế: Không nên để một hàm chịu trách nhiệm quá nhiều việc dẫn tới khó kiểm soát, đồng thời cũng tăng khả năng dính bug. Tính đơn nhiệm cũng được nhắc tới trong nguyên tắc 1 của SOLID.
- Biểu diễn suy nghĩ của bạn bằng code cách tự nhiên: code không chỉ cho máy mà còn cho người, do đó code cần mô tả được ý định của lập trình viên, việc dùng các thư viện đã có sẵn đôi khi cũng giúp ích rất nhiều …
- Code ngắn mà chất: Bạn cần phải hiểu rõ yêu cầu, để không phải code quá nhiều dẫn tới dư thừa tính năng, lại có thể dễ dàng mở rộng trong tương lai. Code ngắn nhưng đủ cũng giúp ta hoàn thành công việc sớm hơn, tránh bị OT, ….

Một cái nhìn xa hơn
Có thể nói rằng, cuốn sách này có nội dung tương tự như cuốn Clean Code thần thánh của Uncle Bob. Cuốn sách là một bản hướng dẫn giúp chúng ta: code dễ hiểu hơn, code đẹp hơn, code chạy tốt hơn, … và vì thế mà code trở nên “xịn” hơn rất nhiều.
Cùng với cuốn The clean coder, bộ đôi này là một cặp kinh điển dành cho lập trình viên: The art of readable code chứa đựng những kiến thức mang tính practical – hướng dẫn về thực hành và kĩ năng cứng, còn The clean coder như một tập hợp kĩ năng mềm giúp điều chỉnh thái độ và định hướng con đường. Với tất cả sự chân thành, lời khuyên là tất cả developer chúng ta đều nên đọc 2 quyển này, không những đọc một lần mà nhiều lần trong đời, rất xứng đáng với thời gian bỏ ra.
Nếu còn muốn tiến bộ hơn nữa, hãy tìm đọc cuốn Agile Software Development: Principles, Patterns, and Practices cũng của Uncle Bob, nói về các nguyên lí phát triển phần mềm, các mẫu thiết kế hướng đối tượng, cách design hệ thống, … Nếu nắm được kiến thức của 3 cuốn sách này và biết cách áp dụng, bạn có thể tự tin mà nói rằng: tôi không còn là coder, tôi là một software engineer
