Cải thiện code review: thực hành tốt nhất

Điểm chính

Giới thiệu

Đánh giá mã tạo ra giá trị trên nhiều khía cạnh hoạt động đồng thời. Chức năng chính của nó là phát hiện khiếm khuyết, nhưng các tác động phụ — chuyển giao kiến thức, thực thi tính nhất quán và trách nhiệm giải trình — cộng dồn theo thời gian thành những cải tiến cấu trúc mà các phiên đánh giá riêng lẻ không tạo ra một cách rõ ràng. Cụ thể, đánh giá mã giúp:

• Cải thiện chất lượng mã: Một góc nhìn bên ngoài xác định các lỗi logic, lỗi tiềm ẩn, lỗ hổng bảo mật và các vấn đề hiệu suất mà tác giả có khả năng bỏ lỡ sau khi làm việc kéo dài trên cùng một codebase. Kết quả là phần mềm ổn định và đáng tin cậy hơn.
• Lan truyền kiến thức: Khi một nhà phát triển đánh giá mã của người khác, họ đồng thời học về các phương pháp mới, mẫu và quyết định cụ thể của dự án. Đây là một trong những cơ chế hiệu quả nhất cho việc chuyển giao kiến thức trong một nhóm — đặc biệt có giá trị cho việc giới thiệu và phân phối hiểu biết về các hệ thống con phức tạp.
• Đảm bảo tính nhất quán: Đánh giá mã thực thi phong cách mã hóa thống nhất, các mẫu cấu trúc và các quy ước kiến trúc. Tính nhất quán này rất quan trọng cho khả năng duy trì lâu dài, đặc biệt khi thành phần nhóm thay đổi theo thời gian.
• Tăng cường làm việc nhóm: Đánh giá mã là một hành động hợp tác tạo ra một môi trường nơi các nhà phát triển hỗ trợ sự phát triển của nhau. Kết quả là các nhóm gắn kết hơn và có hiệu suất cao hơn.
• Giảm nợ kỹ thuật: Các đánh giá thường xuyên xác định và giải quyết các quyết định có vấn đề sớm, trước khi chúng bị nhúng vào codebase và tốn kém để gỡ bỏ.
• Tăng trách nhiệm giải trình: Biết rằng mã sẽ được đồng nghiệp đánh giá tạo ra một động lực tự nhiên để tạo ra công việc cẩn thận hơn, dễ đọc và có cấu trúc tốt ngay từ đầu.

Sự sẵn sàng đánh giá

Sự chuẩn bị trước khi gửi mã để đánh giá làm giảm chi phí của người đánh giá và tăng giá trị của thời gian đánh giá đã chi.

• Chia thành các phần nhỏ: Tránh gửi các thay đổi lớn trải dài qua nhiều tệp và chức năng. Các thay đổi nhỏ hơn, tập trung hơn dễ đánh giá và hiểu hơn — mục tiêu hoạt động là 100-200 dòng mã đã thay đổi mỗi pull request. Khi các thay đổi lớn hơn, hãy phân tách chúng thành các đơn vị logic có thể được đánh giá độc lập.
• Tự đánh giá: Đánh giá trước khi nộp bởi tác giả — xác minh rằng mã biên dịch, các bài kiểm tra vượt qua, logic hợp lý, định dạng nhất quán và tên rõ ràng — làm giảm khối lượng phản hồi cơ học mà người đánh giá phải cung cấp và tập trung đánh giá vào các vấn đề thực chất.
• Mô tả toàn diện: Cung cấp mô tả pull request rõ ràng và đầy đủ: cái gì đã được thay đổi, tại sao được thay đổi, các vấn đề nào được giải quyết và thay đổi liên quan đến mục tiêu dự án như thế nào. Xác định các khía cạnh đòi hỏi sự chú ý đặc biệt. Liên kết đến các mục theo dõi nhiệm vụ là cần thiết.
• Xóa mã đã chú thích và không sử dụng: Pull request chỉ nên chứa mã chức năng. Các đoạn đã chú thích và biến không sử dụng thêm nhiễu che khuất các thay đổi đang được đánh giá.
• Kiểm tra cục bộ: Tất cả các bài kiểm tra tự động — đơn vị và tích hợp — nên vượt qua cục bộ trước khi nộp. Bất kỳ bài kiểm tra thủ công nào được yêu cầu nên được mô tả rõ ràng trong mô tả pull request.

Văn hóa và giao tiếp

Đánh giá mã hiệu quả phụ thuộc vào chất lượng của các tương tác con người mà nó liên quan, không chỉ vào quy trình kỹ thuật. Các chuẩn mực văn hóa điều chỉnh đánh giá xác định liệu nó có hoạt động như một thực hành năng suất hay một nguồn ma sát nhóm.

