Review sách: Clean Code

Clean Code là gì thì với một người lập trình viên thì ai cũng hiểu và mong muốn đạt tới trình độ mà viết code không chỉ máy hiểu mà cả cho người khác cũng hiểu. Bởi khi dự án lớn lên, việc duy trì và phát triển code trở nên phức tạp hơn, việc viết code sạch sẽ giúp giảm thiểu rủi ro và tăng hiệu quả làm việc nhóm.

Thật thiếu sót lớn nếu như chúng ta không hệ thống các quy ước và khái niệm lại một chỗ. Rất may mắn khi đây không phải là một chủ đề mới, chủ đề này đã tồn tại rất lâu kể từ lúc lập trình xuất hiện.

Có hai cuốn mà các bạn có thể tham khảo gồm The Complete Code 2 và Clean Code. Tôi chọn cuốn Clean Code để đọc và tham khảo trước vì nó dễ đọc, giải thích lý do dễ hiểu và cũng được rất nhiều lập trình viên khác khuyên đọc.

Nếu như phải tóm gọn lại khái niệm Clean Code là gì, chúng ta có thể tóm tắt bằng 5 dòng sau:

• Dễ đọc và dễ hiểu: Code nên được viết sao cho người khác có thể đọc và hiểu nhanh chóng mà không cần phải giải thích quá nhiều.
• Đơn giản và có tính nhất quán: Code nên được viết sao cho dễ hiểu và tuân thủ các quy tắc nhất quán trong toàn bộ dự án.
• Dễ bảo trì: Code nên được viết sao cho dễ dàng sửa đổi, mở rộng và kiểm tra mà không gây ra lỗi.
• Không dư thừa: Code nên được viết sao cho không có phần thừa, tránh lặp lại.
• Kiểm thử: Code nên được viết sao cho dễ dàng kiểm thử, đảm bảo rằng các chức năng hoạt động đúng và dễ dàng phát hiện lỗi. Đây là lớp bảo vệ lỗi trong phần mềm.

Với mỗi gạch đầu dòng, bạn sẽ tìm thấy lý do và ví dụ minh họa cụ thể trong các chương trong sách. Ví dụ như cách đặt tên, quy ước viết hàm, comment,...

Những gì đã học được

Tên

• Tên nên rõ ràng, mô tả chính xác chức năng hoặc mục đích của biến, hàm, lớp.
• Tên nên ngắn gọn nhưng đủ ý nghĩa, tránh sử dụng từ viết tắt không rõ ràng.
• Tên nên tuân thủ quy tắc đặt tên trong dự án để đảm bảo tính nhất quán.
• Mọi tên biến nên cần trả lời được câu hỏi: tại sao tồn tại, làm gì, và làm thế nào.
• Tránh tên mơ hồ hoặc không rõ ràng.
• Đặt tên sao cho có thể đọc thành tiếng được.
• Mỗi từ chỉ mang 1 nghĩa và mỗi nghĩa chỉ nên 1 từ thể hiện thôi.
• Đặt tên sao có thể search được.

Hàm

• Hàm nên khoảng 20-40 dòng sao cho vừa đủ hiện 1 hàm trên giao diện editor.
• Hàm nên có một nhiệm vụ duy nhất và tên hàm nên phản ánh rõ ràng nhiệm vụ đó.
• Hàm nên đặt tên đơn giản và dễ hiểu, tên hàm dài tốt hơn comment dài.
• Hàm nên tránh sử dụng các biến toàn cục và phụ thuộc vào trạng thái bên ngoài.
• Nên viết hàm sao cho có thể đọc như một đoạn văn, dễ hiểu và dễ theo dõi.
• Nếu cần sử dụng switch, hãy cân nhắc sử dụng ABSTRACT FACTORY hoặc các cấu trúc dữ liệu khác để giảm sự phức tạp và tăng tính mở rộng.
• Nên sử dụng hàm với 1 tham số input, nếu cần nhiều tham số, hãy cân nhắc sử dụng đối tượng để đóng gói các tham số.
• Không nên truyền flag vào trong một hàm nào đó, thay vào đó nên tách ra làm 2 hàm.
• Hàm nên có return rõ ràng, thay vì trả về dựa trên tham số tham chiếu thì hãy chọn trả về giá trị mới.
• Tránh side effect. Tránh thay đổi ẩn trong hàm vì khi dùng dễ quên, không nhớ, phải đọc kỹ nội dung hàm thay vì chỉ cần đọc tên hàm.
• Nên phân biệt rõ giữa command và query khi viết hàm và đặt tên đúng.
• Không nên lặp lại code. Hãy tái sử dụng code thông qua các hàm hoặc lớp để giảm sự trùng lặp và tăng tính bảo trì.

