Code Review Process | Quality + Knowledge Sharing
Establish code review practices with GitScrum's GitHub, GitLab, Bitbucket integrations. Track PR status on tasks, improve quality, and spread knowledge across the team.
17 min read
Code review is more than bug catching—it's a quality gate, knowledge sharing mechanism, and team alignment tool. Effective review processes balance thoroughness with speed, ensuring high standards without becoming a bottleneck. GitScrum's Git integrations connect reviews to your project workflow, maintaining visibility and accountability across the development process.
Code Review Fundamentals
Purpose of Code Review
WHY WE REVIEW CODE:
┌─────────────────────────────────────────────────────────────┐
│ OBJECTIVES BEYOND BUG FINDING │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRIMARY OBJECTIVES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ 🐛 DEFECT DETECTION ││
│ │ Catch bugs before they reach production ││
│ │ Logic errors, edge cases, security issues ││
│ │ ││
│ │ 📚 KNOWLEDGE SHARING ││
│ │ Spread understanding across the team ││
│ │ Reduce knowledge silos, bus factor ││
│ │ ││
│ │ 📏 STANDARD ENFORCEMENT ││
│ │ Maintain consistent code patterns ││
│ │ Architecture alignment, style consistency ││
│ │ ││
│ │ 🎓 MENTORING ││
│ │ Teach and learn through review dialogue ││
│ │ Junior development, senior oversight ││
│ │ ││
│ │ 🤝 COLLECTIVE OWNERSHIP ││
│ │ Multiple people understand each change ││
│ │ Better maintenance, faster debugging ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ REVIEW IS NOT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✗ Quality assurance replacement (need testing too) ││
│ │ ✗ Performance evaluation (separate process) ││
│ │ ✗ Architectural design time (too late for big changes) ││
│ │ ✗ Style enforcement (use automated tools) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
What to Review
REVIEW FOCUS AREAS:
┌─────────────────────────────────────────────────────────────┐
│ PRIORITIZING REVIEW ATTENTION │
├─────────────────────────────────────────────────────────────┤
│ │
│ HIGH PRIORITY (Always check): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ✓ CORRECTNESS ││
│ │ Does it do what it's supposed to? ││
│ │ Edge cases handled? ││
│ │ Error scenarios covered? ││
│ │ ││
│ │ ✓ SECURITY ││
│ │ SQL injection, XSS vulnerabilities? ││
│ │ Authentication/authorization correct? ││
│ │ Sensitive data handling appropriate? ││
│ │ ││
│ │ ✓ DESIGN ││
│ │ Does it fit the architecture? ││
│ │ Appropriate abstraction level? ││
│ │ Maintainable and extensible? ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MEDIUM PRIORITY (Usually check): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ○ TESTABILITY ││
│ │ Are there adequate tests? ││
│ │ Tests cover the right cases? ││
│ │ Easy to test changes? ││
│ │ ││
│ │ ○ PERFORMANCE ││
│ │ Any obvious inefficiencies? ││
│ │ Database query patterns? ││
│ │ Memory usage concerns? ││
│ │ ││
│ │ ○ DOCUMENTATION ││
│ │ Complex logic explained? ││
│ │ Public APIs documented? ││
│ │ README updated if needed? ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LOWER PRIORITY (Automate if possible): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ △ Formatting and style → Use linters/formatters ││
│ │ △ Import organization → Automate with tools ││
│ │ △ Naming conventions → Define rules, enforce with CI ││
│ │ △ Code structure → Use static analysis ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Integrating with GitScrum
PR Visibility
GITSCRUM GIT INTEGRATION:
┌─────────────────────────────────────────────────────────────┐
│ CONNECTING PULL REQUESTS TO TASKS │
├─────────────────────────────────────────────────────────────┤
│ │
│ AUTOMATIC LINKING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When developers include task ID in branch/PR: ││
│ │ ││
│ │ Branch naming: ││
│ │ feature/PROJ-123-user-authentication ││
│ │ ││
│ │ PR title: ││
│ │ PROJ-123: Add user authentication flow ││
│ │ ││
│ │ GitScrum automatically: ││
│ │ ├── Links PR to task PROJ-123 ││
│ │ ├── Shows PR status on task card ││
│ │ ├── Updates activity feed ││
│ │ └── Notifies assignees of PR events ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TASK VIEW WITH PR: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PROJ-123: User Authentication │ ││
│ │ │ Status: In Review │ ││
│ │ │ │ ││
│ │ │ Linked Pull Requests: │ ││
│ │ │ ┌─────────────────────────────────────────────────┐ │ ││
│ │ │ │ 🟡 PR #456 - Add user authentication flow │ ││
│ │ │ │ Status: Changes requested │ ││
│ │ │ │ Reviews: 1/2 approved │ ││
│ │ │ │ CI: ✓ Passing │ ││
│ │ │ │ Updated: 2h ago │ ││
│ │ │ └─────────────────────────────────────────────────┘ │ ││
│ │ │ │ ││
│ │ │ Activity: │ ││
│ │ │ • @chen left review with 2 comments (1h ago) │ ││
│ │ │ • @sarah pushed 3 commits (3h ago) │ ││
│ │ │ • PR opened by @sarah (1d ago) │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BOARD VISIBILITY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Code Review column shows PR status: ││
│ │ ││
│ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ││
│ │ │ PROJ-123 │ │ PROJ-456 │ │ PROJ-789 │ ││
│ │ │ Auth flow │ │ Dashboard │ │ Reports │ ││
│ │ │ │ │ │ │ │ ││
│ │ │ 🟢 PR #456 │ │ 🟡 PR #461 │ │ 🔴 PR #458 │ ││
│ │ │ Approved │ │ Reviewing │ │ Changes │ ││
│ │ └───────────┘ └───────────┘ └───────────┘ ││
│ │ ││
│ │ Quick filters: [All PRs] [Needs Review] [Approved] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Review Workflow
REVIEW PROCESS INTEGRATION:
┌─────────────────────────────────────────────────────────────┐
│ END-TO-END REVIEW WORKFLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. TASK STARTED → IN PROGRESS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Developer: ││
│ │ • Moves task to "In Progress" ││
│ │ • Creates branch with task ID ││
│ │ • Develops and tests locally ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 2. PR CREATED → IN REVIEW │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Developer: ││
│ │ • Opens PR with task ID in title ││
│ │ • GitScrum auto-moves task to "Code Review" ││
│ │ • Requests reviewers ││
│ │ ││
│ │ Reviewers notified via: ││
│ │ • GitScrum notifications ││
│ │ • Slack/Teams integration ││
│ │ • Email (based on preferences) ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 3. REVIEW CYCLE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Reviewers: ││
│ │ • Review code in GitHub/GitLab ││
│ │ • Leave comments, approve, or request changes ││
│ │ ││
│ │ Task reflects: ││
│ │ • Review status (pending/approved/changes requested) ││
│ │ • CI status (passing/failing) ││
│ │ • Comment count ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 4. APPROVED → READY TO MERGE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ All reviewers approved: ││
│ │ • PR status shows "Approved" ││
│ │ • Task can move to "Ready for QA" or merge directly ││
│ │ • Developer or tech lead merges PR ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 5. MERGED → DONE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ On merge: ││
│ │ • GitScrum can auto-move task to "Done" ││
│ │ • Or move to "Deployed" for deployment tracking ││
│ │ • Activity log updated ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Review Guidelines
For Authors
SUBMITTING CODE FOR REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ SETTING UP REVIEWERS FOR SUCCESS │
├─────────────────────────────────────────────────────────────┤
│ │
│ BEFORE REQUESTING REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ □ Self-review your changes first ││
│ │ □ Run all tests locally (they should pass) ││
│ │ □ Check linting/formatting passes ││
│ │ □ Remove debug code, console.log, TODOs ││
│ │ □ Verify PR is reasonably sized (<400 lines) ││
│ │ □ Add tests for new functionality ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PR DESCRIPTION TEMPLATE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ## Summary ││
│ │ Brief explanation of what this PR does ││
│ │ ││
│ │ ## Task ││
│ │ Closes PROJ-123 ││
│ │ ││
│ │ ## Changes ││
│ │ - Added authentication middleware ││
│ │ - Created user session management ││
│ │ - Updated API routes for protected endpoints ││
│ │ ││
│ │ ## Testing ││
│ │ - [ ] Unit tests added for AuthService ││
│ │ - [ ] Integration tests for login flow ││
│ │ - [ ] Manual testing of OAuth flow ││
│ │ ││
│ │ ## Screenshots (if UI change) ││
│ │ [Before/After images] ││
│ │ ││
│ │ ## Notes for Reviewers ││
│ │ Focus on security in AuthMiddleware ││
│ │ Session timeout logic in SessionManager ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SMALL, FOCUSED PRs: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PR Size │ Review Time │ Quality ││
│ │────────────────┼───────────────┼───────────────────────││
│ │ < 100 lines │ 15-30 min │ Thorough ││
│ │ 100-400 lines │ 30-60 min │ Good ││
│ │ 400-800 lines │ 60-90 min │ Declining ││
│ │ > 800 lines │ Often skimmed │ Poor (split the PR!) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RESPONDING TO FEEDBACK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Respond to every comment ││
│ │ ✓ Ask for clarification if unclear ││
│ │ ✓ Explain reasoning if you disagree ││
│ │ ✓ Push fixes as new commits (for traceability) ││
│ │ ✓ Re-request review when ready ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
For Reviewers
GIVING EFFECTIVE REVIEWS:
┌─────────────────────────────────────────────────────────────┐
│ REVIEW BEST PRACTICES │
├─────────────────────────────────────────────────────────────┤
│ │
│ REVIEW MINDSET: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Review the code, not the person ││
│ │ ✓ Assume positive intent ││
│ │ ✓ Consider multiple valid approaches ││
│ │ ✓ Be explicit about severity (blocker vs suggestion) ││
│ │ ✓ Offer alternatives, not just criticism ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMMENT TYPES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BLOCKING (Must fix): ││
│ │ "🔴 BLOCKER: This SQL is vulnerable to injection. ││
│ │ Use parameterized queries instead: ││
│ │ db.query('SELECT * FROM users WHERE id = ?', [userId])"││
│ │ ││
│ │ SUGGESTION (Should consider): ││
│ │ "💡 SUGGESTION: Consider using async/await here ││
│ │ for better readability. Not blocking but would ││
│ │ improve maintainability." ││
│ │ ││
│ │ QUESTION (Need clarification): ││
│ │ "❓ QUESTION: Why are we caching this for 24 hours? ││
│ │ Is there a specific requirement?" ││
│ │ ││
│ │ NIT (Minor, optional): ││
│ │ "📝 NIT: Typo in variable name 'recieve' → 'receive' ││
│ │ Feel free to ignore if you prefer." ││
│ │ ││
│ │ PRAISE (Positive feedback): ││
│ │ "👍 Nice approach! This handles the edge cases ││
│ │ elegantly." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIME EXPECTATIONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Review requests should be handled within: ││
│ │ ││
│ │ First response: < 4 hours during work hours ││
│ │ Full review: < 1 business day ││
│ │ Re-review: < 4 hours (smaller changes) ││
│ │ ││
│ │ If can't review, decline and suggest alternative ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ APPROVAL CRITERIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ □ Code works correctly (tested or verified) ││
│ │ □ No security vulnerabilities introduced ││
│ │ □ Follows team architecture and patterns ││
│ │ □ Adequate test coverage ││
│ │ □ Documentation updated if needed ││
│ │ □ No blocking comments remaining ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Team Practices
Review Assignments
WHO REVIEWS WHAT:
┌─────────────────────────────────────────────────────────────┐
│ REVIEWER ASSIGNMENT STRATEGIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ CODE OWNERS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Define owners by directory/file pattern: ││
│ │ ││
│ │ # CODEOWNERS file ││
│ │ /src/auth/* @security-team ││
│ │ /src/api/* @backend-team ││
│ │ /src/components/* @frontend-team ││
│ │ /infrastructure/* @devops ││
│ │ *.md @docs-team ││
│ │ ││
│ │ Auto-assigns reviewers based on changed files ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ REVIEWER COUNT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Change Type │ Required Reviewers ││
│ │───────────────────────┼────────────────────────────────││
│ │ Standard feature │ 1 peer + 1 senior ││
│ │ Security-related │ 1 peer + security lead ││
│ │ Database changes │ 1 peer + DBA/data lead ││
│ │ Architecture changes │ 2 seniors/architects ││
│ │ Hotfix (urgent) │ 1 senior (expedited) ││
│ │ Documentation only │ 1 reviewer ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ROTATION STRATEGIES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ROUND-ROBIN: ││
│ │ Distribute review load evenly across team ││
│ │ Each person gets similar review count per sprint ││
│ │ ││
│ │ EXPERTISE-BASED: ││
│ │ Match reviewer expertise to change type ││
│ │ Database changes → people who know DB well ││
│ │ ││
│ │ PAIRING: ││
│ │ Always include one junior + one senior ││
│ │ Knowledge transfer in both directions ││
│ │ ││
│ │ AUTHOR'S CHOICE + RANDOM: ││
│ │ Author picks 1 reviewer they think is best ││
│ │ System randomly assigns 1 more for diversity ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Review Metrics
MEASURING REVIEW HEALTH:
┌─────────────────────────────────────────────────────────────┐
│ TRACKING REVIEW PROCESS EFFECTIVENESS │
├─────────────────────────────────────────────────────────────┤
│ │
│ KEY METRICS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metric │ Target │ Warning ││
│ │─────────────────────┼───────────────┼──────────────────││
│ │ First response time │ < 4 hours │ > 8 hours ││
│ │ PR cycle time │ < 24 hours │ > 48 hours ││
│ │ Avg review rounds │ < 2 rounds │ > 3 rounds ││
│ │ Comments per PR │ 3-8 comments │ < 1 or > 15 ││
│ │ Review depth │ All files │ Partial review ││
│ │ Approval rate │ 80-95% │ < 70% or 100% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ INTERPRETING METRICS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Very few comments per PR: ││
│ │ → Reviews might be too shallow ││
│ │ → PRs might be too perfect (unlikely) ││
│ │ → Review culture might discourage feedback ││
│ │ ││
│ │ Too many comments per PR: ││
│ │ → PRs too large, should be split ││
│ │ → Standards not clear, lots of style comments ││
│ │ → Design discussions happening in PR (too late) ││
│ │ ││
│ │ Long cycle time: ││
│ │ → Reviewers overloaded ││
│ │ → PRs too large to review quickly ││
│ │ → Review not prioritized ││
│ │ ││
│ │ 100% approval rate: ││
│ │ → Rubber-stamping, not real reviews ││
│ │ → Should see some iteration ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Automation
CI Integration
AUTOMATED CHECKS BEFORE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ LET MACHINES CHECK WHAT MACHINES CHECK BEST │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRE-REVIEW AUTOMATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CI Pipeline (must pass before review): ││
│ │ ││
│ │ □ Build compiles successfully ││
│ │ □ All tests pass ││
│ │ □ Code coverage above threshold ││
│ │ □ Linting passes (no style issues) ││
│ │ □ Formatting correct (Prettier, Black, etc.) ││
│ │ □ Security scan passes (no critical vulnerabilities) ││
│ │ □ Type checking passes (TypeScript, mypy) ││
│ │ ││
│ │ If CI fails → Author must fix before requesting review ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AUTOMATED REVIEW COMMENTS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Bots can comment on common issues: ││
│ │ ││
│ │ • "PR is too large (1,247 lines). Consider splitting." ││
│ │ • "Missing test coverage for new function X." ││
│ │ • "Deprecated API usage detected in file Y." ││
│ │ • "This file has changed 47 times in 30 days - high ││
│ │ change area, consider extra review." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ GITSCRUM VISIBILITY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Task shows CI status: ││
│ │ ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PROJ-123: User Authentication │ ││
│ │ │ │ ││
│ │ │ PR #456 CI Status: │ ││
│ │ │ ✓ Build Passed │ ││
│ │ │ ✓ Tests 142/142 passed │ ││
│ │ │ ✓ Linting No issues │ ││
│ │ │ ✓ Coverage 87% (≥80% required) │ ││
│ │ │ ✓ Security No vulnerabilities │ ││
│ │ │ │ ││
│ │ │ Ready for review ✓ │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Common Anti-Patterns
What to Avoid
CODE REVIEW ANTI-PATTERNS:
┌─────────────────────────────────────────────────────────────┐
│ PRACTICES THAT HARM REVIEW EFFECTIVENESS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✗ RUBBER STAMPING │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Problem: Approving without reading ││
│ │ Sign: Quick approvals, no comments, bugs in production ││
│ │ Fix: Require minimum review time, track comment rate ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ✗ GATEKEEPING │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Problem: Using review to block PRs for personal style ││
│ │ Sign: Same person blocks everything, opinion-based ││
│ │ Fix: Clear standards, escalation path, rotate reviewers ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ✗ NEVERENDING REVIEW │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Problem: New comments after every round ││
│ │ Sign: 5+ review rounds, moving goalposts ││
│ │ Fix: All feedback in first round, time-box reviews ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ✗ DRIVE-BY REVIEWS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Problem: Leaving comments but not approving/blocking ││
│ │ Sign: PRs stuck with comments but no decision ││
│ │ Fix: Must approve, request changes, or explicitly pass ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ✗ REVIEWING ONLY HAPPY PATH │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Problem: Only looking at main logic, ignoring edges ││
│ │ Sign: Edge case bugs in production ││
│ │ Fix: Checklist including error handling, null checks ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ✗ DESIGN REVIEW IN CODE REVIEW │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Problem: Questioning architecture after code is written ││
│ │ Sign: "Why are we doing it this way?" in PR ││
│ │ Fix: Design reviews before coding, RFCs for big changes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Best Practices Summary
Do's
EFFECTIVE CODE REVIEW PRACTICES:
✓ AUTOMATE STYLE CHECKS
Let linters handle formatting, focus on logic
✓ KEEP PRs SMALL
<400 lines enables thorough review
✓ RESPOND QUICKLY
<4 hours first response keeps flow
✓ BE SPECIFIC IN FEEDBACK
Show the alternative, not just the problem
✓ LABEL COMMENT SEVERITY
Blocker vs suggestion vs nit
✓ CELEBRATE GOOD CODE
Praise builds culture
Don'ts
CODE REVIEW PITFALLS:
✗ REVIEWING GIANT PRs
>800 lines will be skimmed, not reviewed
✗ STYLE DEBATES IN REVIEWS
Automate with formatters, or document standards
✗ APPROVING WITHOUT READING
Defeats the purpose entirely
✗ BEING HARSH
Code review is for code, not person
✗ IGNORING TESTS
Test quality matters as much as code