Code review
kohd reh-VYOO
The practice of having other developers examine code changes before they are merged.
Code review is the practice of having one or more developers examine proposed code changes before they are merged into the main codebase. It is the primary quality control mechanism in software development.
Good code reviews catch bugs, improve code quality, share knowledge, and maintain consistency. A reviewer brings fresh eyes and different experience. They spot edge cases the author missed, suggest simpler approaches, and ensure the code follows team conventions.
Bad code reviews are either rubber stamps ("LGTM" on every PR without reading it) or nitpick festivals (arguing about variable names while ignoring logic errors). The best code reviews focus on correctness, readability, and maintainability, in that order.
Examples
A reviewer catches a security vulnerability.
A developer submits a PR that concatenates user input directly into a SQL query. The reviewer spots the SQL injection risk and suggests using parameterized queries instead. The fix takes 5 minutes. Finding the vulnerability in production would have been a security incident.
A senior engineer reviews a junior engineer's first PR.
The code works but uses an inefficient approach. Instead of just requesting changes, the senior engineer explains why the alternative is better, links to relevant documentation, and offers to pair on the rewrite. The junior engineer learns the pattern and applies it independently on the next PR.
A team has slow code review turnaround.
PRs sit unreviewed for 2-3 days, blocking developers from shipping. The team implements a policy: all PRs must get a first review within 4 hours. Review becomes part of the daily workflow, not a separate task. Cycle time from PR open to merge drops from 3 days to 6 hours.
In practice
Read more on the blog
Frequently asked questions
How long should a code review take?
A well-scoped PR (under 400 lines) should take 15-30 minutes to review thoroughly. If a review takes longer, the PR is probably too large. Time to first review should be under 4 hours to keep development velocity high.
Should every change require a code review?
Almost every change, yes. Exceptions are rare: critical hotfixes where the fix is obvious and time-sensitive, or trivial changes like typo corrections. Even then, a post-merge review is good practice. The overhead of review is almost always worth the quality improvement.
Related terms
A proposal to merge code changes from one branch into another, with review.
"Looks Good To Me" -- a code review approval indicating the reviewer is satisfied with the changes.
Combining code changes from one branch into another, integrating the work.
The accumulated cost of shortcuts and deferred work in a codebase that slows future development.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.