Formatting

Đa số format đều rất cơ bản, tôi không nghĩ là có gì quá đặc biệt. Nếu phải tóm gọn lại có thể nói rằng: những dòng code nào có liên quan với nhau thì nên để gần nhau, khai báo attribute thì nên khai báo ở đầu lớp.

Objects and Data Structure

Ta phải khéo phân biệt giữa Objects và Data Structure. Từ đó, ta mới có thể xác định được khi nào cần dùng objects khi nào thì cần dùng data structure và phải tránh sử dụng dạng hybrid.

Giả sử ta có dòng code sau đây:

type Vehicle interface {
  float64 getFualTankCapacityInGallons()
  float64 getGallonsOfGasoline()
}

Khi nhìn vào đây, Vehicle là một interface định nghĩa các function nhưng thật chất nó lại public ra các thông tin bên trong như đây là xe xăng Gasoline và có đơn vị tính là Gasllons. Nếu ta tạo một instance là xe điện thì sẽ như thế nào?

Có hai phong cách code là theo hướng function và hướng đối tượng. Nếu ta sử dụng data structure thì sẽ theo hướng procedural code. Và ngược lại, nếu ta sử dụng OO code thì ta sẽ sử dụng objects. Cả hai đều có ưu và nhược điểm riêng:

• Procedural code: sẽ rất dễ thêm function mới, nhưng khi ta thêm một đối tượng mới thì sẽ khó khăn hơn.
• OO code: sẽ rất dễ để tạo ra thêm một đối tượng mới, nhưng khi thêm một function mới thì sẽ khó khăn hơn.

Có một nguyên tắc là theo The Law of Demeter, tức là nếu ta có function f thuộc class C thì function f chỉ có thể gọi các hàm của các đối tượng sau:

• C
• Các object được tạo bởi f
• Các object được truyền vào f
• Các object trong C đang giữ

Tránh cho một chuỗi gọi objects liên tiếp mà C hay f không biết:

outputDir := ctx.GetOptions().GetScratchDir().GetAbsolutePath()

Thay vào đó, ta có thể chuyển đổi thành:

outputDir := ctx.GetAbsolutePathOfScratchDirOptions()

Hoặc nếu Options, ScratchDir là các data structure thì ta có thể gọi như sau:

outputDir := ctx.Options.ScratchDir.AbsolutePath

Bởi vì các thuộc tính trong data structure là public cho nên ta sẽ cho phép gọi. Luật chỉ áp dụng cho objects, không áp dụng cho data structure.

Còn một loại data structrue khá đặc biệt là data transfer object (DTO) chuyên trách để chuyển dữ liệu. Với DTO thì ta có thể có thêm một số function đặc biệt như save thì sẽ cho phép. Nhưng các function của DTO không cho phép chứa business bên trong.

Nhận xét ban đầu

Đây là cuốn sách nên đọc cho bất kỳ lập trình viên nào muốn nâng cao kỹ năng viết code. Thay vì cứ chạy theo trend công nghệ mới, thì ta nên bắt đầu từ những thứ đơn giản nhất là viết code sạch và dễ hiểu. Khi đọc sách, bạn sẽ hiểu rõ lý do của từng vấn đề mà các lập trình viên hay mắc phải và đưa ra các quy ước để giải quyết các vấn đề đó. Cuốn sách không chỉ How mà còn trả lời câu hỏi Why.