Clean Code Series - Part 1: Introduction

Clean Code - A Handbook of Agile Software Craftsmanship - Robert C. Martin, một trong những cuốn sách gối đầu giường dành cho các lập trình viên. Luôn nằm trong top các quyển sách được recommend cho giới lập trình viên. http://blog.itviec.com/7-programming-book/ https://techmaster.vn/posts/33900/bi-kip-lap-trinh-vien http://www.codingdojo.com/blog/9-best-programming-books-read-right-now-want-distinguish/ https://dzone.com/articles/must-read-book-list-for-programmers Ở trên amazon, cuốn sách đạt rating 4.5 stars do hơn 300 customers review, và là #1 Best Seller trong Software Testing.

Nhiêu đó đã đủ để bạn bật chrome lên, vào amazon và order ngay cuốn sách này chưa? Nếu chưa, hãy cùng tôi đi hết những bài viết thuộc series Clean Code. Những bài viết thuộc series này một phần là để review cuốn sách, phần còn lại là để nói lên những suy nghĩ, trải nghiệm bản thân sau khi đọc cuốn sách, để biết rằng những dòng code của tôi đã thay đổi thể nào sau từng trang sách. Do những gì trong series bài viết đã bị ảnh hưởng bởi tư duy và quản điểm của cá nhân tôi, nên nếu bạn muốn học và trải nghiệm những thứ tinh túy và trọn vẹn nhất, hãy lên amazon và order ngay lập tức cuốn sách này.

Introduction

Mình không có nhiều kiến thức về Hy Lạp cho lắm, nhưng mình đoán đây là đền Parthenon, ngôi đền thờ thần Athena, một trong các kiệt tác kiến trúc nối tiếng nhất ở Hy Lạp, còn người đang ngồi "giặt" code là ai thì mình chịu. Quan trọng là dòng chữ dưới cùng mà tác giả muốn nhắn nhủ:

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

Có lẽ code đến một giai đoạn nào đó, bạn sẽ hiểu ra rằng, code để máy hiểu là một điều quá đỗi bình thường, code để người hiểu mới khó. Đây cũng chính là một trong các đặc điểm phân biệt junior và senior.

Bad Code

Có bao giờ bạn code xong một feature, rồi 2 phút sau nhìn lại và không hiểu mình vừa code gì không? Đã bao giờ bạn track bug, và nhận ra rằng luồng hoạt động của nó đi qua khoảng 10 layer chưa. Hoặc đơn giản hơn, nhìn vào 1 file với khoảng 800 dòng code, đọc một function với khoảng ...100 dòng code chưa. Một function update product trong một dự án cũ của tôi Function này dài ... gần 200 dòng (từ line 634 -> 829). Và bạn biết file controller này bao nhiêu dòng code không? 955 dòng code Tôi đã trải qua tất cả những điều trên, và tôi tin rằng đa phần các bạn đã, đang và sẽ phải trải qua. Lập trình hay bất kì ngành nghề nào khác đều phải trải qua các bậc thang, các level để có thể thành thạo nó. Và những nấc thang đầu tiên chính là những vấn đề tôi đã đề cập ở trên.

Khi mới chập chững biết code, mục tiêu duy nhất của tôi là ... làm nó chạy. Tôi đã từng code những dòng mà chỉ ngay hôm sau thôi, đọc lại và chẳng hiểu gì. Sẽ ra sao nếu project của chúng ta bắt đầu bằng những dòng code như thế? Sau mỗi sprint, bug càng ngày càng nhiều, sửa 1 sinh 2, load time tăng, crash ngày càng nhiều, phần mềm trở nên cồng kềnh, làm bất cứ cái gì cũng sinh ra bug, rồi đến một ngày bạn nhận ra mình không còn khả năng maintain hay develop new feature nữa, bạn sẽ hối hận khi vấn đề bắt nguồn từ vài dòng code như thế.

