Nếu chăm chỉ đọc blog của mấy developer giỏi và nổi tiếng (như Uncle Bob, Martin Fowler, John Skeet), các bạn sẽ thấy họ có rất nhiều guideline để viết code cho tốt:

• Sử dụng nguyên lý SOLID để code tách bạch, rõ ràng, dễ sửa chữa
• Sử dụng Seperation of Concern và các mô hình phổ biến như MVC, MVVM để phân tách code thành nhiều thành phần nhỏ, dễ quản lý
• Áp dụng design pattern để giải quyết các vấn đề trong code
• Viết code phải viết thêm test để đảm bảo code chạy đúng

Làm và áp dụng theo những guideline này, chúng ta có thể có code… đúng chuẩn (có thể thôi nhé).

 

Tuy nhiên, trên thực tế, đa phần code trong các dự án đều khá … tởm. Code không có architecture rõ ràng, không có design pattern, viết cẩu thả. Nhiều khi đọc code xong, ta chỉ muốn đập đi xây lại, viết lại cho… đúng chuẩn.

Tuy nhiên, đã bao giờ bạn tự hỏi: Liệu viết code SOLID, chuẩn này chuẩn kia, DI/IoC đồ có thật sự làm code tốt lên hay không? Liệu ta có nên đảm bảo code viết ra phải cực kì hoàn hảo, phải có trật tự?

Thế nào mới là code tốt, code chuẩn?

Mỗi người sẽ có 1 định nghĩa riêng, nhưng hẳn nhiều người đồng ý với mình, Code Tốt có những đặc điểm sau (tính theo độ quan trọng):

• Chạy đúng như yêu cầu functional và non-functionnal
• Code không có bug hoặc ít bug so với toàn bộ dự án
• Code sạch (clean), tên hàm tên biến tách bạch rõ ràng ngắn gọn.
• Code có structure rõ ràng, đơn giản.
• Dễ đọc dễ hiểu, dễ tìm bug, dễ bảo trì và mở rộng

Đôi khi, chúng ta mải lo lắng về viết code phải dùng chuẩn này chuẩn nọ, phải đúng pattern nọ kia, mà quên mất điều quan trọng nhất: Code phải chạy đúng. Code có đẹp đến mấy, có structure tốt đến mấy mà chạy sai, chạy quá chậm, chạy bị lỗi cũng vứt.

Khi Code Chuẩn chưa chắc đã là Code Tốt

Để cảm nhận được điều này, bạn hãy thử đọc đoạn code Hello World dưới đây

Đoạn code này … khá chuẩn, có sử dụng Dependency Injection, tuy nhiên, code dài lòng thòng lê thê, đọc để hiểu flow chương trình cũng khá là mệt não.

Gần đây, trong cộng đồng front-end cũng có nhiều bình luận tương tự về Redux. Structure của Redux khiến code được phân tách thành nhiều thành phần nhỏ, dễ debug hơn.

Nhưng bù lại, để làm một chức năng đơn giản các bạn sẽ phải đụng đến khoảng 5, 6 file từ view, action, reducer, service (để sửa cũng vậy luôn).

Với những ứng dụng lớn, nhiều component với flow phức tạp, dùng Redux khá phù hợp. Nhưng với những ứng dụng đơn giản, flow chỉ thêm bớt xóa sửa, áp dụng Redux chỉ tổ tốn thời gian (thời gian học và code) của lập trình viên.

Các bạn thấy đó, code lúc này có cấu trúc rõ ràng chuẩn mực, nhưng đọc code mất thời gian, mở rộng chỉnh sửa code cũng mất thời gian nốt.

Vậy anh developer phải làm sao?

Là một developer giỏi, các bạn sẽ nhận ra rằng: Đôi khi Code Chuẩn chưa hẳn đã là Code Tốt. Nếu chưa tin lời Code Dạo chém gió, bạn có thể xem thêm bài Too Clean của Uncle Bob (Tác giả cuốn Clean Code) .

Theo ông, code không cần phải quá clean. Viết code clean là cần thiết, nhưng đôi chỗ ta có thể viết code không chuẩn để dễ xử lý vấn đề hơn, dễ mở rộng thay đổi hơn

When I write code I fight very hard to keep it clean. But there are also little places where I break the rules specifically because those breakages create affordances for transient issues.

Nhắc lại câu nói ở đầu bài viết: Code bạn viết ra sẽ méo bao giờ hoàn hảo hoặc hoàn toàn clean đâu. Nhưng như vậy cũng không sao. Nhiều khi, ta sẽ phải chấp nhận viết code.. không chuẩn, để giúp code gọn hơn, dễ đọc dễ sửa hơn nhé.

Note: Nếu các bạn cảm thấy nội dung trong bài hơi trừu tượng hoặc khó hiểu, hãy thử kinh qua vài dự án, từ bảo trì cho tới lúc code từ đầu, sau đó quay lại đọc nhé. Lúc đó bạn sẽ thấm điều mình muốn chia sẻ nhen.