Code review: review và được review như một senior Trung cấp

Vấn đề

Hai kiểu team review hỏng hay gặp nhất:

• Team “LGTM”: PR 1.800 dòng được approve sau 4 phút. Bug double-charge lọt production vì không ai đọc tới hàm retry ở file thứ 23.
• Team “gác cổng”: PR 40 dòng chờ 3 ngày, nhận 27 comment về dấu chấm phẩy, rồi bị yêu cầu “viết lại theo cách của anh”.

Cả hai đều tốn tiền. Cụm này là bộ quy tắc để review nhanh, có trọng tâm và không làm ai ghét nhau, cho cả người viết PR lẫn reviewer.

Đọc theo thứ tự nào

Đang tải diagram…

Trong cụm này

Phần	Trả lời câu hỏi
Ưu tiên review	Review để làm gì? Nhìn gì trước? Một PR đi từ draft tới merge thế nào?
Người viết PR	PR to cỡ nào? Mô tả PR gồm gì? Tự review bắt được gì?
Người review	Phản hồi nhanh cỡ nào? Đọc PR theo thứ tự nào? Khi nào approve kèm comment?
Viết comment	Gắn nhãn mức độ ra sao? Comment tồi và tốt khác gì? Bất đồng thì xử lý thế nào?
Anti-pattern, metric	Review hỏng trông ra sao? Đo gì mà không làm hỏng review? Ngoại lệ nào hợp lý?
Lỗi hay gặp	Comment, mô tả PR và bug code nào hay lọt, và comment nào nên bắt chúng?

Tóm tắt quyết định

Câu hỏi	Mặc định	Lý do
Tiêu chuẩn để approve	PR chắc chắn làm code tốt lên, dù chưa hoàn hảo	Google: không có code hoàn hảo, chỉ có code tốt hơn
Nhìn gì trước	Thiết kế, tính đúng → bảo mật, dữ liệu → test → dễ đọc → style	Lỗi thiết kế phát hiện muộn là lỗi đắt nhất
Style, format	Prettier, ESLint, CI lo; con người không comment	Máy kiểm nhanh hơn người
Kích thước PR	Một mục đích; ~100 dòng hợp lý, ~1.000 dòng thường quá lớn	Số tham khảo của Google Small CLs
Thời gian phản hồi	Tối đa một ngày làm việc	Phần lớn phàn nàn về review biến mất khi review nhanh hơn
Comment không bắt buộc	Gắn nhãn nit: / suggestion (non-blocking):	Tác giả biết cái nào phải sửa
Bất đồng kéo dài	Call sau 2 vòng comment (quy ước của cụm), ghi kết luận vào PR	Thread dài không hội tụ

Tóm tắt

Tóm tắt

• Approve khi PR chắc chắn làm code tốt lên, không đợi hoàn hảo.
• Thứ tự: tính đúng và thiết kế → bảo mật, dữ liệu → test → dễ đọc → style; style giao cho máy.
• Tác giả quyết định phần lớn chất lượng review: PR nhỏ, tách refactor, mô tả có vì sao/test/rủi ro/rollback, tự review trước.
• Reviewer phản hồi trong một ngày làm việc, đọc thiết kế trước, gắn nhãn mức độ cho từng comment.
• Bất đồng: dữ liệu và quy ước trước, call sau hai vòng, ghi kết luận vào PR, escalate là bước cuối.
• Đo quy trình (độ trễ, kích thước, số vòng), không đo người.

Tiếp theo: Ưu tiên review.