Code Review Best Practices: How to Review (and Be Reviewed) — cod-ai.com

Tôi vẫn nhớ cuộc đánh giá mã mà suýt nữa khiến tôi bỏ nghề kỹ sư phần mềm. Đó là năm 2012, tôi đã làm việc được sáu tháng tại một công ty khởi nghiệp fintech, và tôi vừa nộp những gì tôi nghĩ là một bản tái cấu trúc tuyệt vời cho mô-đun xử lý thanh toán của chúng tôi. Đánh giá của kỹ sư cao cấp quay lại với 47 nhận xét—hầu hết trong số đó là các biến thể của "điều này là sai" mà không có lời giải thích. Tôi đã dành ba ngày để viết lại mã, chỉ để có đánh giá tiếp theo quay lại với 39 nhận xét nữa mâu thuẫn với những nhận xét trước đó. Kinh nghiệm đó đã dạy tôi một điều quan trọng: đánh giá mã kém không chỉ lãng phí thời gian—chúng phá hủy các đội nhóm, giết chết sự đổi mới, và đẩy những kỹ sư tài năng rời bỏ.

Nhanh chóng mười hai năm sau, và bây giờ tôi là Kỹ Sư Chính tại một công ty SaaS Series C, nơi tôi đã đánh giá hơn 8.000 yêu cầu kéo và hướng dẫn hơn 50 kỹ sư về những thực hành đánh giá mã hiệu quả. Tôi đã chứng kiến điều đó qua việc chuyển đổi văn hóa đánh giá mã của bạn có thể làm giảm tỷ lệ lỗi xuống 60%, giảm thời gian tiếp nhận xuống một nửa, và biến việc đánh giá mã từ một điểm tắc nghẽn đáng sợ thành công cụ học tập mạnh mẽ nhất của đội ngũ bạn. Sự khác biệt giữa các đội ngũ thành công và các đội ngũ chỉ tồn tại thường phụ thuộc vào cách họ tiếp cận thực hành này.

Tại Sao Đánh Giá Mã Quan Trọng Hơn Những Gì Bạn Nghĩ

Hãy bắt đầu với một vài con số có thể khiến bạn ngạc nhiên. Một nghiên cứu năm 2023 của SmartBear cho thấy rằng việc đánh giá mã bắt được 60-90% các lỗi trước khi chúng đến sản xuất—hiệu quả hơn nhiều so với bất kỳ bộ thử nghiệm tự động nào một mình. Nhưng đây là điều mà hầu hết mọi người bỏ lỡ: giá trị thật sự của việc đánh giá mã không chỉ là ngăn ngừa lỗi. Theo kinh nghiệm của tôi trong việc phân tích các chỉ số của đội ngũ trong năm năm, tôi đã nhận thấy rằng việc đánh giá mã hiệu quả mang lại bốn lợi ích quan trọng tích lũy theo thời gian.

Trước tiên, phân phối kiến thức. Khi tôi gia nhập công ty hiện tại, chúng tôi đã có vấn đề "nhà phát triển anh hùng" cổ điển—ba kỹ sư hiểu 80% mã nguồn, và những người còn lại thì sợ phải chạm vào bất cứ điều gì ngoài lĩnh vực của họ. Sau khi thực hiện các thực hành đánh giá mã có cấu trúc, chúng tôi đo được sự tăng trưởng 340% trong đóng góp mã chéo đội trong vòng 18 tháng. Các kỹ sư không chỉ đánh giá mã; họ đang học các mẫu, hiểu kiến trúc, và xây dựng sự tự tin để làm việc trên toàn bộ hệ thống.

Thứ hai, tính nhất quán về chất lượng. Trước khi thiết lập các tiêu chuẩn đánh giá rõ ràng, mã nguồn của chúng tôi là một mớ hỗn độn của các kiểu dáng, mẫu mã, và mức chất lượng khác nhau. Bạn có thể dễ dàng nhận ra đội nào đã viết mô-đun nào chỉ bằng cách nhìn vào nó. Sau khi chuyển đổi văn hóa đánh giá, điểm số phân tích tĩnh của chúng tôi đã cải thiện 73%, và quan trọng hơn, các kỹ sư mới báo cáo rằng họ cảm thấy tự tin gấp 4 lần về các kỳ vọng chất lượng mã trong tháng đầu tiên của họ.

Thứ ba, hướng dẫn quy mô. Tôi không thể hướng dẫn từng kỹ sư trong đội ngũ của mình, nhưng thông qua các đánh giá mã có suy nghĩ, tôi có thể chia sẻ thông tin với hàng chục người cùng một lúc. Một nhận xét đánh giá được giải thích tốt về lý do tại sao chúng tôi chọn một mẫu đồng thời cụ thể đã được tham khảo trong tài liệu nội bộ của chúng tôi 89 lần và đã tiết kiệm hàng giờ giải thích lặp đi lặp lại.

Thứ tư, và có thể là điều bị đánh giá thấp nhất: việc đánh giá mã là hệ thống cảnh báo sớm cho sức khỏe của đội nhóm. Khi thời gian quay vòng đánh giá tăng vọt, khi các chủ đề bình luận trở nên căng thẳng, khi một số kỹ sư ngừng tham gia—đây là những tín hiệu cảnh báo. Tôi đã phát hiện ra sự kiệt sức, xung đột giữa các cá nhân, và các bất đồng kiến trúc nhiều tuần trước khi chúng có thể bùng nổ, chỉ bằng cách chú ý đến các mẫu đánh giá mã.

