Code Review
Code review is a structured inspection of a proposed change by peers, catching defects, spreading knowledge, and enforcing conventions before code reaches the mainline.
Definition
Code review is the practice of having one or more engineers examine a proposed code change for correctness, security, maintainability, and fit with team conventions before it is merged.
Context and scope
Applied to every change that reaches production, including code, migrations, infrastructure definitions, and configuration.
Common misconceptions
- Code review is mainly about formatting and style; tooling should own those concerns
- An approval proves the change is bug-free; it only proves someone examined it
- Only senior engineers can review; any informed peer can catch most issues
Anti-patterns
- Rubber-stamping a thousand-line pull request because the author is trusted
- Blocking a change on personal preference rather than documented conventions
- Using review as the only quality gate while tests are weak
Related concepts
Authoritative source
How it works
The author opens a small pull request with a description of intent, risk, and test evidence. Automated checks such as lint, types, and unit tests run first. Reviewers then examine design, correctness, edge cases, security, and test quality, marking comments as blocking or optional. Approval merges the change; a rejected design returns to discussion before more code is written.
When to use it
Apply review to every change that reaches production: code, migrations, infrastructure, and configuration. Urgent fixes can use pair review or a fast second pair of eyes. Compared with pair programming, asynchronous review scales across time zones but adds latency, so teams often combine both.
Trade-offs
Review catches defects and spreads knowledge, but it costs reviewer time and slows delivery. Large pull requests get rubber-stamped; keeping changes under a few hundred lines improves attention. Review is not a substitute for tests, and style debates should be settled by tooling, not humans.
Example
A pull request adds retries to a payment client. The reviewer notices the retry lacks an idempotency key and asks for a test proving a duplicated request is charged once. The fix lands in forty-five minutes instead of surfacing as a double charge in production.
Misconceptions
Review is not only about formatting; its highest value is design and correctness. Senior engineers do not need to approve everything, and an approval never proves the absence of bugs. Automated tools help but cannot judge intent, trade-offs, or maintainability.
Related concepts
Trunk-based development makes reviews small and frequent; contract testing catches interface drift between services; feature branching changes when review happens in the workflow.