Clean code

Code là gì ?

Với lập trình viên, chắc hẳn không ai còn còn xa lạ gì với việc code, thậm chí chúng ta còn thường xuyên phải code xuyên màn đêm nữa. Đó là công việc cũng là đam mê của một lập trình viên chân chính .

Tuy nhiên, có bao giờ chúng ta nghĩ code của chúng ta đã thực sự tốt chưa, hay nói cách khác, code của chúng ta là Bag Code hay Good Code

Bag Code là gì ?

Đã bao giờ bạn cảm thấy khó chịu khi gặp một Bad Code chưa ? Nếu là một lập trình viên có chút kinh nghiệm, bạn chắc hẳn đã cảm thấy điều này nhiều lần. Khi đó chúng ta làm gì, chúng ta cố gắng lội qua đống bad code đó, chúng ta tìm mọi cách, hy vọng tìm ra chút gợi ý để giải thích cho vấn đề đang xảy ra, nhưng tất cả chỉ là ngày càng tìm thấy nhiều hơn những đoạn mã vô nghĩa.

Thực tế đúng là như vậy đấy, thế nhưng câu hỏi là "Tại sao chúng ta lại viết ra những bad code ?". Có phải vì:

• Chúng ta đang cố gắng viết code nhanh hơn ? Có lẽ đúng là vậy, bởi vì chúng ta không có đủ thời gian để làm việc một cách tốt nhất, trong khi sếp luôn luôn cau có nếu chúng ta mất quá nhiều thời gian cho việc clean code của mình.
• Chúng ta luôn cảm thấy mệt mỏi với công việc lập trình và muốn thoát khỏi chúng.
• Hay đôi khi bạn nhìn thấy những vấn đề còn tồn đọng bạn tự nhủ sẽ giải quyết khi xong mớ yêu cầu và ticket này đã, thể rồi bạn vứt chúng vô BackLog. Và tôi dám chắc mớ BackLog đó sẽ không khi nào được đụng tới nữa

Hầu hết lập trình viên đều gặp phải những vấn đề trên. Thậm chí chúng ta vẫn thường xuyên nhận ra mớ hỗn độn mình vừa thực hiện nhưng vẫn tặc lưỡi để sang hôm sau giải quyết nốt vì dù sao mớ hỗn độn đó vẫn làm việc được còn hơn là không làm được gì.

Cái giá phải trả cho mớ hỗn độn chúng ta tạo ra là gì ?

Nếu bạn là một lập trình viên có ít nhất 2-3 năm kinh nghiệm, bạn sẽ thừa nhận rằng mình bị công việc của mình bị chậm đi khi gặp những mớ hỗn độn này. Hay thông thường, trong khoảng 2-3 năm, hầu hết các team đều làm việc rất nhanh trong giai đoạn đầu dự án nhưng sau đó dần trở lên chậm chạp và trì trệ hơn rất nhiều.

Bởi lúc đó, mỗi sự thay đổi đều khiến code bị chia nhỏ ra thành nhiều phần hơn. Mỗi khi thêm hay thay đổi yêu cầu hệ thống, các rắc rỗi đều có thể được thêm vào. Dần dần mớ hỗn độn đó trở lên lớn hơn, tới mức chúng không thể clean được nữa.

Cùng với sự ra tăng các bad code, năng suất của team sẽ tiếp tục giảm xuống cho tới mức 0, thì để làm tăng hiệu suất làm việc, các boss sẽ bổ sung thêm nhân sự mới. Tuy nhiên, các nhân viên mới lại không biết rõ về design của hệ thống, do đó họ không biết được cần thay đổi như thế nào để phù hợp với thiết kế của hệ thống. Cộng với áp lực lớn về hiệu suất công việc khiến họ bắt buộc phải làm nhiều hơn, và phạm nhiều bad code hơn, cuối cùng dẫn tới năng suất giảm xuống về 0.

Phản ứng của chúng ta ra sao ?

Chúng ta luôn tự hỏi, vì sao code của chúng ta có vấn đề, tại sao ngày từ đầu code của chúng đã đã rất tốt (good code), thế nhưng chúng nhanh chóng bị biến thành bad code và sinh ra một mớ hỗn độn cho chính chúng ta ?

