Review sách clean code(mã nguồn sạch), tóm tắt nội dung clean code tiếng việt

Để viết “Code sạch” luôn là điều làm đau đầu người viết code – lập trình viên. Viết code để cho mình hiểu đã khó, việc viết để cho cả người khác có thể dễ đọc, dễ hiểu, dễ sửa chữa và bảo trì còn khó hơn nữa.
Viết Code sạch – clean code không chỉ là một điều “nên làm” mà còn là một điều “phải làm” với coder. Bạn hãy thử tưởng tượng 1 ngày bạn nhận bàn giao 1 project nhỏ xinh với mớ code rối bù, liệu bạn có muốn đấm một phát chết luôn thằng dev cũ hay không. Cuốn sách clean code sẽ giúp bạn có cái nhìn về mã sạch và những vấn đề gặp phải?

Nếu bạn muốn viết code sạch, Clean Code : “ A Handbook of Agile Software Craftsmanship ” chính là cuốn sách mà bạn nên đọc ngay ngày hôm nay .

Thông tin về ebook “Clean Code”

• Tên tài liệu : Clean Code: A Handbook Of Agile Software Craftmanship
• Tác giả sách : Robert C.Martin
• Số trang : 462
• Ngôn ngữ : Tiếng Anh
• Format : PDF
• Thể loại : Programming

CUỐN SÁCH NÀY DÀNH CHO AI?

Clean code là một trong những cuốn sách kinh điển mà mọi developer(lập trình viên) đều nên đọc, tìm hiểu về nó để việc lập trình được tốt hơn.

Cuốn sách phù hợp với những bạn vừa ra trường hoặc đã có kinh nghiệm code khoảng 1-3 tháng. Cuốn sách clean code sẽ tạo cho bạn những thói quen tốt khi code ngay từ ban đầu, tránh việc ‘quen tay” code xấu, code linh tinh. Các bạn đã có kinh nghiệm code lâu hơn, 1-2 năm chẳng hạn cũng nên đọc cuốn sách này để rút ra kinh nghiệm cho mình, nhận ra được lỗi sai và có phương pháp khắc phục nó.

Bạn nên đọc lại cuốn sách này mỗi 1-2 năm 1 lần để hiểu thêm những thứ mình chưa hiểu, có thể tham khảo những bản clean code bằng tiếng việt giúp bạn dễ đọc hơn:

CUỐN SÁCH NÀY DẠY BẠN ĐIỀU GÌ?

• Tầm quan trọng của việc viết “code sạch”- clean code.
• Cách đặt tên biến, tên hàm trong lập trình. Tên biến, tên hàm phải nói rõ tác dụng của hàm và biến thay vì chỉ là những kí tự a, b, c, x, y, z chung chung và vô nghĩa.
• Độ dài khuyên dùng của hàm, các parameter truyền vào.
• Tại sao không nên lạm dụng comment, thay vì code ẩu rồi comment loạn xạ, chúng ta nên    code sạch và dùng comment để giải thích những điều không thể trình bày qua code.
• 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 – clean code thông qua các biện pháp refactor.
• Một số dấu hiệu nhận biết code smell – nhận biết code xấu thông qua một số dấu hiệu điển hình.

BẠN CÓ THỂ ĐỌC CUỐN SÁCH NÀY Ở ĐÂU?

Nếu có điều kiện và khả năng, bạn nên mua sách gốc để ủng hộ tác giả: “Clean Code: A Handbook of Agile Software Craftsmanship”.

Hoặc bạn có thể lên google tìm và tải file clean code .pdf để đọc tham thảo. Hay những blog có dịch sang bản tiếng việt.

Link dowload file pdf sách clean code tại đây

BÀI HỌC RÚT RA TỪ SÁCH CLEAN CODE:

• Tầm quan trọng của việc viết mã 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.
• Độ dài của hàm, các parameter truyền vào.
• Tại sao không nên lạm dụng dùng comment.
• Một số ví dụ cụ thể về việc refactor code.
• 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ố dấu hiệu nhận biết code smell.

GIỚI THIỆU SÁCH VÀ CẤU TRÚC CLEANCODE

Làm cách nào để viết ra những dòng code tốt ? Bạn đã khi nào nghĩ tới việc bản thân trở thành những expert, am hiểu nâng cao, code viết ra đọc qua là hiểu chưa ?

Để đạt tới trình độ đó, chúng ta phải có 2 thứ: sự hiểu biết và sự chăm chỉ. Giống như việc tập xe đạp, dù bạn có biết hết các nguyên tắc đạp xe, thậm chí cả những thứ cao siêu hơn như lực hút trái đất, động năng,… thì bạn vẫn cần ngồi lên xe để biết đi xe và đi tốt. Cuốn sách này cũng thiết kế theo hướng đó, với các đoạn code được minh hoạ xen lẫn nội dung, chúng ta nên đọc các ví dụ để hiểu thêm về khái niệm được đưa ra, và có lẽ tốt hơn hết, vẫn là sau đó liên hệ với những dòng code bạn viết gần đây nhất.

Cuốn sách được chia làm 3 phần:

• Phần 1: nói về cách phân biệt good code/bad code, những nguyên tắc tạo nên good code, bao gồm: đặt tên, cách viết và cấu trúc function, comment, format của code,… Đây là phần nền tảng của sách.
• Phần 2: (nhưng lại nằm trong phụ lục): các case study. Theo giới thiệu, đây sẽ là các case rất phức tạp, và sẽ mất rất nhiều thời gian để hoàn thành phần này. Có vẻ đây là các dự án thực tế, rất dài (do đó cũng sẽ rất phức tạp).
• Phần 3: bao gồm rất nhiều ví dụ minh hoạ cho các lỗi thường gặp.

Tổng kết chương 1: Clean code

Có nhiều ý kiến về vấn đề clean code này, có người thì đồng tình và cũng có người thì phản đối. Có nhiều ý kiến cho là: Code thì ai chẳng code được, code kiểu gì mà chẳng được chạy là được rồi…

Những quan điểm này cũng hoàn toàn có thể đúng, ví dụ như thể dự án Bất Động Sản mà làm 1 lần và không khi nào quay trở lại chỉnh sửa gì cả. Nhưng, cuộc sống không như là mơ, hiếm khi mà có dự án Bất Động Sản nào làm xong và vứt đó cả .
Những dòng code tệ hại Open khắp nơi. Khi nhìn lại dự án Bất Động Sản mình vừa hoàn thành xong, mình thấy đó là 1 đống rác, rác của mình viết, rác của người khác viết, rác của người khác viết mà mình thay thế sửa chữa, … Thật may, về cơ bản những tính năng của nó vẫn ổn, bảo vệ nhu yếu của người mua, tuy nhiên mình không dám nghĩ tới tăng trưởng thêm dựa trên những dòng code đó nữa. Biết là tệ hại, vậy vì sao tất cả chúng ta lại viết ra bad code ?

• Mình cho rằng, yếu tố tác động lớn nhất là thời gian: đôi khi, bạn có deadline dí sát đít, và bạn phải thức trắng đêm để cố gắng hoàn thành. Bạn hoàn thành trễ, hoặc may mắn là vừa kịp, chỉ test xong đã là cả 1 điều kỳ diệu, thì làm sao để kịp sửa chữa nó đây? Cá nhân mình thấy, đây là lỗi của manager hơn là của bạn.
• Vì bạn lười. Bạn khó mà bận tối mắt cả dự án được, sẽ có những khoảng thời gian bạn rảnh rỗi, nhưng bạn lại chẳng ngồi rèn luyện kỹ năng, hay chỉnh sửa code.
• Vì bạn đã chán dự án tới tận cổ, và bạn chẳng thèm sửa nữa, chỉ mong nhanh nhanh chóng chóng cho xong.
• Dù sao mấy lý do trên cũng đỡ tệ hại hơn việc vì 1 số đoạn code quá mức tệ hại, tới mức bạn không thể nào sửa nổi nếu không thay đổi rất rất nhiều kết cấu chương trình. Đây chắc chắn là lý do tồi tệ nhất và cũng là lý do không được đón chờ nhất.

Kết Lại:

Chúng ta đều biết, bad code không tốt. Nhưng không tốt tới mức nào, liệu nó có ảnh hưởng tác động tới đâu lại là 1 câu hỏi khó vấn đáp. Tác giả cho rằng, thời hạn dùng để đọc code so với thời hạn dùng để viết code là 10 : 1. Chúng ta cần đọc, tâm lý rất nhiều trước khi viết code. Để giảm thiểu thời hạn, tất cả chúng ta nên giảm thiểu thời hạn đọc chứ không cần phải viết code hấp tấp vội vàng, hấp tấp vội vàng viết ra những dòng code tệ hại là tham bát bỏ mâm mà thôi .

Vậy, thế nào là code sạch?

Khi nhìn 1 bức tranh, bạn sẽ tự cảm nhận được nó đẹp hay không. Khi quan sát nhiều hơn, bạn sẽ tự phân biệt được xấu đẹp, nhưng việc vẽ ra những bức tranh đẹp lại khó hơn rất nhiều. Viết code cũng vậy, cảm nhận code sạch thì không khó, nhưng viết ra code sạch lại khó. Dù sao tất cả chúng ta cũng cần có những khái niệm, dù mơ hồ về việc thế nào là code sạch .

Sau khi tổng hợp ý kiến của 1 số chuyên gia, chúng ta có thể rút ra vài đặc điểm của code sạch như sau:

• Phải có logic rõ ràng.
• Phải đạt performance tốt, tốt nhất là gần với mức tối đa (so với thuật toán).
• Người khác có thể đọc, cải tiến, bảo trì được dễ dàng, dễ đọc và sữa chữa.
• Chạy tốt các test.
• Không có các phần trùng lặp về chức năng.
• Nội dung code giống với những gì bạn dự kiến (câu này có thể hơi khó hiểu, trong chương 3 function sẽ được nói kỹ hơn).
• Giảm bớt số lượng tất cả: class, function, variable,…

Bạn có thể tham khảo mua sách clean code ebook ở đây:

Link mua sách clean code tại LAZADA: 

Bài viết liên quan

Source: https://final-blade.com
Category : Kiến thức Internet