💡 Key Takeaways
- The Psychology of Code Review: Why Most Reviews Fail Before They Start
- The Reviewer's Checklist: What to Actually Look For
- The Art of the Constructive Comment
- Being Reviewed: How to Make Your PRs Reviewable
Tôi vẫn nhớ lần xem xét mã mà suýt nữa khiến tôi từ bỏ nghề kỹ sư phần mềm. Đó là năm 2012, tôi đã làm được sáu tháng trong công việc đầu tiên tại một công ty khởi nghiệp fintech, và tôi vừa nộp một bản tái cấu trúc mà tôi nghĩ là tuyệt vời cho hệ thống xử lý thanh toán của chúng tôi. Nhận xét từ kỹ sư cấp cao trở lại với 47 bình luận—hầu hết đều là các biến thể của "điều này sai" mà không có giải thích. Tôi đã dành ba ngày để viết lại mọi thứ, chỉ để nhận được sự chấp thuận từ cùng một người đánh giá với một từ duy nhất: "Được rồi." Kinh nghiệm đó đã không dạy tôi gì về việc viết mã tốt hơn, nhưng đã dạy tôi mọi thứ về cách KHÔNG thực hiện một cuộc xem xét mã.
💡 Những điểm chính
- Tâm lý học của việc xem xét mã: Tại sao hầu hết các cuộc xem xét thất bại trước khi bắt đầu
- Danh sách kiểm tra của người đánh giá: Những gì thực sự cần tìm
- Nghệ thuật của nhận xét mang tính xây dựng
- Bị xem xét: Làm thế nào để khiến các PR của bạn có thể được xem xét
Tương lai mười hai năm, và giờ tôi là Kỹ sư Chính tại một công ty SaaS Series C, đã xem xét hơn 8.000 yêu cầu kéo và hướng dẫn hơn 40 nhà phát triển qua quy trình xem xét mã. Tôi đã thấy việc xem xét mã cứu cứu công ty khỏi những lỗi nghiêm trọng, và tôi đã thấy chúng phá hủy tinh thần của cả đội ngũ đến mức các bộ phận kỹ thuật hoàn toàn bị thay đổi chỉ trong sáu tháng. Sự khác biệt? Không phải chất lượng của mã được xem xét, mà là chất lượng của chính quy trình xem xét.
Việc xem xét mã đồng thời là một trong những công cụ mạnh mẽ nhất trong phát triển phần mềm và là một trong những thứ thường được sử dụng sai nhất. Theo báo cáo Tình trạng Xem xét Mã 2023 của SmartBear, các nhóm thực hiện quy trình xem xét mã có cấu trúc sẽ phát hiện 60-90% lỗi trước khi vào sản xuất, nhưng nghiên cứu tương tự cho thấy 73% nhà phát triển báo cáo trải nghiệm tiêu cực với việc xem xét mã đã làm giảm sự tự tin hoặc mối quan hệ của họ với các đồng đội. Sự nghịch lý này tồn tại vì hầu hết các nhóm chỉ tập trung vào cái gì để xem xét mà không phải cách để xem xét.
Tâm lý học của việc xem xét mã: Tại sao hầu hết các cuộc xem xét thất bại trước khi bắt đầu
Đây là điều mà không ai nói với bạn về việc xem xét mã: chúng không chủ yếu liên quan đến mã. Chúng liên quan đến con người. Mỗi yêu cầu kéo đại diện cho hàng giờ nỗ lực trí tuệ của ai đó, giải quyết vấn đề sáng tạo và bản sắc nghề nghiệp. Khi bạn xem xét mã, bạn không chỉ đánh giá logic và cú pháp—bạn đang tương tác với sản phẩm công việc của một con người khác theo cách mà sẽ xây dựng họ lên hoặc kéo họ xuống.
Tôi đã học điều này theo cách khó sau khi thực hiện một cuộc phỏng vấn thoát hiểm với một nhà phát triển junior tài năng đã rời bỏ đội của chúng tôi. Cô ấy nói với tôi rằng một bình luận xem xét mã đầy thiếu thốn—"Tại sao bạn lại làm điều này theo cách này?"—đã khiến cô ấy nghi ngờ về việc liệu cô ấy có thuộc về ngành kỹ thuật hay không. Người đánh giá đã coi đó là một câu hỏi chân thành, tò mò về lý do của cô ấy. Cô ấy hiểu rằng đó là sự phán xét. Đó là lúc tôi nhận ra rằng phương tiện văn bản không đồng bộ đã lấy đi âm điệu, biểu cảm khuôn mặt, và ngôn ngữ cơ thể, chỉ còn lại lời nói có thể được diễn giải trong ánh sáng xấu nhất.
Các nghiên cứu tâm lý học hỗ trợ điều này. Một nghiên cứu năm 2021 được công bố trong IEEE Transactions on Software Engineering cho thấy các bình luận xem xét mã được coi là khắc nghiệt hoặc thiếu thốn đã làm tăng thời gian để hợp nhất thêm trung bình 3.2 ngày và giảm khả năng tác giả đóng góp cải tiến trong tương lai xuống 34%. Ngược lại, các nhận xét bao gồm sự khen ngợi cụ thể bên cạnh phản hồi mang tính xây dựng đã dẫn đến chu kỳ lặp lại nhanh hơn 28% và chất lượng mã cao hơn 41% trong các lần nộp tiếp theo từ cùng một tác giả.
Điều này không có nghĩa là chúng ta nên làm ngọt mọi thứ hoặc tránh chỉ ra các vấn đề. Nó có nghĩa là chúng ta cần tiếp cận việc xem xét mã với một mục đích về con người ở phía bên kia. Trước khi tôi viết bất kỳ bình luận xem xét nào, tôi tự hỏi ba câu hỏi: Điều này có đúng không? Điều này có cần thiết không? Điều này có tử tế không? Nếu tôi không thể trả lời có cho cả ba, tôi sẽ viết lại bình luận. Bộ lọc đơn giản này đã biến đổi cách mà đội của tôi giao tiếp và đã giảm thời gian chu kỳ PR trung bình của chúng tôi từ 4.3 ngày xuống 1.8 ngày trong suốt hai năm qua.
Danh sách kiểm tra của người đánh giá: Những gì thực sự cần tìm
Khi tôi đào tạo các người đánh giá mới, họ luôn hỏi cùng một câu hỏi: "Tôi nên tìm gì?" Câu trả lời không phải là một danh sách đơn giản các quy tắc cú pháp hay hướng dẫn phong cách—những thứ đó nên được tự động hóa. Công việc của bạn với tư cách là một người đánh giá con người là đánh giá những điều mà máy móc không thể: quyết định thiết kế, khả năng bảo trì, và độ chính xác của logic kinh doanh.
Tôi sử dụng một hệ thống ưu tiên bốn cấp giúp tôi tập trung năng lượng xem xét vào những gì quan trọng nhất. Các vấn đề cấp 1 là rào cản: các lỗ hổng bảo mật, những rủi ro mất dữ liệu, hoặc những thay đổi quan trọng có thể gây ra sự cố sản xuất. Những điều này sẽ được đánh dấu ngay lập tức với các giải thích rõ ràng về rủi ro. Theo kinh nghiệm của tôi, các vấn đề cấp 1 thực sự xuất hiện trong chưa đến 5% yêu cầu kéo, nhưng khi chúng xuất hiện, việc phát hiện chúng là toàn bộ lý do mà chúng tôi thực hiện việc xem xét mã.
Các vấn đề cấp 2 là các mối quan tâm kiến trúc: mã hoạt động nhưng tạo ra nợ kỹ thuật, vi phạm các mẫu đã thiết lập, hoặc sẽ làm cho các thay đổi trong tương lai khó khăn hơn. Đây là những điều khó nhất để xem xét vì chúng yêu cầu hiểu cả mã nguồn hiện tại và định hướng tương lai của đội ngũ. Tôi đã tìm thấy rằng việc đặt khung những điều này dưới dạng câu hỏi thay vì chỉ đạo sẽ hiệu quả hơn: "Tôi lo lắng rằng cách tiếp cận này có thể khiến việc thực hiện tính năng X vào quý sau trở nên khó khăn hơn—bạn đã xem xét việc sử dụng mẫu Y thay thế chưa?" Điều này mời gọi thảo luận thay vì phòng thủ.
Các vấn đề cấp 3 là cải tiến về khả năng đọc và khả năng bảo trì: tên biến không rõ ràng, thiếu bình luận về logic phức tạp, hoặc các hàm có thể được tách thành để rõ ràng hơn. Những điều này quan trọng, nhưng không gấp. Tôi thường giới hạn bản thân chỉ trong ba bình luận cấp 3 mỗi lần xem xét, tập trung vào những lĩnh vực sẽ có tác động lớn nhất đến khả năng bảo trì trong tương lai. Nhiều hơn thế, và tác giả sẽ cảm thấy choáng ngợp và ngừng tương tác với phản hồi.
Cấp 4 là mọi thứ khác: sở thích phong cách, các cách tiếp cận thay thế không nhất thiết phải tốt hơn, hoặc những điều nhặt nhạnh về định dạng. Đây là ý kiến gây tranh cãi của tôi: bạn gần như không nên để lại các bình luận cấp 4. Nếu nó đủ quan trọng để chuẩn hóa, hãy thêm nó vào bộ linter hoặc hướng dẫn phong cách của bạn. Nếu nó không đủ quan trọng để tự động hóa, nó cũng không đủ quan trọng để làm chậm một yêu cầu kéo. Tôi đã thấy các đội mất hàng giờ tranh luận xem có nên sử dụng dấu nháy đơn hay dấu nháy kép trong khi gửi mã có lỗi logic thực sự. Đừng trở thành đội đó.
Nghệ thuật của nhận xét mang tính xây dựng
Sự khác biệt giữa một bình luận xem xét mã hữu ích và một bình luận gây demoral hóa thường chỉ là vài từ. So sánh hai bình luận này về cùng một đoạn mã:
| Cách tiếp cận đánh giá | Tác động đến chất lượng mã | Tác động đến tinh thần đội ngũ |
|---|---|---|
| Phê bình mà không có ngữ cảnh ("điều này sai") | Cải tiến tối thiểu; tác giả không học được các nguyên tắc cơ bản | Rất tiêu cực; tạo ra sự sợ hãi và sự oán giận |
| Chấp thuận chỉ để cho có ("LGTM" mà không đọc) | Không có cải tiến; lỗi trượt vào sản xuất | Trung tính ngắn hạn, tiêu cực dài hạn khi chất lượng xuống cấp |
| Phản hồi giải thích với lý do | Cải tiến cao; tác giả học được các mẫu và nguyên tắc | Tích cực; xây dựng niềm tin và sự an toàn tâm lý |
| Thảo luận hợp tác (câu hỏi so với lệnh) | Rất cao; nêu bật các trường hợp biên và các cách tiếp cận thay thế | Rất tích cực; khuyến khích chia sẻ kiến thức và tôn trọng lẫn nhau |
| Kiểm tra tự động + quan điểm của con người | Tốt nhất; tự động phát hiện các vấn đề cơ học, con người tập trung vào kiến trúc | Rất tích cực; giảm ma sát và tập trung vào việc thảo luận có ý nghĩa |
"Hàm này quá dài và làm quá nhiều việc." "Hàm này xử lý cả việc xác thực và biến đổi dữ liệu, điều này làm cho việc kiểm tra từng mối quan tâm trở nên khó khăn hơn. Hãy xem xét việc tách nó thành validateUserInput() và transformToApiFormat()—bằng cách đó, chúng ta có thể kiểm tra logic xác thực mà không cần phải giả lập quá trình biến đổi, và ngược lại."
Bình luận đầu tiên về mặt kỹ thuật là chính xác nhưng vô dụng. Nó nói cho tác giả biết điều gì sai nhưng không nói tại sao nó quan trọng hoặc làm thế nào để khắc phục. Bình luận thứ hai giải thích vấn đề, mô tả tác động, và gợi ý một giải pháp cụ thể. Tôi đã mất thời gian để...