Code Review Không "Drama": Cách Các Đội Tuyển Gửi Phản Hồi Hiệu Quả

Vài năm trước, tôi rời khỏi một buổi đánh giá code (code review) với một cảm giác… khó tả.

Code chạy ổn.

Các bài test đều passed.

Nhưng lại nhận được những bình luận như:

“Cái này sai”

“Cách tiếp cận tệ”

“Viết lại chỗ này”

Không giải thích.

Không ngữ cảnh.

Chỉ có sự phán xét.

Không có gì sai về mặt kỹ thuật cả.

Nhưng có gì đó sai sai.

Đó là lúc tôi nhận ra:

Code review không chỉ là về code, mà là về giao tiếp.

Và nếu làm không tốt, chúng không cải thiện được codebase, mà chỉ âm thầm làm tổn thương đội ngũ mà thôi.

Tại sao Code Review lại gặp rắc rối

Hầu hết các lập trình viên không muốn đưa ra phản hồi tiêu cực, nhưng các buổi review code thường trở nên căng thẳng.

Tại sao?

Bởi vì chúng nằm ở giao điểm của:

• sự sở hữu (“đây là code của tôi”)
• bản sắc (“nó phản ánh kỹ năng của tôi”)
• áp lực thời gian (“chúng ta cần release gấp”)

Thêm vào đó một chút giao tiếp không rõ ràng, mọi thứ leo thang rất nhanh.

Những gì bắt đầu là phản hồi lại trở thành chỉ trích. Những gì nên là sự cộng tác lại trở thành ma sát.

Code Review tốt thực sự làm được gì

Một buổi code review tốt không chỉ bắt lỗi.

Nó làm được ba việc:

• cải thiện code
• chia sẻ kiến thức
• củng cố đội ngũ

Nếu thiếu một trong những điều này, đặc biệt là điều cuối cùng, thì có gì đó không ổn. Một đội ngũ né tránh review hoặc sợ hãi chúng sẽ không bao giờ đi nhanh trong dài hạn.

1. Tập trung vào Code, không phải Con người

Điều này nghe có vẻ hiển nhiên, nhưng sự khác biệt nhỏ trong cách dùng từ lại rất quan trọng.

Hãy so sánh:

This is wrong (Cái này sai)

với

This logic might lead to edge cases when the input is empty (Logic này có thể dẫn đến các trường hợp ngoại lệ khi input bị trống)

Cái đầu tiên cảm giác như là phán xét.

Cái thứ hai cảm giác như là sự cộng tác.

Một sự thay đổi đơn giản sẽ giúp ích rất nhiều:

👉 mô tả vấn đề, không phải con người

Thay vì:

• “bạn làm sai cái này”

Hãy thử:

• “cách tiếp cận này có thể gây ra vấn đề vì…”

Đó là một thay đổi nhỏ, nhưng nó thay đổi hoàn toàn cách phản hồi được tiếp nhận.

2. Giải thích Tại sao, không chỉ là Cái gì

Một trong những điều khó chịu nhất trong code review là những phản hồi mơ hồ.

Refactor this (Refactor cái này đi)

Tại sao?

Vấn đề là gì?

Mục tiêu là gì?

Nếu không có ngữ cảnh, bình luận đó chỉ là tiếng ồn.

Phản hồi tốt luôn trả lời một câu hỏi:

Tại sao điều này lại quan trọng?

Ví dụ:

This works, but extracting this into a function could make it easier to test and reuse (Cái này chạy được, nhưng việc tách nó ra thành một function có thể khiến nó dễ test và tái sử dụng hơn)

Bây giờ tác giả hiểu được:

• ý định
• lợi ích
• sự đánh đổi

Và có thể đưa ra quyết định tốt hơn.

3. Biến Phán xét thành Câu hỏi

Khi nghi ngờ, hãy hỏi.

Câu hỏi rất mạnh mẽ vì chúng:

• mời gọi thảo luận
• giảm thiểu sự phòng thủ
• làm sáng tỏ ngữ cảnh mà bạn có thể đã bỏ sót

Thay vì:

This is over-engineered (Cái này bị over-engineering - quá phức tạp không cần thiết)

Hãy thử:

Do we need this level of abstraction here, or could a simpler approach work? (Chúng ta có cần level abstraction này ở đây không, hay một cách tiếp cận đơn giản hơn có thể hoạt động được?)

Cùng một mối lo ngại.

Kết quả hoàn toàn khác nhau.