• Hãy mang tính xây dựng, không phải chỉ trích: Đánh giá hướng đến mã, không phải tác giả. Các cụm từ hướng đến mã — "Điều này có thể được cải thiện" hoặc "Nếu chúng ta thử cái này thì sao?" — có tính năng suất hơn các đánh giá hướng đến tác giả.
• Đề xuất giải pháp, không chỉ vấn đề: Khi một khiếm khuyết được xác định, đề xuất một cải tiến cụ thể có giá trị hơn đáng kể so với chỉ đánh dấu vấn đề. "Sử dụng forEach ở đây sẽ cải thiện khả năng đọc" có thể hành động hơn "Vòng lặp tồi tệ."
• Hỏi, thay vì chỉ đạo: Các câu hỏi hướng dẫn tác giả đến giải pháp đúng — "Bạn đã xem xét mẫu Factory ở đây chưa?" — thường hiệu quả hơn việc sửa chữa trực tiếp, đặc biệt là để phát triển các thành viên nhóm cấp dưới.
• Hãy cụ thể: Các nhận xét nên rõ ràng và có cơ sở. Tránh các cụm từ chung chung. Cung cấp các ví dụ, liên kết đến tài liệu hoặc tham chiếu đến các tiêu chuẩn mã hóa khi áp dụng.
• Chú ý đến giọng điệu: Giao tiếp bằng văn bản làm cho giọng điệu khó hiệu chỉnh. Duy trì sự lịch sự rõ ràng và sử dụng làm rõ trực tiếp khi có thể có sự mơ hồ làm giảm rủi ro các nhận xét được nhận như chỉ trích cá nhân.
• Phản hồi các nhận xét: Tác giả mã nên phản hồi nhanh chóng các câu hỏi và nhận xét của người đánh giá — giải thích các quyết định, chấp nhận đề xuất hoặc trình bày sự không đồng ý với lý do rõ ràng.
• Công nhận đóng góp của người đánh giá: Công nhận thời gian và nỗ lực mà một người đánh giá đầu tư củng cố động lực hợp tác và làm cho các đánh giá trong tương lai có năng suất hơn.

Trọng tâm của người đánh giá

Đánh giá hiệu quả đòi hỏi một cách tiếp cận có hệ thống đối với những gì cần đánh giá. Một danh sách kiểm tra nhất quán ngăn chặn các danh mục quan trọng bị bỏ qua:

• Chức năng: Mã có làm những gì nhiệm vụ yêu cầu không? Nó có giải quyết vấn đề đã nêu không?
• Tính chính xác và logic: Có lỗi logic không? Các trường hợp biên có được xử lý đúng không? Các điều kiện lỗi có được giải quyết không (null-pointer, chia cho 0, lỗi mạng)?
• Bảo mật: Có lỗ hổng tiềm ẩn nào không — SQL injection, XSS, xử lý dữ liệu người dùng không an toàn?
• Hiệu suất: Mã có giới thiệu các điểm tắc nghẽn không? Có các thuật toán sẽ tạo ra hiệu suất không thể chấp nhận được ở khối lượng dữ liệu dự kiến không?
• Khả năng đọc và bảo trì: Mã có thể hiểu được đối với người đọc nó lần đầu không? Tên cho các biến, hàm và lớp có rõ ràng không? Các nhận xét có hiện diện ở những nơi cần thiết không? Mã có tuân theo các tiêu chuẩn mã hóa của nhóm không?
• Kiểm thử: Các bài kiểm tra đơn vị có hiện diện cho chức năng mới không? Các bài kiểm tra hiện có có vượt qua không? Các bài kiểm tra hồi quy có được bao gồm cho các sửa lỗi không?
• Sự trùng lặp mã: Bài nộp có giới thiệu mã đã tồn tại ở nơi khác trong dự án không?
• Kiến trúc và thiết kế: Các thay đổi có phù hợp với kiến trúc tổng thể của dự án không? Mã mới có giới thiệu các phản mẫu không?

Đánh giá không phải là một bài tập viết lại mã theo sở thích của người đánh giá — đó là một sự kiểm tra có hệ thống cho các lỗi và cải tiến có ý nghĩa so với các tiêu chuẩn chung.

Công cụ và tự động hóa

Tự động hóa các khía cạnh đánh giá thường lệ — thực thi phong cách, thực hiện kiểm thử, quét lỗ hổng — chuyển sự chú ý của người đánh giá từ kiểm tra cơ học sang đánh giá logic thực chất.

1. Hệ thống kiểm soát phiên bản có hỗ trợ PR/MR: GitHub, GitLab và Bitbucket cung cấp các giao diện tập trung để tạo, xem và bình luận về các yêu cầu pull/merge, với các nhận xét nội tuyến được gắn với các dòng mã cụ thể.

2. Tích hợp CI/CD: Các kiểm tra tự động được kích hoạt bởi mỗi pull request nên bao gồm:

• Bộ kiểm tra tự động: các bài kiểm tra đơn vị, tích hợp và chức năng chạy trên mỗi lần nộp
• Trình kiểm tra và định dạng mã: ESLint, Prettier, Black, SwiftLint thực thi các tiêu chuẩn phong cách tự động, loại bỏ việc thực thi phong cách khỏi trách nhiệm của người đánh giá
• Phân tích mã tĩnh: SonarQube, Bandit (Python), Semgrep đưa ra các lỗi tiềm ẩn, lỗ hổng và vấn đề chất lượng trước khi đánh giá của con người bắt đầu
• Quét lỗ hổng phụ thuộc: phân tích tự động về bảo mật thư viện bên thứ ba

