Code Review Culture: Xây Dựng Văn Hóa Review Hiệu Quả
Google's engineering practices document viết: "Code review là cơ hội để cải thiện chất lượng toàn codebase, không phải để chứng minh reviewer thông minh hơn author." SmartBear research trên 10 teams kết luận: code review phát hiện 60% defects trước khi code đến QA — hiệu quả hơn unit testing (25%). Nhưng thực tế ở nhiều team, code review trở thành: nitpicking về style, gatekeeping bằng ego, hoặc tệ hơn — rubber stamping (approve mà không đọc). Bài viết này chia sẻ cách xây dựng văn hóa review lành mạnh — nơi mọi người đều học, code đều tốt hơn, và PR không phải chiến trường.
Reviewer Mindset: 4 Nguyên Tắc
🤝 Nguyên tắc 1: Critique Code, Not People
❌ "Sao anh lại viết kiểu này?" → ✅ "Hàm này có thể đơn giản hơn nếu dùng pattern X." Luôn nói về code, không nói về người viết code. Dùng "chúng ta" thay "anh/em": "Chúng ta nên thêm error handling ở đây" thay vì "Em quên error handling." Research: Microsoft found that constructive tone trong reviews tăng author receptiveness 35% so với critical tone — cùng feedback nhưng khác delivery.
📚 Nguyên tắc 2: Explain Why, Not Just What
❌ "Đổi thành async/await" → ✅ "Dùng async/await ở đây vì callback hiện tại sẽ gây khó debugging khi có lỗi — stack trace bị mất nghĩa là production incident sẽ khó root cause." Reviewer phải giải thích tại sao suggest thay đổi. Đây là cơ hội teaching moment — đặc biệt quan trọng khi review code của junior developers. Mỗi review comment với "why" là 1 micro-learning session.
⚡ Nguyên tắc 3: Label Comment Priority
Label comments rõ ràng: [BLOCKING] — bug thật sự, security issue, logic error → cần fix trước merge. [NIT] — style preference, naming suggestion → nice-to-have, không block merge. [QUESTION] — tôi chưa hiểu approach, cần giải thích → không phải criticism. [SUGGESTION] — có cách khác tốt hơn nhưng cách hiện tại cũng okay → non-blocking. Nếu 10 comments đều unlabeled, author overwhelmed. Phân loại giúp author biết ưu tiên gì — focus energy vào blocking issues.
🎯 Nguyên tắc 4: Review What Matters
Focus reviewer time vào high-value areas: correctness (logic bugs), security (injection, auth bypass), performance (N+1 queries, memory leaks), maintainability (coupling, abstraction level). Để AI/tools xử lý mechanical checks: style (Prettier), formatting (ESLint), naming conventions (linter rules), import ordering (auto-sort). Thời gian reviewer quý hơn thời gian CI/CD — đừng waste human attention vào những thứ máy làm tốt hơn và nhanh hơn.
PR Author Etiquette
Code review là two-way street. Author cũng có trách nhiệm tạo PR dễ review — PR khó review = review chậm hoặc review chất lượng kém.
① Keep PRs small: Maximum 400 LOC (Google guideline). Research: PRs > 500 LOC có review quality giảm exponentially — reviewer fatigue sau 200-300 LOC. Tách feature lớn thành nhiều PR nhỏ, mỗi PR tự đứng vững (compilable, testable, deployable independently). ② Write quality descriptions: PR description trả lời: What changed, Why (business context), How (approach/trade-offs), Testing done (manual + automated). Screenshot/screencast cho UI changes. Link to ticket. ③ Self-review trước khi assign: Đọc lại diff của mình — sẽ bắt được 30-50% issues mà không cần người khác. Remove debug logs, commented-out code, TODOs không cần thiết. ④ Respond professionally: Khi nhận comment, đừng defensive. Nếu không đồng ý, giải thích lý do technically — data, not emotion. "Tôi chọn approach này vì X, Y — nhưng happy to discuss alternatives."
Review Speed SLA
Google quy định: review trong 1 business day. Slow reviews = blocked developers = lower productivity = frustrated team. BanhCuonFlow team áp dụng SLA chặt hơn:
4 giờ
First response (comment hoặc approve). Không để PR "im lặng" — im lặng = uncertainty cho author.
8 giờ
Complete review với all comments done. Nếu cần thêm time → comment "sẽ review kỹ sáng mai, ETA 9h."
24 giờ
Author respond to all comments + push fixes. Không để PR pending quá 1 ngày sau review.
4 Anti-Patterns Cần Tránh
🚫 Rubber Stamping: "LGTM" approve ngay mà không đọc code. Đặc biệt nguy hiểm cho PRs ảnh hưởng security hoặc data integrity. Nếu không có thời gian review kỹ, nói thẳng và delegate cho người khác — đừng fake approve.
🚫 Gatekeeping: Senior block PR vì "tôi sẽ viết khác" dù approach author đúng, readable, và maintainable. Many correct solutions exist cho 1 problem — nếu code works và maintainable, approve. Đừng confuse "different" với "wrong."
🚫 Review Fatigue: Review hàng chục PRs trong 1 session cuối tuần. Chất lượng review giảm nghiêm trọng sau 60+ phút continuous review. Spread reviews throughout the day, max 2-3 PRs mỗi session, rest giữa các sessions.
🚫 Style Wars: "Tôi thích camelCase, anh dùng snake_case" — đây là việc của linter, không phải reviewer. Agree on style guide 1 lần (eslint config, prettier config), enforce bằng CI/CD, never discuss again in reviews.