Ảnh minh hoạ bởi Unsplash
Bất kỳ ai đã từng trải qua những năm tháng mài đũng quần trên ghế nhà trường môn Lập trình đều quá quen thuộc với cảm giác sung sướng tột độ khi màn hình console hiện lên dòng chữ Build Succeeded hoặc Hello World sau hàng giờ fix bug. Chúng ta thường có thói quen hò reo: "Chạy được rồi! Đừng đụng vào nó nữa!".
Tuy nhiên, mang tư duy "Chạy được là được" (It works, don't touch it) từ bài tập lớn đại học vào môi trường phát triển phần mềm doanh nghiệp lại là một thảm họa. Nó không chỉ giết chết dự án mà còn dần dần bào mòn cả sự nghiệp của một lập trình viên.
1. Máy tính không phán xét, nhưng con người thì có
Máy tính là một cỗ máy ngu ngốc nhưng cực kỳ trung thành. Dù bạn viết code một cách tinh tế với các Design Pattern (Mẫu thiết kế) hay bạn nhồi nhét 20 vòng lặp lồng nhau với các biến tên là temp1, temp2, trình biên dịch (Compiler) cuối cùng cũng dịch tất cả thành mã máy (0 và 1) để thực thi. Đối với máy tính, code xấu và code đẹp đều chạy được.
Nhưng Martin Fowler từng nói một câu bất hủ: "Bất kỳ kẻ ngốc nào cũng có thể viết code cho máy tính hiểu. Lập trình viên giỏi là người viết code cho con người hiểu."
Code của bạn không sống trong môi trường chân không. Tuổi thọ trung bình của một dự án phần mềm có thể kéo dài 5-10 năm. Trong khoảng thời gian đó, đoạn code bạn viết hôm nay sẽ được đọc, sửa đổi và mở rộng bởi hàng chục người khác (thậm chí là chính bạn của 6 tháng sau). Viết code khó đọc chính là hành vi "đầu độc" đồng nghiệp và tương lai của dự án.
2. Nợ kỹ thuật (Technical Debt) - Kẻ giết người thầm lặng
Hãy tưởng tượng bạn đang xây một ngôi nhà. Vì áp lực tiến độ, thay vì xây móng vững chắc bằng bê tông, bạn dùng ván ép cho nhanh. Ngôi nhà vẫn đứng vững, vẫn "chạy được". Nhưng khi muốn xây thêm tầng hai, tầng ba, ngôi nhà sẽ sụp đổ. Trong lập trình, sự dễ dãi này được gọi là Nợ Kỹ Thuật (Technical Debt).
Mỗi lần bạn copy-paste một đoạn code thay vì tạo một hàm tái sử dụng, mỗi lần bạn bỏ qua việc viết Unit Test, mỗi lần bạn hard-code cấu hình... bạn đang vay mượn nợ kỹ thuật. Và giống như nợ tín dụng, nó sinh ra "lãi suất". Lãi suất ở đây chính là thời gian: Tính năng mới thay vì mất 2 ngày để hoàn thành, nay mất đến 2 tuần vì mọi luồng logic đã rối tung lên như một bát mì Spaghetti.
3. Dấu hiệu của một "Bát mì Spaghetti"
Làm sao để biết bạn đang mang tư duy "Chạy được là được"? Hãy kiểm tra các dấu hiệu sau:
- God Object / God Function: Một hàm xử lý tất cả mọi thứ: Gọi database, xử lý logic tính toán, gọi API bên thứ 3 và format luôn cả dữ liệu trả về giao diện. Kích thước hàm lên tới 1000 dòng.
- Tên biến vô nghĩa:
userList2,checkFlag,doSomething(). Đọc tên biến không ai biết nó dùng để làm gì. - Magic Numbers (Những con số ma thuật): Khắp nơi trong code xuất hiện các phép nhân chia với
86400,3.14,0.05mà không có bất kỳ hằng số (constant) nào giải thích ý nghĩa của chúng. - Comment dọn rác: Viết những comment kiểu
// Xin lỗi người đọc, tôi biết đoạn này rất ngu nhưng ngày mai phải release rồi.
4. Clean Code không tốn thời gian, nó tiết kiệm thời gian
Lý do phổ biến nhất cho việc viết code ẩu là: "Tôi không có thời gian, sếp hối quá". Nhưng đây là một cái bẫy tư duy. Viết Clean Code (Code Sạch) có thể làm chậm tốc độ của bạn trong 2 tuần đầu tiên của dự án. Nhưng từ tháng thứ 2 trở đi, nó giúp dự án duy trì tốc độ phát triển ổn định.
Ngược lại, Quick and Dirty (Nhanh và Ẩu) giúp bạn bay nhanh trong 2 tuần đầu, nhưng sẽ khiến dự án chìm vào vũng lầy (bog down) vĩnh viễn ở các tháng sau đó. Việc tìm và sửa một bug trong mớ code lộn xộn tốn thời gian gấp hàng chục lần so với việc viết nó tử tế ngay từ đầu.
5. Nghệ nhân lập trình (Software Craftsmanship)
Hãy từ bỏ danh xưng "Thợ gõ code" (Code Monkey) để trở thành một "Nghệ nhân phần mềm" (Software Craftsman). Nghệ nhân là những người tự hào về sản phẩm mình tạo ra, dù đó là những chi tiết khuất lấp không ai nhìn thấy.
Bắt đầu từ những việc nhỏ nhất: Đặt tên biến thật rõ nghĩa (dù nó có hơi dài), chia nhỏ các hàm theo nguyên tắc Đơn trách nhiệm (Single Responsibility Principle - SOLID), và hãy thực hành nguyên tắc Hướng đạo sinh: "Luôn để lại khu cắm trại sạch hơn lúc bạn tìm thấy nó" (Mỗi khi chạm vào một đoạn code cũ, hãy dọn dẹp nó một chút).
Lời kết: Viết code chạy được là một kỹ năng. Viết code đẹp, dễ đọc, dễ bảo trì là một nghệ thuật. Bạn có thể lừa được sếp, lừa được khách hàng bằng một tính năng chạy loáng thoáng bên ngoài, nhưng bạn không thể lừa được những đồng nghiệp sẽ phải đọc code của bạn. Hãy viết code như thể người bảo trì nó sau này là một kẻ sát nhân hàng loạt biết địa chỉ nhà của bạn!
