Code review
Definition
A quality control process in which one or more developers examine a colleague's code changes before they are merged into the main codebase — checking for bugs, adherence to coding standards, performance implications, and design correctness.
Code review (also called peer review or pull request review) is a standard practice in software engineering that serves multiple purposes simultaneously: it catches bugs before they ship, distributes knowledge of the codebase, enforces consistency, and provides a natural teaching moment for both reviewer and author.
The mechanics: Most modern code reviews happen through pull requests (PRs) in GitHub, GitLab, or Bitbucket. The author submits a PR; reviewers read the diff, leave inline comments, and either approve, request changes, or block the merge. Some teams also conduct synchronous code review in person or via screen share, particularly for complex changes.
What reviewers look for:
- Correctness: does the code do what the author says it does?
- Edge cases: what happens with empty inputs, large datasets, concurrent access?
- Security: does the change introduce any vulnerabilities?
- Performance: any obvious regressions or inefficient patterns?
- Readability: will another developer understand this in six months?
- Test coverage: are the changes appropriately tested?
The whiteboard in code review: When a code review surfaces a design question — an architectural trade-off, a better approach to a problem — the conversation sometimes moves to a whiteboard. Snap that whiteboard discussion with BoardSnap to capture the decision and its rationale, which can be added as a comment in the PR or in the project doc.
Code review vs. architecture review: Code review is at the implementation level; architecture review is at the system design level.
Examples
- A team requires two approvals for any PR that touches a payments flow — a coding standards review and a security-focused review.
- A senior engineer uses the code review as a teaching moment, explaining the reason behind a requested change rather than just flagging it.
- A team sets a 24-hour SLA on code reviews to prevent PRs from sitting for days and creating merge conflicts.
- An async remote team does most code reviews in writing but schedules a 15-minute video call for reviews that require a complex back-and-forth.
Snap a code review. Ship its actions.
BoardSnap turns any whiteboard — including this one — into a summary and action plan.