💡 Key Takeaways
- 1. Names Should Reveal Intent, Not Require Archaeology
- 2. Functions Should Do One Thing and Do It Well
- 3. Comments Should Explain Why, Not What
- 4. Keep Your Code DRY, But Not Bone Dry
Bởi Marcus Chen, Kỹ sư Phần mềm Chính với 14 năm kinh nghiệm xây dựng hệ thống có khả năng mở rộng tại các công ty Fortune 500 và startups
💡 Những Điểm Chính
- 1. Tên Biểu Thị Ý Định, Không Cần Phải Khảo Cổ
- 2. Hàm Nên Làm Một Việc và Làm Tốt Việc Đó
- 3. Bình Luận Nên Giải Thích Tại Sao, Không Phải Là Gì
- 4. Giữ Mã Của Bạn DRY, Nhưng Không Được Quá Khô
Ba năm trước, tôi thừa hưởng một mã nguồn khiến tôi nghi ngờ về những lựa chọn nghề nghiệp của mình. Nhóm trước đã cung cấp tính năng rất nhanh—thật sự rất nhanh. Nhưng khi tôi mở tệp dịch vụ chính, tôi tìm thấy 4.200 dòng logic rối rắm, các biến có tên temp2 và finalFinal, và các hàm thực hiện mười bảy việc khác nhau. Một sửa lỗi đơn giản lẽ ra chỉ mất một giờ lại tiêu tốn ba ngày. Dự án đó đã dạy tôi điều gì đó quan trọng: tốc độ mà không có kỷ luật tạo ra nợ kỹ thuật giống như lãi suất thẻ tín dụng ở mức 29% APR.
Kể từ đó, tôi đã biến mã sạch thành một nỗi ám ảnh. Tôi đã tái cấu trúc các hệ thống lỗi thời phục vụ 50 triệu người dùng, hướng dẫn hơn 80 lập trình viên, và chứng kiến các nhóm biến đổi năng suất của họ bằng cách áp dụng những nguyên tắc này. Dữ liệu thật thuyết phục: các nhóm thực hành nguyên tắc mã sạch giảm mật độ lỗi từ 40-60% và cắt giảm thời gian hướng dẫn cho các lập trình viên mới một nửa. Quan trọng hơn, họ cung cấp tính năng nhanh hơn về lâu dài vì họ không phải liên tục chiến đấu với mã nguồn của chính mình.
Mã sạch không phải chỉ là vấn đề lý thuyết hay tuân theo các quy tắc vì lợi ích của chính nó. Nó nói lên sự tôn trọng—sự tôn trọng cho bản thân bạn trong tương lai, cho đồng nghiệp của bạn, và cho lập trình viên tiếp theo sẽ duy trì công việc của bạn lúc 2 giờ sáng khi sản xuất đang gặp sự cố. Dưới đây là mười nguyên tắc đã biến đổi cách tôi viết mã và cách các đội mà tôi đã dẫn dắt cung cấp phần mềm.
1. Tên Biểu Thị Ý Định, Không Cần Phải Khảo Cổ
Lần đầu tiên tôi xem xét mã tại công ty hiện tại, tôi gặp một hàm có tên processData(). Tôi mất 45 phút để hiểu những gì nó thực sự làm: xác thực đầu vào của người dùng, chuyển đổi giá trị tiền tệ, cập nhật ba bảng cơ sở dữ liệu, gửi hai email khác nhau và ghi lại sự kiện phân tích. Tên gọi đã không tiết lộ gì về độ phức tạp này.
Tên gọi tốt là nền tảng của mã sạch vì chúng tôi đọc mã nhiều hơn là viết mã. Các nghiên cứu cho thấy các lập trình viên dành 58% thời gian của họ để đọc và hiểu mã so với 42% thực sự viết hoặc sửa đổi nó. Mỗi tên gọi mơ hồ là một khoản thu thuế cho thời gian đọc đó, bị nhân lên qua mỗi lập trình viên chạm vào mã đó.
Dưới đây là khung tên gọi của tôi: một tên biến hoặc hàm nên trả lời ba câu hỏi mà không cần bạn đọc phần triển khai của nó. Nó đại diện cho điều gì? Nó làm gì? Tại sao nó tồn tại? Một biến có tên d không trả lời được câu nào. Một biến có tên daysSinceLastModification trả lời cả ba câu hỏi.
Đối với các hàm, tôi tuân theo quy tắc danh từ-động từ rất nghiêm ngặt. getUserById() rõ ràng. get() là vô dụng. handleUserData() là mơ hồ—xử lý như thế nào? Đối với các biến boolean, tôi sử dụng các đại từ: isActive, hasPermission, canEdit. Chúng đọc tự nhiên trong các câu lệnh điều kiện: if (isActive && hasPermission) so với if (active && permission).
Tôi đã thấy các nhóm lãng phí hàng trăm giờ vì ai đó đã viết tắt customer thành cust trong nửa mã nguồn và cstmr trong nửa còn lại. Tính nhất quán là rất quan trọng. Đặt quy tắc đặt tên sớm và thực thi chúng qua các đánh giá mã và quy tắc linting. Tương lai của bạn sẽ cảm ơn bạn khi bạn đang gỡ lỗi lúc nửa đêm và không phải decipher tmp_val_2 đại diện cho điều gì.
Một kỹ thuật thực tiễn mà tôi sử dụng: nếu tôi không thể nghĩ ra một tên gọi tốt ngay lập tức, tôi viết một bình luận mô tả những gì biến hoặc hàm đó làm, sau đó biến bình luận đó thành một tên gọi. Nếu tên gọi trở nên quá dài (hơn 4-5 từ), đó thường là dấu hiệu rằng hàm đang làm quá nhiều và cần được chia nhỏ.
2. Hàm Nên Làm Một Việc và Làm Tốt Việc Đó
Nguyên tắc Trách Nhiệm Đơn Độc không chỉ là lý thuyết học thuật—nó là sự khác biệt giữa mã có thể bảo trì và một cơn ác mộng bảo trì. Tôi đã học điều này theo cách khó khăn khi gỡ lỗi một hàm 300 dòng xử lý việc đăng ký người dùng, xác thực email, xử lý thanh toán và theo dõi phân tích. Việc tìm lỗi mất sáu giờ. Sửa chữa nó chỉ mất năm phút.
"Tỷ lệ thời gian dành cho việc đọc so với viết mã là trên 10 so với 1. Chúng tôi liên tục đọc mã cũ như một phần của nỗ lực viết mã mới. Làm cho nó dễ đọc sẽ giúp nó dễ viết." — Robert C. Martin
Một hàm nên làm một việc, làm tốt việc đó và chỉ làm việc đó. Nhưng cái gì được coi là "một việc"? Quy tắc ngón tay cái của tôi: nếu bạn không thể mô tả điều mà một hàm làm trong một câu giản đơn mà không sử dụng từ "và," thì hàm đó đang làm quá nhiều. validateUserInput() làm một việc. validateUserInputAndSaveToDatabase() làm hai việc và nên được chia nhỏ.
Tôi nhắm đến các hàm dài từ 10-20 dòng. Một số lập trình viên nghĩ rằng điều này cực đoan, nhưng các hàm nhỏ có lợi ích to lớn. Chúng dễ dàng để kiểm thử—bạn có thể xác minh một hành vi mà không cần thiết lập các kịch bản phức tạp. Chúng dễ dàng để tái sử dụng—các hàm nhỏ, tập trung trở thành các khối xây dựng cho các hoạt động lớn hơn. Chúng dễ hiểu hơn—bạn có thể nắm bắt toàn bộ hàm mà không cần cuộn.
Khi tôi tái cấu trúc các hàm lớn, tôi tìm kiếm những vết nứt tự nhiên nơi mã thay đổi mức độ trừu tượng. Một hàm xác thực đầu vào, chuyển đổi dữ liệu và lưu vào cơ sở dữ liệu đang hoạt động ở ba mức độ khác nhau. Tôi tách mỗi mức vào chính hàm của nó: validateOrderData(), transformOrderForStorage(), và saveOrder(). Hàm gốc trở thành một bộ điều phối gọi ba hàm này theo trình tự.
Cách tiếp cận này cũng làm cho việc xử lý lỗi trở nên sạch hơn. Thay vì các khối try-catch lồng nhau kéo dài 50 dòng, mỗi hàm nhỏ xử lý các lỗi của riêng mình một cách thích hợp. Hàm bộ điều phối sau đó có thể xử lý các kịch bản lỗi cấp cao mà không bị mắc kẹt trong các chi tiết thực thi.
Tôi đã đo lường tác động của nguyên tắc này lên các nhóm của tôi. Sau khi áp dụng giới hạn kích thước hàm nghiêm ngặt, thời gian trung bình để sửa lỗi của chúng tôi đã giảm từ 4.2 giờ xuống còn 1.8 giờ. Các thành viên mới trong nhóm bắt đầu trở nên năng suất nhanh hơn 40% vì họ có thể hiểu các hàm riêng lẻ mà không cần phải hiểu toàn bộ hệ thống trước.
3. Bình Luận Nên Giải Thích Tại Sao, Không Phải Là Gì
Sớm trong sự nghiệp của mình, tôi nghĩ mã tốt có nghĩa là có nhiều bình luận. Tôi sẽ viết những điều như // tăng biến đếm lên 1 phía trên counter++. Cấp trên của tôi đã kéo tôi sang một bên và nói điều gì đó đã thay đổi quan điểm của tôi: "Nếu mã của bạn cần bình luận để giải thích nó làm gì, mã của bạn không đủ rõ ràng."
| Khía Cạnh | Mã Bẩn | Mã Sạch | Tác Động |
|---|---|---|---|
| Tên Hàm | processData(), doStuff(), handleIt() | validateAndTransformUserInput(), sendWelcomeEmail() | Giảm thời gian hiểu biết 70% |
| Chiều Dài Hàm | 200-500+ dòng, nhiều trách nhiệm | 10-20 dòng, trách nhiệm đơn lẻ | Mật độ lỗi giảm từ 40-60% |
| Tên Biến | temp2, finalFinal, x, data | userEmailAddress, validatedOrderTotal | Thời gian hướng dẫn cắt giảm một nửa |
| Bình Luận | Giải thích gì mã làm | Giải thích tại sao các quyết định đã được đưa ra | Thời gian bảo trì giảm 50% |
| Sao Chép Mã | Logic giống nhau được sao chép trong 5+ tệp | Trích xuất thành các hàm tái sử dụng | Các thay đổi yêu cầu 1 chỉnh sửa so với 5+ |
Bình luận nên giải thích tại sao bạn đã đưa ra quyết định, không phải mã làm gì. Chính mã nên tự giải thích thông qua cách đặt tên tốt và cấu trúc rõ ràng. Khi tôi thấy // lặp qua người dùng phía trên một vòng lặp for, đó là tiếng ồn. Vòng lặp đã cho thấy nó đang lặp qua người dùng. Nhưng một bình luận như // Sử dụng tìm kiếm tuần tự ở đây vì mảng thường chỉ có 5-10 mục và chi phí tìm kiếm nhị phân không đáng giá—đó là giá trị. Nó giải thích một quyết định không rõ ràng từ chính mã.
Tôi sử dụng bình luận để tài liệu hóa các quy tắc kinh doanh không rõ ràng, giải thích các giải pháp thay thế cho lỗi thư viện bên thứ ba, hoặc làm rõ lý do tại sao chúng tôi không sử dụng giải pháp "hiển nhiên". Ví dụ: // Không thể sử dụng async/await ở đây vì Safari 12 không hỗ trợ nó trong service workers và 8% người dùng của chúng tôi vẫn đang dùng Safari 12. Bình luận đó ngăn lập trình viên tiếp theo "sửa chữa" một điều gì đó không bị hỏng.
Bình luận cảnh báo là một trường hợp sử dụng hợp lệ khác. // CẢNH BÁO: Thay đổi thời gian chờ này ảnh hưởng đến giới hạn tốc độ trong bộ xử lý thanh toán. Xem ticket #1234 trước khi chỉnh sửa. Điều này ngăn chặn các lập trình viên với ý định tốt gây ra những thay đổi có hậu quả không dự đoán được.