Work Methodologies DefinedTerm

Code Review

Also known as: Peer Review, Pull Request Review, PR Review

Systematic examination of source code by peers to identify bugs, improve quality, and share knowledge.

Updated: 2026-01-04

Definition

Code Review (or Peer Review) is a systematic practice where one or more developers examine code written by colleagues before it’s integrated into the main codebase. The primary goal is to identify bugs, improve design, ensure adherence to coding standards, and share knowledge of the system among the team.

In modern organizations, code review typically happens through Pull Requests (or Merge Requests in GitLab): the developer creates a branch, writes code, opens a PR, and one or more reviewers approve before merging. Tools like GitHub, GitLab, Bitbucket facilitate the process with in-line commenting, approval workflows, and CI/CD integration.

The practice originated in formal inspection introduced by IBM in the 1970s (Fagan inspection), but has evolved into a more agile process integrated into daily workflow. Tech companies like Google, Microsoft, Meta make code review mandatory for every change (zero direct commits to main branch).

Code Review Objectives

Code Quality

Bug detection: reviewers identify logic errors, unhandled edge cases, race conditions, memory leaks. Studies show code review finds 40-60% of defects before testing.

Design improvement: reviewers suggest better patterns, refactoring to reduce complexity, extraction of duplication.

Consistency: enforcement of coding standards (naming conventions, formatting, architectural patterns).

Performance and security: identify inefficiency (N+1 queries, unnecessary memory allocation) and vulnerabilities (SQL injection, XSS, hardcoded credentials).

Knowledge Sharing

Cross-training: reviewers learn parts of the system they don’t know. Author receives feedback from different perspective.

Mentorship: senior developers coach juniors through constructive comments with rationale (“I prefer X to Y because…”).

Collective code ownership: everyone on the team has visibility on all changes. Reduces truck factor (risk of single person who is the only one to know critical module).

Accountability and Standards

Quality gate: review as checkpoint before merge. Prevents “quick and dirty” commits that accumulate technical debt.

Documentation enforcement: reviewers ask for tests, comments, documentation updates before approval.

Team agreement: architectural decisions discussed and shared, not unilateral.

The Process

Typical Workflow (GitHub Pull Request)

1. Branch and develop: developer creates feature branch, writes code, commits locally.

2. Open PR: push branch and open Pull Request with description of what changes and why. Link related issue/ticket.

3. Automated checks: CI runs automated tests, linter, security scan. If fail, dev fixes before asking for human review.

4. Review assignment: author assigns reviewers (1-3 people) or team (e.g., @backend-team). Tool auto-assigns based on CODEOWNERS.

5. Review: reviewers read diff, leave comments (suggestions, questions, must-fix issues), approve or request changes.

6. Address feedback: author responds to comments, makes changes, re-pushes. Conversation threads resolved when agreed.

7. Approval and merge: when all reviewers approve and CI passes, author (or bot) merges to main branch.

Optimal Size

Line of code limit: effective review under 400 lines of diff. Beyond that, reviewer fatigue and drop in defect detection. Best practice: keep PR under 200 LOC when possible.

Review time: less than 60 minutes for effective review. If requires more time, PR probably too large. Split into multiple PRs.

Iterations: ideally 1-2 rounds of feedback. If more than 3 rounds, consider sync discussion (call, pair programming) to unblock.

Best Practices

For the Author

Clear description: PR description explains “what” changes (feature/fix), “why” (business context), “how” (chosen approach). Screenshots for UI changes.

Self-review: before assigning reviewers, author does self-review of their own diff. Catches typos, forgotten debug code, quick fixes.

Small PRs: prefer multiple small PRs to one large. Easier to review, faster turnaround, less risk of conflicts.

Tests included: every PR includes tests demonstrating functionality and preventing regression. Reviewable code = testable code.

Respect reviewer time: mark comments as “nit” if non-blocking, thank for feedback, be responsive (reply within 24h).

For the Reviewer

Timely review: target within 24h for first pass, preferably within 4h to unblock developer. Review blocking development is waste.

Constructive feedback: not “this is wrong”, but “consider X because Y”. Offer alternatives, not just criticism.

Distinguish severity: mark comments as “blocking” (must-fix before merge), “suggestion” (nice-to-have), “nit” (typo, formatting).

Understand context: read PR description and linked issue before reviewing code. Understand goal before criticizing implementation.

Approve incrementally: don’t wait for perfection. If code improves quality bar and doesn’t introduce bugs/debt, approve even if it’s not exactly how you would have written it.

Use automation: don’t waste time on formatting (use auto-fix linter), syntax errors (CI catches them). Focus on logic, design, edge cases.

Adoption and Benefits

Diffusion: 2023 Stack Overflow survey shows 85% of professional developers do code review as standard practice. Practically universal in tech companies.

Impact on quality: 2017 Microsoft study on 6 projects finds code review reduces post-release defect density by 40-60% compared to no review.

Effect on knowledge sharing: Google research finds teams with consistent code review have 35% fewer knowledge silos and 28% faster onboarding of new hires.

ROI: Cisco analysis finds code review costs ~10-15% of development time but reduces debugging and rework cost by 50-80%. Net positive ROI.

Practical Considerations

Tool selection: GitHub/GitLab PR workflow is standard for most teams. Gerrit for Android/Chromium scale. Crucible/Review Board for legacy. Phabricator discontinued.

Automated review: tools like SonarQube, CodeClimate, Codacy, DeepSource automate detection of code smells, security issues, test coverage. Frees reviewers to focus on design.

AI-assisted review: GitHub Copilot, Amazon CodeGuru, DeepCode analyze PRs with ML and suggest improvements. Complement, not substitute for human review.

Balance with velocity: if review becomes bottleneck (PRs pending for days), intervene: reduce PR size, increase number of reviewers, pair programming for complex changes.

Remote-friendly: asynchronous code review is ideal for distributed teams across timezones. Written comments document rationale better than verbal discussion.

Metrics: track PR turnaround time, number of comments per PR, approval rate. Avoid perverse incentives (PR/week quota) that incentivize quantity over quality.

Common Misconceptions

”Code review is only for finding bugs”

No. Multiple objectives: knowledge sharing (often more important than bug detection), mentorship, architectural alignment, standard enforcement. In mature teams, most bugs are caught by automated tests, code review focuses on design and maintainability.

”More reviewers is better”

False. Beyond 2-3 reviewers, diminishing returns and conflicting feedback. For most PRs, 1 competent reviewer is sufficient. Multiple reviewers make sense for critical infrastructure, security-sensitive code, or major architectural changes.

”I must approve only if code is perfect”

Counterproductive. Standard is “improves the codebase, doesn’t introduce regression, and doesn’t accumulate significant debt”. Perfectionism blocks velocity. If you have nits or non-blocking suggestions, approve with comments, don’t hold approval.

”Automated review tools replace human review”

No. Tools automate mechanical checks (linting, formatting, simple security scans), but human review is irreplaceable for evaluating design, readability, edge case logic, architectural fit. Tools and humans are complementary.

Sources

Back to Glossary