Code Review trong SDD

Code review truyền thống chủ yếu nhìn code. Trong SDD, reviewer cần hỏi thêm một câu: code có KHỚP spec không?

Năm quy tắc

1. Spec PR tách khỏi code PR. Spec PR chỉ chứa .md trong /specs (reviewer: PO/BA + Tech Lead); code PR chứa code + test (reviewer: dev). Tách ra để nghiệp vụ review spec mà không bị ngợp bởi diff code.
2. Code PR phải link UC. Tiêu đề feat(UC-042): implement QR expiry validation; test mới có UC ID trong tên describe/test. PR đụng hành vi nghiệp vụ mà không link UC → gắn needs-spec.
3. Review spec trước, code sau. Đọc UC vài phút: “Flow rõ chưa? AC test được không? Exception thiếu case hiển nhiên không?“. Làm ngược lại, reviewer dễ sa vào style/naming rồi bỏ qua rule nghiệp vụ.
4. Test phải map AC. Spec có 5 AC thì test nên có ≥ 5 test case tương ứng. AC quan trọng mà không có test → phải có lý do rõ.
5. Hỏi “AI quyết hay bạn quyết?” Khi thấy block logic phức tạp. Không phải để bắt lỗi AI, mà giúp team biết nguồn gốc quyết định để sau này debug.

Với OpenSpec

Tương đương review proposal.md, delta spec, design.md, tasks.md trong openspec/changes/<name>/ trước /opsx:apply; sau khi code + test xong, /opsx:archive mới merge delta vào spec chính.

Liên quan

• Stakeholder-Centric - spec PR cần approval nghiệp vụ
• Traceable - code PR link UC
• Vai trò trong SDD - ai review gì
• AI-Assisted - câu hỏi “AI quyết hay bạn quyết?”