Code review là một trong những hoạt động mang lại giá trị cao nhất trong phát triển phần mềm: phát hiện lỗi sớm, lan tỏa kiến thức, giữ cho codebase nhất quán. Nhưng nó cũng là nơi dễ xảy ra va chạm nhất. Một bình luận cộc lốc có thể khiến đồng nghiệp tự ái, một pull request treo ba ngày có thể làm chậm cả sprint. Bài viết này chia sẻ cách review và nhận review sao cho mang tính xây dựng, dựa trên kinh nghiệm thực tế và hướng dẫn công khai của Google về code review.

Mục tiêu của code review

Trước hết, cần thống nhất mục tiêu. Theo hướng dẫn kỹ thuật của Google, tiêu chuẩn chính là: một thay đổi nên được chấp nhận khi nó cải thiện tổng thể sức khỏe của codebase, dù chưa hoàn hảo. Không có code nào hoàn hảo, và mục tiêu là tiến bộ liên tục chứ không phải sự hoàn mỹ.

Code review giúp:

  • Phát hiện lỗi logic, lỗ hổng bảo mật, vấn đề hiệu năng.
  • Đảm bảo code dễ đọc, dễ bảo trì cho người đến sau.
  • Chia sẻ kiến thức về hệ thống giữa các thành viên.
  • Giữ nhất quán về kiến trúc và quy ước.

Phần 1: Dành cho người tạo pull request

Giữ thay đổi nhỏ

Pull request nhỏ được review nhanh hơn, kỹ hơn và ít lỗi lọt qua hơn. Nếu tính năng lớn, hãy chia thành nhiều PR độc lập: tách refactor ra khỏi thay đổi logic, tách phần thêm API ra khỏi phần giao diện.

Viết mô tả rõ ràng

Một mô tả tốt trả lời: thay đổi này làm gì, tại sao cần, đã kiểm thử thế nào, có điểm nào reviewer cần đặc biệt lưu ý.

## Mục đích
Thêm giới hạn 5 lần đăng nhập sai/15 phút để chống brute-force.
 
## Thay đổi chính
- Middleware rateLimitLogin dùng Redis để đếm số lần thử
- Trả về HTTP 429 kèm header Retry-After
 
## Kiểm thử
- Unit test cho middleware, test thủ công trên môi trường staging
 
## Cần lưu ý
- Chưa xử lý trường hợp người dùng sau NAT dùng chung IP

Tự review trước

Đọc lại diff của chính mình trước khi gửi. Bạn sẽ bất ngờ với số lượng console.log quên xóa, đoạn code comment bỏ dở hay lỗi chính tả. Hãy để linter, formatter và test tự động trong CI xử lý những việc máy làm được, giúp reviewer tập trung vào phần quan trọng.

Đón nhận góp ý một cách cởi mở

  • Tách bản thân khỏi code: góp ý nhắm vào code, không phải con người bạn.
  • Hỏi lại khi chưa rõ thay vì đoán ý hoặc phản ứng phòng thủ.
  • Giải thích khi không đồng ý, kèm lý do kỹ thuật. Nếu thảo luận kéo dài, hãy chuyển sang gọi trực tiếp vài phút thay vì tranh luận qua hàng chục bình luận.
  • Cảm ơn người review: họ đã dành thời gian giúp code của bạn tốt hơn.

Phần 2: Dành cho người review

Review kịp thời

Một PR chờ review lâu làm chậm cả nhóm và khiến người viết mất mạch làm việc. Hướng dẫn của Google khuyến nghị phản hồi trong vòng tối đa một ngày làm việc. Nếu bận, hãy báo cho tác giả biết khi nào bạn có thể review.

Thứ tự ưu tiên khi đọc code

  1. Thiết kế: thay đổi có hợp lý, có đặt đúng chỗ trong hệ thống không?
  2. Chức năng: code có làm đúng điều nó định làm, có xử lý edge case không?
  3. Độ phức tạp: có cách nào đơn giản hơn không?
  4. Test: có test phù hợp và test có thực sự kiểm tra đúng hành vi không?
  5. Đặt tên, comment, tài liệu: người khác đọc có hiểu không?
  6. Phong cách: phần này nên để công cụ tự động lo.

Viết bình luận mang tính xây dựng

Cách bạn viết quyết định cảm nhận của người nhận. Một vài nguyên tắc:

  • Nói về code, không nói về người: "Hàm này có thể bị gọi với mảng rỗng" thay vì "Bạn quên xử lý mảng rỗng".
  • Giải thích lý do: góp ý kèm lý do giúp người khác học hỏi thay vì chỉ làm theo.
  • Đặt câu hỏi thay vì ra lệnh khi chưa chắc: "Mình thắc mắc nếu API trả về null thì sao?".
  • Phân biệt mức độ: đánh dấu rõ góp ý nào bắt buộc, góp ý nào chỉ là gợi ý. Nhiều team dùng tiền tố như nit: cho góp ý nhỏ, hoặc theo quy ước Conventional Comments với nhãn như suggestion:, issue:, question:.
  • Khen khi có điểm tốt: một lời ghi nhận cách giải quyết gọn gàng cũng là phản hồi giá trị.

So sánh hai bình luận cho cùng một vấn đề:

  • Kém: "Sai rồi, dùng Map đi."
  • Tốt: "suggestion: Chỗ này mình đang tìm trong mảng trong vòng lặp nên là O(n²). Nếu chuyển sang Map theo id thì sẽ còn O(n), sẽ có ích khi danh sách đơn hàng lớn. Bạn thấy sao?"

Biết khi nào nên chấp thuận

Đừng chặn PR vì sở thích cá nhân không có trong quy ước của team. Nếu thay đổi đã cải thiện codebase và những góp ý còn lại chỉ là chi tiết nhỏ, hãy chấp thuận kèm ghi chú để tác giả tự quyết định.

Xây dựng văn hóa review lành mạnh

  • Thống nhất checklist và quy ước chung, viết thành tài liệu.
  • Luân phiên reviewer để kiến thức không tập trung vào một người.
  • Junior cũng nên được review code của senior: đó là cách học nhanh nhất, và câu hỏi của họ thường giúp code rõ ràng hơn.
  • Định kỳ nhìn lại quy trình: PR có đang quá lớn, thời gian chờ có quá lâu không?

Kết luận

Code review hiệu quả là sự kết hợp giữa kỹ thuật và giao tiếp. Người viết code giữ thay đổi nhỏ, mô tả rõ ràng và đón nhận góp ý cởi mở; người review phản hồi nhanh, ưu tiên đúng vấn đề và viết bình luận tôn trọng, có lý do. Khi cả hai phía cùng hướng đến mục tiêu chung là một codebase tốt hơn, code review sẽ trở thành công cụ học hỏi thay vì nguồn căng thẳng.

Nguồn tham khảo