Hôm nay bỗng dưng không có hứng viết bài về technical, thôi thì lôi đại cuốn này ra review vây. Mình đọc cuốn này trong thời gian còn làm việc ở FPT Software (Làm việc lúc nào cũng dư thời gian nên toàn lôi ebook ra đọc. Cuốn sách này xứng đáng là sách gối đầu giường của mọi developer. Mình khuyên các bạn nên mua bản gốc, 1 là để đọc, 2 là nếu gặp thằng nào code ngu, có thể cầm cuốn này đập vào đầu nó và bắt nó đọc.

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 suorce 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 la code của bạn chưa được sạch lắm đâu =))).

Đa số developer đều code “không được sạch” (cả mình ngày xưa vẫn thế), 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 tổ tông tám đời nhà 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”.

Vì nãy giờ toàn khen nên cũng không muốn nhận xét gì nhiều, mình chỉ tóm tắt vài điều hay bạn có thể học được trong 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, những thằng mình muốn chọi gạch là những thằng đặ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 nay để tìm những đoạn “code rởm” trong project hiện tại =))).

Lời khuyên của mình: 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. Hãy code như thể thằng developer bảo trì code của bạn là 1 thằng sát nhân bệnh hoạn biết địa chỉ nhà của bạn. (Hiện giờ nhiều developer code cho xong function rồi để đó. Cứ tưởng tượng thằng developer bảo trì code của bạn mà đọc những dòng code bạn viết …. sẽ làm gì bạn sau khi đọc code bạn viết. Mình là mình cũng từng muốn cầm dao lụi mấy thằng developer cũ của team nhiều lần lắm đấy).