Biết là ta đang viết bad code, nhưng vì sao chúng ta vẫn cứ làm: bởi thấy không cần thiết, bởi deadline gần kề, bởi người khác không làm thì mình có làm cũng chẳng để làm gì, bởi không biết viết clean code, bởi tôi sẽ làm sau, ... Chúng ta có đủ loại lí do cho việc này, refactor code sau là một trong các lí do phổ biến nhất, cần nhanh chóng tạo ra sản phẩm để còn có cái mà ăn nói với khách hàng, nhưng tin tôi đi, hoặc ít nhất là hãy tin tác giả của chúng ta: Later equals never (Muộn đồng nghĩa với không bao giờ) Một team T tiến hành một project P, sau 2 năm, một vài thành viên out, project trải qua chục lần thay đổi requirement, productivity chạm gần đáy như hình trên. Lúc này, một vài thành viên mới tham gia vào team, họ đọc một đống messy code và ngay lập tức yêu cầu manager redesign. Manager (hoặc Project Owner) không muốn phải bỏ hết resource từ project cũ, nhưng cũng biết khó mà chấp nhập được mức low productivity như hiện tại, nên đã quyết định, sẽ tổ chức một cuộc thi giữa 2 team. Team T1 phát triển sản phẩm cũ còn Team T2 phát triển project lại từ đầu, những cũng phải đảm bảo các feature, requirement mới được update vào hệ thống.

Sau 2 năm, một vài thành viên team T2 ra đi, một vài người mới đến, và team T2 lại yêu cầu redesign hệ thống bởi không thể chấp nhận nổi code base. (facepalm)

Tôi tin rằng nhiều người trong số các bạn đã gặp phải chuyện thật như đùa này. Và đều sẽ hiểu rằng việc giữ hệ thống clean code không chỉ đảm bảo hiệu quả về mặt chi phí, nó là vấn đề sống còn của project.

Clean Code

Thế nào là clean code? Tác giả đã đi hỏi câu này với hàng loạt các nhân vật máu mặt trong ngành IT, nhưng mỗi người đều có một quan điểm và lập luận khác nhau. Riêng tác giả, ông đưa ra một định nghĩa khá lạ:

Schools of Thought

Mỗi nhân vật nổi tiếng trong ngành IT lại có một cách hiểu khác nhau về clean code, và thậm chí là khác hoàn toàn. Bạn không nhất thiết phải nghe theo họ. Cũng giống như theo học ở trường vậy, cùng một môn, một khái niệm, mỗi thầy cô sẽ đưa ra cho ta một định nghĩa khác nhau, không ai trong số họ là đúng tuyệt đối cả. Hay coi đó chỉ như những nguồn tham khảo để bạn tìm ra đúng định nghĩa cho bản thân, tương tự vậy với clean code. Giả sử như chúng ta nghe theo quan điểm của Ward Cunningham người sáng lập ra Wiki chẳng hạn:

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem

Thú thật là tôi cũng không hiểu lắm quan điểm của ông, nhưng cứ coi như bạn hiểu và làm theo quan điểm này. It's oke, nhưng trong quá trình làm việc, bạn nhất có gì đó thiếu sót, có gì đó sai sai, hãy thay đổi. Thay đổi và những trải nghiệm của bạn thân mới tạo nên một Clean Code phù hợp nhất với bạn - đó chính là Schools of Thought

Conclusion

Bản thân tôi cũng đang đi tìm định nghĩa Clean Code của chính bản thân mình, và mong rằng bạn cũng vậy. Nó là cả một quá trình, chứ không phải ngày một ngày hai, đọc dăm ba cuốn sách là xong. Trước khi kết thúc bài viết, tôi hỏi bạn 1 câu nhé: Theo bạn thì đọc và viết code, bạn làm việc nào nhiều hơn? Vâng, là Đọc code đấy, tỉ lệ tầm 10:1 (Theo tác giả). Bạn viết smell code, bạn hứng chịu hậu quả 10 lần. Đừng giày vò bản thân mình cùng đồng đội. Hãy viết Clean Code!