Có rất nhiều nguyên nhân cho vấn đề này:

• Do yêu cầu thay đổi theo những cách mà rất khác so với thiết kế chúng ta đưa ra ban đầu.
• Plan + due date + deadline cứ thúc chúng ta hàng ngày, chúng ta khó có thời gian để nghĩ tới việc clean code.
• Người quản lý ngu ngốc + khách hàng củ chuối + lũ marketing thì vô dụng luôn luôn bắt chúng ta phải làm theo bất kỳ đòi hỏi nào mà chúng ta cho rằng nó thật vô lý và không thể làm được nhưng vẫn phải làm.

Nhưng thực sự mà nói lỗi là ở chính bản thân chúng ta. Vì chúng ta không chuyên nghiệp.

Vì sao ư. Vì marketing thì luôn tìm chúng ta lấy thông tin để họ có thể thực hiện cam kết với Khách hàng, còn chúng ta thì nhút nhát khi nói về những gì mình nghĩ. Khách hàng thì tìm chúng ta để kiểm tra các yêu cầu có khớp với hệ thống hay không. Manager thì tìm đến chúng ta để giúp đưa ra kế hoạch. Vì thế tất cả mọi vấn đề đều có liên quan tới chúng ta, đặc biệt là các vấn đề về bad code.

Việc chúng ta phải làm đó là phải bảo vệ cho code của mình không trở thành bad code. Vì hầu hết các manager đều muốn có good code, mặc dù họ vấn muốn giữ kế hoạch và yêu cầu, nhưng đó là việc của các manager. Việc của chúng ta là bảo vệ code.

Lấy ví dụ cho vấn đề này, giả sử bạn là một bác sỹ, và có một bệnh nhân yêu cầu bạn dừng tất cả việc vệ sinh tay hay các dụng cụ y tế vì nó tốn quá nhiều thời gian. Ở đây, bệnh nhân là boss trả tiền cho bạn, nhưng là một bác sỹ bạn có đồng ý với đề xuất ngu xuẩn đó không ? Tất nhiên là không rồi, vì là một bác sỹ, bạn hiểu rõ hơn boss của mình những rủi rõ và nguy hiểm từ bệnh nhiễm trùng sẽ gây ra cho họ. Và thật không chuyên nghiệp nếu bác sỹ nghe lời yêu cầu của bệnh nhân.

Clean code ?

Tới đây bạn sẽ tự hỏi, "Làm thế nào để viết code clean hơn ?" Nhưng sẽ rất không tốt nếu bạn muốn clean code mà bạn lại không hiểu rõ code thế nào mới được gọi là clean. Tin xấu là việc viết code clean cũng giống như sẽ tranh vậy. Hầu hết mọi người đều có thể biết một bức tranh đẹp hay xấu, tuy nhiên không phải ai cũng có thể vẽ ra một bức tranh đẹp. Vì thế nếu bạn có thể tìm ra clean code từ dirty code thì không có nghĩa bạn có thể viết clean code.

Viết clean code yêu cầu việc sử dụng rất nghiêm ngặt một số kỹ thuật bằng một sự cẩn thận và chắc chắn, gọi là "code-sense". Một lập trình viên không có "code-sense" có thể nhìn thấy một mớ modun hỗn độn nhưng sẽ không làm gì để cải thiện nó. Một lập trình viên có "code-sense" thì có thể nhìn thấy các tùy biến và biến thể cho modun đó tốt hơn. "code-sense" giúp lập trình viên chọn được biến thể tốt nhất và hướng dẫn họ các hành vi giữ cho các thay đổi được vận hành trơn tru.

"Clean code" có rất nhiều khái niệm. Dưới đây là một số định nghĩa của một số lập trình viên nổi tiếng.

Bjarne Stroustrup, inventor of C++ and author of The C++ Programming Language

"I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well."

Grady Booch, author of Object Oriented Analysis and Design with Applications

"Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control"

“Big” Dave Thomas, founder of OTI, godfather of the Eclipse strategy

"Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone."

Tham khảo

Sách: “CLEAN CODE” của tác giả Robert C. Martin Series