CLEAN CODE

Giới thiệu

Như cái tên “Clean Code”, đây là cuốn sách hướng dẫn các bạn developer viết ra “code sạch“.

Thế nào là code sạch? Theo định nghĩa của sách, đó là code dễ đọc, dễ hiểu, dễ sửa chữa và bảo trì.

Có bạn sẽ xì mũi bảo: Giời, có gì đâu, cái đấy ai code chả được. OK! Mời bạn thử xem lại source code của 1 project mình đã làm cách đây 3-6 tháng xem, có hiểu được mình viết gì ko? Nếu không tức là code của bạn chưa được sạch.

Đa số developer đều code “không được sạch”, có nhiều nguyên nhân dẫn đến chuyện này. Từ nguyên nhân chủ quan như: nghĩ mình trình cao, không biết code, code đại … cho tới khách quan như: bị leader dí deadline, code cho xong, sau này rảnh optimize sau (“Sau này” đối với developer là “không bao giờ“). Đôi khi bạn vào 1 dự án cũ, thấy 1 đống bầy nhầy. Bạn sẽ phải vừa mò code vừa chửi cái thằng developer cũ vì nó code vừa ngu vừa khó hiểu. Đó là hậu quả của việc “code không sạch”.

 

Bài học rút ra

• Tầm quan trọng của việc viết “code sạch”.
• Cách đặt tên biến, tên hàm. Tên biến, tên hàm phải nói rõ tác dụng của hàm và biến. 

Vâng, ghét kiểu đặt tên biến int a, b, c hoặc đặt tên hàm tối nghĩa.

• Độ dài của hàm, các parameter truyền vào.

1 hàm đừng nên dài quá 1 trang A4, cũng đừng nên có quá nhiều parameter. Thử đọc 1 hàm dài khoảng 800 dòng code các bạn sẽ biết cực chừng nào.

• Tại sao không nên lạm dụng comment.

Comment không phải xấu, nhưng nhiều người viết code không sạch, sau đó dùng comment để nói đoạn code đó làm gì.

Sách khuyên ta nên viết code tự comment, tức là đoạn code đã trong sáng tới mức đọc là biết code làm gì, comment chỉ nên dùng để bổ sung những điều không giải thích được qua code (VD: đoạn code này để fix bug abc, dùng thuật toán này vì lý do bcd).

• Hướng dẫn cách viết và dùng unit test.
• Giải quyết 1 số vấn đề liên quan tới concurrency.
• Một số ví dụ cụ thể về việc refactor code

Phần này khá hay, biến code rởm thành code sạch thông qua các biện pháp refactor.

• Một số dấu hiệu nhận biết code smell

Phần này cũng khá hay, bạn có thể đọc và dựa theo các dấu hiệu này để tìm những đoạn “code rởm” trong project hiện tại.

Lời khuyên

Ngay khi vừa ra trường hoặc đã code được khoảng 2-3 tháng, bạn nên đọc cuốn này để tạo dựng những thói quen tốt cơ bản khi code. Sau khi code được khoảng 1-2 năm, hãy đọc lại 1 lần nữa để nghiệm lại những điều mình chưa hiểu lần đầu đọc. Hai câu nói mình tâm đắc nhất trong sách sau khi đọc:

1. Code cho máy đọc thì ai cũng viết được, code cho người đọc thì chỉ có developer giỏi mới viết được.
2. Đứng ở góc nhìn của một developer bảo trì code sau này, cứ tưởng tượng sau khi họ đọc những dòng code bạn viết …. Họ sẽ làm gì bạn. Giờ nhiều developer code cho xong function rồi để đó.

 

 

Emanvn | Phạm Huy Hoàng