Đôi khi, bạn thậm chí sẽ nhận ra tác giả ban đầu có lý do chính đáng.

4. Tránh Bike-shedding

Không phải tất cả phản hồi đều có cùng trọng lượng, nhưng nhiều đánh giá lại đối xử với mọi thứ như nhau.

Bạn kết thúc với những chủ đề tranh luận dài dòng về:

• tên biến
• định dạng
• sở thích cá nhân

Trong khi các vấn đề quan trọng hơn lại nhận được ít sự chú ý.

Đây được gọi là bike-shedding (tranh cãi về những chi tiết vụn vặt) và nó giết chết năng suất.

Một quy tắc đơn giản giúp ích:

👉 tập trung vào những gì ảnh hưởng đến:

• tính chính xác (correctness)
• khả năng đọc (readability)
• khả năng bảo trì (maintainability)

Còn lại để cho:

• linters
• formatters
• quy ước đội ngũ (team conventions)

Năng lượng của bạn có hạn, hãy dùng nó vào nơi quan trọng.

5. Cân bằng Tốc độ và Độ sâu

Luôn có một sự căng thẳng trong mọi code review:

• đi sâu → chất lượng tốt hơn
• đi nhanh → tốc độ (velocity) tốt hơn

Các đội nhóm tuyệt vời không chọn một trong hai, họ cân bằng cả hai.

Một số cách thực tế:

• giữ các PR (Pull Request) nhỏ gọn
• review sớm, không chỉ đợi đến cuối
• tránh những “đánh giá khổng lồ” với 1000+ dòng code

Bởi vì thay đổi càng lớn, càng khó để review tốt.

Và càng dễ để các vấn đề lọt qua.

Ví dụ thực tế: Từ gay gắt đến hữu ích

Hãy lấy một ví dụ thực tế.

❌ Gay gắt (Harsh)

This is messy. Refactor it. (Cái này bừa bộn. Refactor lại đi.)

Điều này tạo ra:

• nhầm lẫn
• thất vọng
• tranh qua tranh lại

✅ Hữu ích (Helpful)

This works, but it’s a bit hard to follow due to the nested conditions. What do you think about extracting this part into a separate function? It might make the flow easier to read and test. (Cái này chạy được, nhưng hơi khó theo dõi do các điều kiện lồng nhau. Bạn thấy sao nếu tách phần này thành một function riêng? Nó có thể khiến luồng đi dễ đọc và test hơn.)

Bây giờ chúng ta có:

• ngữ cảnh
• gợi ý
• sự cộng tác

Cùng một ý định, kết quả tốt hơn nhiều.

Cách tiếp nhận phản hồi

Đưa ra phản hồi chỉ là một nửa vấn đề.

Tiếp nhận nó cũng quan trọng không kém.

Một vài điều giúp ích:

• giả định ý định tích cực
• yêu cầu làm rõ nếu điều gì đó chưa rõ ràng
• đừng mang các bình luận cá nhân hóa
• phản bác khi cần thiết, nhưng phải có ngữ cảnh

Một code review tốt không phải là đồng ý về mọi thứ.

Nó là về việc cùng nhau đạt được giải pháp tốt hơn.

Thỏa thuận chung cho đội ngũ (Practical Team Agreements)

Những đội nhóm tốt nhất không để mọi thứ phụ thuộc vào may rủi.

Họ định nghĩa cách review nên hoạt động.

Một vài thỏa thuận đơn giản có thể tạo ra sự khác biệt lớn:

• “Giải thích lý do tại sao” là bắt buộc
• Ưu tiên câu hỏi hơn là phán xét
• Tập trung vào các vấn đề có tác động cao trước
• Giữ PR nhỏ và tập trung
• Không cái tôi (ego) trong các cuộc thảo luận

Đây là những quy tắc nhỏ, nhưng chúng tạo ra một môi trường lành mạnh hơn nhiều.

Lời kết

Code review là một trong những công cụ mạnh mẽ nhất của một đội ngũ, nhưng chỉ khi nó được thực hiện đúng. Bởi vì những buổi review tệ không chỉ làm chậm sự phát triển, mà chúng tạo ra ma sát, sự thất vọng và cuối cùng là sự im lặng.

Những buổi review tuyệt vời thì làm điều ngược lại:

• Chúng cải thiện code.
• Chúng lan tỏa kiến thức.
• Chúng xây dựng niềm tin.

Và trong dài hạn, đó mới là điều khiến một đội nhóm thực sự nhanh chóng.