Clean code #1: Clean code là gì?

1. Famous quote:

2. Why should you care?

Chúng ta thường có nhiều lí do, sự biện minh để bỏ qua việc uốn nắn (clean) cho code của bản thân trong quá trình phát triển như:

Sếp của tôi yêu cầu phải phát triển nhanh tính năng (feature)
Tôi không có thời gian để suy nghĩ về các quy tắc đặt tên, những cái tên hay,...
Tôi lười biếng lắm.
Tôi nghĩ việc đó là không cần thiết và tôi không quan tâm, miễn sao project tôi chạy tốt là được.
etc...

Nhưng sau 1 khoảng thời gian (có thể là 3 tháng - 1 năm) chúng ta không còn nhận ra code của chính mình.

Việc bảo trì (maintain) lúc này thật sự là rất khó khăn.
Thêm một tính năng mới dựa trên các tính năng cũ rất tốn thời gian và phát sinh nhiều lỗi vặt.
Các đồng nghiệp xung quanh luôn phải hỏi tác giả của những dòng code đó về ý tưởng code của họ, và các cuộc tranh luận xảy ra gây tốn rất nhiều thời gian của các bên.
etc...

✅ Clean code được tạo ra để đề xuất các kĩ thuật, phương pháp làm cho code của bạn viết trong quá trình phát triển dễ đọc hơn từ đó dễ dàng bảo trì hơn. Qúa trình phát triển phần mềm có thể trở nên nhanh hơn vì code tường minh, đồng nghiệp dễ đọc và thực hiện tiếp công việc của họ => Giảm thiểu thời gian giao tiếp về code, qua đó thúc đẩy quá trình phát triển sản phẩm.

3. Three Principles for Clean Code

1. Right tool for the job

Bạn phải biết về “ranh giới” giữa các công nghệ. Hiện nay, có rất nhiều ngôn ngữ lập trình (C#, Java, Go, Dart, ...), ngôn ngữ truy vấn dữ liệu (Postgress, MySQL, Mongo,...), định dạng trao đổi dữ liệu (Json, XML,...). Việc chọn đúng công cụ (tool) để lập trình là rất quan trọng. Ví dụ như code C# thì nên dùng IDE Visual Studio, Go thì nên dùng IDE Goland,... biểu diễn dữ liệu nên cần các plugin format để cho JSON/XML dễ nhìn hơn. Giúp ích rất nhiều cho việc lưu trữ, code color (màu sắc của các biến, các keywork của ngôn ngữ lập trinh, ...), check các Syntax, ...

Các project ngày nay thường có chứa nhiều ngôn ngữ khác nhau trong cùng 1 project (E.g: Project về web xây dựng bằng ASP.NET có thể có thêm HTML, CSS, JS) và các định dạng dữ liệu như JSON hay XML. Vì vậy chúng ta phải chọn công cụ phù hợp cho Project của mình.

Lưu ý: Chỉ nên có 1 ngôn ngữ trên một file.

2. High signal to noise ratio

Signal: Logic code nên

Ngắn gọn: Hạn chế tạo ra các class/method quá dài. Não chúng ta cảm thấy phù hợp và an toàn khi đọc những thứ ngắn gọn, không quá dài. Nếu chúng ta bắt gặp 1 method hay class qúa dài, não chũng ta dễ nảy sinh tâm lý sợ hãi hoặc ngán ngẫm việc phải đọc nó. Vì vậy hãy cố gắng viết càng ngắn gọn càng tốt, nếu không thể hãy chia nhỏ các class/method ra.
Biểu cảm: Code nên thể hiện suy nghĩ, cảm xúc của tác giả, có thể qua các comment. Điều này giúp người đọc ấn tượng và hình dung tốt hơn về chức năng của code
Làm 1 việc: Code của bạn chỉ nên làm 1 chức năng duy nhất, điều này được mô tả trong nguyên tắc Single Responsibility Principle trong SOLID sẽ được diễn giải kĩ hơn ở những phần sau.

Noise: Logic code nên tránh

Code quá phức tạp
Thụt lề quá mức
Zombie code
Các comment không cần thiết hoăc quên xoá comment khi đã loại bỏ tính năng
Đặt tên class/method/varriable quá kém
Tạo nên các Class quá to
Tạo ra các method quá dài
Lặp lại code (nguyên tắc DRY) Don't repeat yourself
Không có khoảng trắng (code dính liền nhau, không có khoảng trắng phân tách các dòng)
Dòng (Line code) quá dài (1 line code quá dài, thậm chí tràn ra khỏi màn hình)

Signal to noise ratio là rất quan trọng vì não chúng ta là 1 trình biên dịch và sự lộn xộn thì được xây dựng một cách rất lặng lẽ.

3. Self-documenting Code

Nếu bạn viết code tốt, clean thì code của bạn có khả năng tự ghi chú. Để làm được điều đó, code của bạn cần thoả mãn các tiêu chí:

Ý định rõ ràng
Định dạng để dễ đọc
Các lớp (layers) phải trừu tượng (abstractions)
Code nên được ưu tiên hơn comment (Nếu bạn viết code tốt thì bạn không cần viết comment để giải thích về code nữa)

Cảm ơn bạn đã đọc hết bài viết. Nếu thấy hay hãy để lại mình 1 vote và hẹn gặp lại trong bài viết tiếp theo! 🚀

iPhone #AppMobile