Những nguyên lí cơ bản của chủ nghĩa code sạch

Posted by Dev Nhà Người Ta on 2017-09-23
Code sạch nhà người ta

clean-code

Code sạch là

Code không bốc mùi (smell code 💩). Nhìn lại hình ở trên tí nhé ☝️, chất lượng của code được đo bằng đơn vị số lần wtf mỗi phút. Bạn viết code sao mà những người review, dev khác không phải thốt lên wtf như vậy là sạch 😀

Tại sao phải code sạch?

Ờ, đó là trách nhiệm của bạn mà 😎.
Codebase cũng giống như database của một website vậy, tỉ lệ đọc:ghi thường là 10:1. Mọi người ai cũng phải đọc được code rồi mới viết code phải không nào? Vì vậy, hãy viết code sao cho người khác (hoặc chính bạn trong tương lai) có thể đọc hiểu được.

Mục đích của code sạch:

  • Thay đổi code nhanh hơn
  • Đọc hiểu code dễ hơn

Bạn không muốn mất 2h để đọc hiểu một module đáng lẽ chỉ cần đọc trong vài phút chứ?

Những nguyên lí cơ bản của chủ nghĩa code sạch

1. Đặt tên

Mọi thứ đều có tên. Chúng ta đặt tên cho mọi thứ. Tên để nhận dạng một đối tượng.
Okie, vậy tôi nên đặt tên trong code của tôi như thế nào? Có vài điều nên chú ý sau:

  • Tên phải mô tả được đối tượng (biến đó lưu cái gì, hàm đó làm gì, class đó là gì,..)
  • Tên có thể tìm kiếm được.
  • Tránh sử dụng từ viết tắt, từ dễ gây nhầm lẫn.

Xem thêm bài về việc đặt tên ở đây nhé.

2. Comment

Code never lies. Comments sometimes do.

Vâng, code thì không bao giờ nói dối bạn, còn comment thì có đấy. Bạn đã bao giờ gặp trường hợp code một đường, comment cho đoạn code đó một nẻo chưa?

Bạn không cần phải có comment. Yeap, tên là tài liệu đầy đủ và tốt nhất rồi :), không cần thêm comment, chú thích làm gì nếu bạn không thật sự cần.

Trong trường hợp vẫn cần comment, hãy:

  • Cố gắng giải thích bằng code của mình, đừng comment 😀
  • Viết comment ngắn gọn, đừng dư thừa.
  • Đừng comment code không dùng, hãy xoá nó luôn đi.

3. Format

Ông bà ta nói “tốt gỗ hơn tốt nước sơn”, cơ mà không phải lúc nào cũng lo chọn gỗ tốt mà không quan tâm đến nước sơn. Ai chả thích cái đẹp cơ chứ 😛. Code cũng vậy, dù bạn có viết tốt như thế nào, mà trình bày code xấu tệ thì.. cũng chưa sạch được.

Gần đây mình có đọc bài viết về tại sao DHH - cha đẻ của Rails từ chối 80% ứng viên (bài viết tại đây). Có một ý trong đó nói về “Your code looks terrible!”. Nếu là người tuyển dụng, mình cũng sẽ không tuyển những người trình bày code xấu như hình dưới đây :)

terrible format

Để trình bày tốt hơn, có một số lưu ý như:

  • Sử dụng một loại indentation thống nhất, tab cũng được, space cũng được, miễn sao thống nhất với nhau.
  • Để ý đến số kí tự mỗi dòng, số dòng của mỗi class.

Về cấu trúc của source code:

  • Phân biệt các phần theo chiều dọc.
  • Các hàm phụ thuộc hoặc tương tự nên được đặt gần nhau.
  • Đặt các hàm của bạn theo thứ tự trên xuống.

4. Test, test, test và test

Test để đảm bảo code của bạn chạy đúng như mong đợi.

Áp dụng luật FIRST cho test:

  • Fast: test phải chạy nhanh
  • Independent: test phải không phụ thuộc lẫn nhau
  • Repeatable: chạy được ở những môi trường khác nhau
  • Self-Validating: test phải có một output, là pass hay failed.
  • Timely: test code phải được viết trước khi viết production code.

5. Khô thoáng

Code của bạn phải luôn luôn khô thoáng, à nhầm, DRY nhé.
DRY là viết tắt của từ Dont't Repeat Yourself, tức là đừng lặp lại chính mình.

Đừng viết lại những đoạn code giống nhau ở những chỗ khác nhau. Điều này sẽ làm cho việc maintain khó khăn hơn, bạn sẽ bị thiếu khi sửa code ở chỗ này nhưng lại quên ở chỗ khác, và tất nhiên đây là một nguyên nhân gây ra bug 🐛.

Mỗi khi thấy mình phải viết những đoạn code giống nhau ở những nơi khác nhau, đó là lúc bạn nên tìm cách refactor để luôn DRY nhé.



Comments: