Người review: phản hồi nhanh, đọc thiết kế trước Trung cấp

Trang này trả lời: reviewer phản hồi nhanh cỡ nào, đọc PR theo thứ tự nào, và khi nào approve dù còn comment.

Phản hồi nhanh, nhưng không cắt ngang việc tập trung

Google đặt mức trần: “One business day is the maximum time it should take to respond”. Đồng thời: đừng tự ngắt lúc đang code tập trung; review ở điểm nghỉ tự nhiên (sau standup, sau bữa trưa, giữa hai task).

Quan trọng hơn tổng thời gian là từng phản hồi đến nhanh:

• Không kịp review hết thì trả lời “Mình xem thiết kế rồi, chi tiết chiều nay” — vẫn tốt hơn im lặng.
• Google ghi nhận phần lớn phàn nàn về quy trình review được giải quyết chỉ bằng cách review nhanh hơn.

Thói quen thực tế cho team backend:

• Hai khung review cố định mỗi ngày (ví dụ 10:00 và 15:00).
• PR quá lớn: yêu cầu chia thành các PR nhỏ nối nhau; không thể chia và không đủ thời gian thì comment về thiết kế tổng thể rồi trả lại để tác giả không bị chặn.

Thiết kế trước, chi tiết sau

Đang tải diagram…

• Đọc mô tả, rồi file chứa logic chính (thường là service và test), rồi mới đến DTO, module, config.
• Đọc test trước đôi khi giúp hiểu PR định làm gì.
• Thiết kế sai thì dừng lại và comment ngay — tác giả có thể đang tiếp tục xây trên nó.

Approve kèm comment

Google cho phép approve khi còn comment chưa xử lý, nếu:

• tác giả đáng tin sẽ sửa, hoặc
• comment là tuỳ chọn, hoặc
• chỉ là việc nhỏ (sắp xếp import, sửa typo gần đó).

Nói rõ trường hợp nào: “Approve, sửa 2 nit trước khi merge là được, không cần mình xem lại”. Khi hai người khác múi giờ, một vòng review thừa là mất một ngày.

Reviewer cũng chịu trách nhiệm

Google: reviewer có “ownership and responsibility” với code mình review, như tác giả. Không đọc kỹ được thì nói rõ “mình chỉ xem phần X”, đừng approve cả PR.

Viết comment thế nào cho tác giả biết cái nào phải sửa: xem Viết comment.

Checklist cho reviewer

1. Phản hồi đầu tiên trong vòng một ngày làm việc; không kịp thì báo khi nào xem.
2. Đọc mô tả; PR này có nên tồn tại không? Có cách đơn giản hơn không?
3. Đọc phần logic chính trước; lỗi thiết kế thì comment ngay, dừng soi chi tiết.
4. Đi qua bảng “nhìn ở đây trước”: transaction, bảo mật, migration, đặt tên.
5. Test có kiểm hành vi thật, có case biên, có fail khi code sai không?
6. Mỗi comment có nhãn mức độ; blocking có lý do (dữ liệu, nguyên tắc, quy ước), không phải sở thích.
7. Ít nhất một praise: khi có điều đáng khen thật.
8. Approve ngay khi PR chắc chắn làm code tốt lên; nói rõ comment còn lại có cần xem lại không.

Tiếp theo: Viết comment và xử lý bất đồng.