3. Mẫu pull request: Các mẫu PR/MR tiêu chuẩn hóa với các trường bắt buộc — mô tả thay đổi, liên kết nhiệm vụ, kiểm thử đã chạy, câu hỏi cho người đánh giá — đảm bảo các tác giả cung cấp ngữ cảnh mà người đánh giá cần để tiến hành một đánh giá hiệu quả.

4. Nhận xét nội tuyến: Hầu hết các nền tảng hỗ trợ các nhận xét được liên kết với các dòng cụ thể, làm cho cuộc thảo luận theo ngữ cảnh thay vì yêu cầu người đánh giá tham chiếu số dòng riêng biệt.

Vòng lặp và học tập

Đánh giá mã không phải là một quá trình tĩnh — nó nên phát triển với nhóm và dự án khi cả hai phát triển.

• Cách tiếp cận lặp: Nhiều vòng nhận xét và sửa đổi được kỳ vọng cho các thay đổi phức tạp. Mỗi vòng lặp nên tạo ra sự cải tiến tăng dần thay vì cố gắng đạt được trạng thái cuối cùng trong một lần đi.
• Hồi tưởng: Các hồi tưởng thường xuyên tập trung vào quá trình đánh giá — cái gì hoạt động, cái gì tạo ra ma sát, các mô hình phản hồi nào xuất hiện lặp đi lặp lại — cung cấp dữ liệu cần thiết để cải thiện quá trình một cách có hệ thống.
• Học tập và cố vấn: Đánh giá là một trong những cơ chế học tập hiệu quả nhất có sẵn trong một nhóm. Các nhà phát triển cấp dưới học hỏi từ những người đánh giá có kinh nghiệm hơn; các nhà phát triển có kinh nghiệm phát triển khả năng cố vấn. Các mẫu nhất quán của cùng một lỗi trong các bài nộp của một nhà phát triển có thể chỉ ra nhu cầu đào tạo có cấu trúc hoặc lập trình theo cặp.
• Sự thích ứng quy tắc: Các tiêu chuẩn mã hóa và tiêu chí đánh giá nên phát triển khi dự án trưởng thành và thành phần nhóm thay đổi. Các tiêu chuẩn phục vụ một nhóm nhỏ có thể cần sửa đổi khi codebase mở rộng.
• Đánh giá kịp thời: Các đánh giá bị trì hoãn chặn tiến trình của tác giả và tăng khả năng xung đột tích hợp. SLA nội bộ cho thời gian xử lý đánh giá — thường là 24-48 giờ — giữ cho dòng phát triển không bị gián đoạn.
• Bảo vệ thời gian tập trung: Thời gian đánh giá nên được cấu trúc — các khối thời gian dành riêng hoặc phân phối trên nhiều người đánh giá — để ngăn chặn đánh giá liên tục gián đoạn công việc sâu.

Các bài viết liên quan:

Để có cách tiếp cận cấp khung cho trực quan hóa và ưu tiên nhiệm vụ, hãy đọc Tăng năng suất với Kanban: lời khuyên để quản lý nhiệm vụ hiệu quả.

Để có các phương pháp tiếp cận xác định và ngăn ngừa kiệt sức trước khi nó ảnh hưởng đến hiệu suất, hãy đọc Cách tránh kiệt sức: các chiến lược chính để duy trì sự khỏe mạnh.

Để trực quan hóa và quản lý dòng thời gian dự án với biểu đồ Gantt, hãy đọc Biểu đồ Gantt là gì? Hướng dẫn trực quan hóa và quản lý dòng thời gian dự án.

Kết luận

Đánh giá mã, được thực hiện với các tiêu chuẩn chuẩn bị nhất quán, các chuẩn mực giao tiếp xây dựng, các công cụ tự động và định hướng cải tiến liên tục, hoạt động như một hệ thống chuyển giao kiến thức và đảm bảo chất lượng thay vì một quy trình kiểm tra. Lợi nhuận dài hạn của nó — trong việc giảm tỷ lệ khiếm khuyết, cải thiện khả năng bảo trì và chuyên môn nhóm phân tán — tỷ lệ thuận với tính nhất quán mà các thực hành mô tả ở trên được áp dụng.

Đọc thêm được đề xuất

"Code Complete"

Một tài liệu tham khảo toàn diện để viết mã sạch, có thể bảo trì, với phạm vi đáng kể của các thực hành hỗ trợ đánh giá đồng nghiệp hiệu quả.

"The Art of Readable Code"

Một hướng dẫn thực tế để viết mã truyền đạt ý định rõ ràng — điều kiện tiên quyết cơ bản cho đánh giá tạo ra phản hồi thực chất thay vì hời hợt.

"Team Geek"

Bao quát các yếu tố con người trong phát triển phần mềm — hợp tác, giao tiếp và các động lực giữa các cá nhân quyết định liệu các thực hành như đánh giá mã có thành công hay thất bại trong thực tế.