Tâm Lý Của Người Đánh Giá: Không Phải Là Về Việc Đúng Hay Sai

Đây là sự thật không thoải mái mà tôi đã học được sau năm đầu tiên của mình như một kỹ sư cao cấp: việc đúng về mặt kỹ thuật không làm cho bạn trở thành một người đánh giá mã giỏi. Tôi đã phát hiện ra lỗi, xác định các vấn đề hiệu suất, và thực thi các quy tắc tốt nhất—và tinh thần của đội ngũ tôi đang giảm sút. Tỷ lệ chấp thuận đánh giá của tôi là 12%, có nghĩa là 88% PR cần thay đổi. Tôi nghĩ tôi đang duy trì các tiêu chuẩn cao. Người quản lý của tôi nghĩ rằng tôi đang tạo ra một điểm tắc nghẽn và khiến mọi người sợ phải gửi mã.

"Các đánh giá mã kém không chỉ lãng phí thời gian—chúng phá hủy các đội ngũ, giết chết sự đổi mới, và đẩy những kỹ sư tài năng rời bỏ."

Cuộc chuyển biến xảy ra khi tôi bắt đầu coi việc đánh giá mã như một cuộc trò chuyện hơn là một phán xét. Thay vì "Điều này sai, hãy sử dụng sự tiêm phụ thuộc ở đây," tôi bắt đầu viết "Tôi lo ngại về khả năng kiểm tra ở đây—bạn đã xem xét sự tiêm phụ thuộc chưa? Rất vui được phối hợp về điều này nếu nó không quen thuộc." Nội dung kỹ thuật là như nhau, nhưng cách thức đã thay đổi mọi thứ. Chỉ trong hai tháng, tỷ lệ chấp thuận của tôi đã tăng lên 67%, nhưng quan trọng hơn, chất lượng của các bản nộp ban đầu đã cải thiện 40% bởi vì các kỹ sư cảm thấy an toàn khi hỏi các câu hỏi trước khi nộp.

Sự thay đổi tâm lý mà tôi dạy bây giờ là: công việc của bạn với tư cách là một người đánh giá không phải là chứng minh bạn thông minh hơn tác giả. Công việc của bạn là giúp gởi đi mã chất lượng cao trong khi làm cho tác giả trở thành một kỹ sư tốt hơn. Điều đó có nghĩa là hiểu ngữ cảnh trước khi chỉ trích, đặt câu hỏi trước khi đưa ra yêu cầu, và nhận ra rằng thường có nhiều giải pháp hợp lệ cho bất kỳ vấn đề nào.

Tôi sử dụng một khung tư duy mà tôi gọi là "Ba Cấp Độ Phản Hồi Đánh Giá." Các vấn đề Cấp 1 là các vấn đề khách quan: lỗi, lỗ hổng bảo mật, vi phạm các tiêu chuẩn đã thiết lập của đội. Những điều này cần có sự thay đổi. Các vấn đề Cấp 2 là những gợi ý mạnh mẽ: lo ngại về hiệu suất, cải tiến khả năng bảo trì, mẫu mã tốt hơn. Những điều này cần thảo luận. Các vấn đề Cấp 3 là sở thích cá nhân: đặt tên biến, tổ chức mã, các lựa chọn về phong cách. Những điều này nên hiếm và được đánh dấu rõ ràng là không cản trở.

Vấn đề là hầu hết các người đánh giá coi mọi thứ như Cấp 1. Tôi đã thấy các chủ đề đánh giá 20 nhận xét mà 18 nhận xét là về sở thích thụt lề và đặt tên biến, và chỉ 2 nhận xét đề cập đến một tình huống race condition thực sự. Khi mọi thứ đều quan trọng, không có gì là quan trọng. Bây giờ tôi nhắm đến tỷ lệ khoảng 70% Cấp 1, 25% Cấp 2 và 5% Cấp 3 trong các đánh giá của mình. Nếu tôi thấy mình viết hơn hai nhận xét Cấp 3, tôi dừng lại và tự hỏi liệu tôi có thực sự đang cải thiện mã hay chỉ đang áp đặt sở thích của mình.

Nghệ Thuật Viết Nhận Xét Đánh Giá Hiệu Quả

Tôi đã phân tích hàng ngàn nhận xét đánh giá mã để hiểu điều gì làm cho phản hồi hiệu quả so với điều gì tạo ra sự bối rối và xung đột. Sự khác biệt thường phụ thuộc vào cấu trúc và sự cụ thể. Một nhận xét như "Điều này sẽ không mở rộng được" về mặt kỹ thuật là phản hồi, nhưng nó vô dụng. Nó không giải thích vấn đề, gợi ý một giải pháp, hoặc giúp tác giả học hỏi. So sánh điều đó với: "Vòng lặp O(n²) này sẽ trở nên vấn đề khi chúng ta đạt 10k+ bản ghi (mà chúng ta dự đoán cho Q3). Hãy cân nhắc sử dụng một map băm ở đây để tra cứu O(n). Đây là một mẫu tương tự mà chúng tôi đã sử dụng trong máy xử lý thanh toán: [link]."