Code Review Practices
The problem
A single author reviewing their own code misses their own blind spots by definition — a second set of eyes catches bugs, design problems, and unclear code before it merges, and spreads knowledge of the codebase across a team instead of concentrating it in one person.
Why now
Version control with Git established the branch-and-merge structure code review sits inside — a review happens on a pull request, a specific point in the commit DAG, before it's merged into shared history. Coupling and cohesion gave the specific vocabulary reviewers use to judge whether a change is well-structured, not just correct.
Mental model
Code review is a deliberate checkpoint inserted into the merge process from version-control-with-git: a change is proposed as a pull request, a reviewer evaluates it against both correctness and the coupling/cohesion judgment already covered, and only an approved change proceeds to merge — catching problems while they're still cheap to fix, before they're baked into shared history everyone else builds on.
Requires
- Version Control with GitEngineering Practices
Code review is structurally a checkpoint on a pull request — a specific point in the commit graph already covered — before it merges into shared history; you need that branching model as the mechanism review attaches to.
- Coupling & CohesionSoftware Architecture
Good code review isn't just checking correctness — it's judging whether a change is well-placed and well-structured, which is exactly the coupling and cohesion vocabulary already covered, now applied as a review criterion.
Used in
- Pull request review on every collaborative software team
- Catching bugs and design issues before they reach production, when they're cheapest to fix
- Spreading codebase knowledge across a team instead of concentrating it in one author
- Style and convention consistency enforced through review rather than after-the-fact cleanup
Projects
- Review a real or sample pull request, leaving specific, actionable feedback that distinguishes a must-fix bug from a stylistic preference
- Write a clear, well-scoped pull request description for a real change, anticipating the questions a reviewer would naturally ask
Examples
- A reviewer catching a race condition before merge saves the cost of an actual production incident and its investigation
- A well-written PR description explaining why a change was made, not just what changed, lets a reviewer evaluate the reasoning, not just the diff
Resources
Mastery checklist
- I can review a change and distinguish a correctness issue from a stylistic preference
- I can write clear, specific, actionable review feedback
- I can write a pull request description that anticipates a reviewer's likely questions
- I can explain why code review benefits the team even when the reviewer trusts the author