Code Review

practice · computer science · organizing-schema

Peer review of source changes before merge, both for quality and shared understanding.

Code Review is the practice of one or more programmers other than the author examining proposed source-code changes before they are merged into a shared codebase. The practice has deep roots — Michael Fagan's formal inspection methodology at IBM in the 1970s ('Fagan inspection') established structured code review as a documented quality practice — and has been substantially transformed by the modern pull-request workflow popularized by GitHub from 2008 onward, which made asynchronous, threaded code review accessible to most software teams. Modern code review serves multiple purposes: defect detection (finding bugs before merge), knowledge sharing (multiple people understand each change), mentorship and learning, design feedback, codebase consistency, and the social and psychological function of shared accountability for code quality. Empirical research on code review effectiveness has accumulated substantially — Smartbear, Microsoft Research, and Google studies broadly support its value while showing that effectiveness depends substantially on review practices (size of changes, reviewer engagement, time pressure). Microsoft's 2013 'Expectations, Outcomes, and Challenges of Modern Code Review' (Bacchelli & Bird) provides foundational empirical work on how code review actually functions in practice.

Originators

Michael Fagan (formal inspection methodology); modern pull-request workflow popularized by GitHub from 2008 high

Year / Decade

1976 (Fagan inspection); 2008 onward (modern pull-request workflow via GitHub) high

Primary sources

Fagan, M.E. (1976). 'Design and Code Inspections to Reduce Errors in Program Development', IBM Systems Journal, Bacchelli, A. & Bird, C. (2013). 'Expectations, Outcomes, and Challenges of Modern Code Review', ICSE 2013, Cohen, J. (2006). Best Kept Secrets of Peer Code Review (Smart Bear) high

Core components

Pre-merge examination of changes by reviewers other than author
Modern pull-request / merge-request workflow
Threaded comments and discussion
Approval requirements before merge
Automated checks alongside human review (CI, static analysis)
Multiple purposes (defect detection, knowledge sharing, mentorship, design feedback, consistency)
Asynchronous vs synchronous review modes
Distinction from formal Fagan inspection (which was synchronous and meeting-based)

Primary use case

Standard software development practice across most professional engineering organizations; foundation for code quality and shared understanding; basis for many engineering culture and onboarding practices; reference in software engineering research and education; complement to TDD, CI, and other engineering practices; integration with continuous-integration pipelines and merge-protection rules.

Common criticisms

Review effectiveness varies substantially with change size — large changes get rubber-stamped or block-with-nitpicks rather than substantively reviewed
pull-request workflow can produce review-as-bureaucratic-gate that delays delivery without improving quality
bikeshedding (reviewers focusing on trivial style issues while missing substantive concerns) is widespread
reviewer bias and politics can affect review behavior
geographic and time-zone distribution introduces multi-day review latency
defect-detection rates per review hour are often lower than other quality practices (TDD, automated tests)
excessive review cycles can be a productivity tax that more lightweight pair programming or ensemble work would avoid
commercial code-review tools shape behavior in ways teams may not consciously choose.

Lineage

Siblings: Pair Programming, Mob Programming