Bài 5 — Coder và Reviewer: cơ chế review chéo hiệu quả

Review chéo là nơi chất lượng thật sự được tạo ra

Coder viết code; Reviewer là "con mắt độc lập" bắt lỗi trước khi test. Nhưng review chéo giữa agent chỉ có giá trị khi Reviewer thật sự độc lập và có tiêu chí rõ. Nếu Reviewer chỉ gật đầu cho qua, bạn đã tốn token mà không được gì.

Nguyên tắc vàng: Reviewer không sửa code

Reviewer chỉ chỉ ra vấn đề, không tự vá. Vì sao? Nếu Reviewer vừa phát hiện vừa sửa, nó sẽ thiên vị bảo vệ bản sửa của chính mình ở vòng sau — mất tính khách quan. Thay vào đó, Reviewer trả về danh sách issue có cấu trúc để Coder xử lý.

{
  "verdict": "changes_requested",
  "issues": [
    {"severity":"high","category":"security","loc":"auth.py:31",
     "msg":"So sánh mật khẩu bằng == dễ bị timing attack, dùng hmac.compare_digest"},
    {"severity":"medium","category":"logic","loc":"auth.py:40",
     "msg":"Không kiểm tra user tồn tại trước khi so hash"}
  ]
}

Vòng lặp Coder ↔ Reviewer

diff = Coder(task)
review = Reviewer(diff, task)
vòng 1: changes_requested → Coder nhận issues → sửa
vòng 2: Reviewer đọc lại → approved
→ chuyển sang Tester

Checklist review theo thứ tự ưu tiên

Bắt Reviewer đi theo thứ tự này để không sa đà vào tiểu tiết:

• Đúng yêu cầu? Code có làm đúng acceptance của task không.
• Lỗi logic? Điều kiện biên, off-by-one, null/empty.
• Bảo mật? Injection, lộ secret, so sánh nhạy cảm, quyền truy cập.
• Xử lý lỗi? Exception có được bắt và báo cáo đúng không.
• Hiệu năng? Vòng lặp N+1, query trong loop.
• Phong cách? Đặt tên, format — ưu tiên thấp nhất.

Các bước thiết lập review chéo

• Cho Reviewer chỉ diff + task + acceptance, không cho toàn bộ repo (giảm nhiễu).
• Bắt buộc mỗi issue có severity để orchestrator quyết định chặn hay cho qua.
• Quy ước: chỉ high/medium mới chặn (changes_requested); low ghi nhận nhưng không chặn.
• Giới hạn số vòng review (ví dụ 3) rồi escalate.
• Truyền lại cho Coder chỉ danh sách issue, không truyền toàn bộ hội thoại cũ.

Chống "reviewer dễ dãi" và "reviewer khó tính vô lý"

• Nếu Reviewer luôn approve → thêm yêu cầu "phải nêu ít nhất các rủi ro đã cân nhắc", và thỉnh thoảng chèn task có lỗi cố ý để kiểm định.
• Nếu Reviewer bới lông tìm vết vô tận → chặn bằng quy tắc severity, chỉ high/medium mới được chặn.

Prompt mẫu cho Coder khi nhận feedback

Bạn là Coder. Đây là code hiện tại và danh sách issue từ Reviewer.
Chỉ sửa đúng các issue được liệt kê, KHÔNG tái cấu trúc ngoài phạm vi.
Trả về diff mới + ghi chú ngắn cách bạn xử lý từng issue.

Khung tư duy: "Review có tăng giá trị không?"

Sau mỗi vòng, tự hỏi: vòng review này có bắt được lỗi thật, hay chỉ đang tranh cãi phong cách? Nếu chỉ là phong cách, hãy hạ severity và cho qua — thời gian của đội quý hơn dấu phẩy.

Sai lầm thường gặp

• Reviewer tự sửa code, mất tính độc lập ở vòng sau.
• Cho Reviewer cả repo khổng lồ, nó lạc trọng tâm và tốn token.
• Không phân severity, mọi ý kiến đều chặn → pipeline tắc.
• Truyền cả lịch sử chat dài cho Coder, làm nhiễu và tăng chi phí.
• Tin tưởng mù quáng verdict: không bao giờ kiểm định Reviewer bằng lỗi cài sẵn.