Code Review
The practice of systematically examining code changes by peers before merging, to ensure quality, catch bugs, and share knowledge across the team.
Detailed Explanation
Code review (also called peer review) is where developers examine each other's code before it is merged to the main branch. It catches bugs, ensures code quality, shares knowledge, and maintains consistency. Code reviews happen through pull requests (GitHub, GitLab) where reviewers leave comments and approve or request changes.
Best practices: keep PRs small (under 400 lines), review promptly (within 24 hours), focus on logic and design (not style—use linters), be constructive (suggest solutions, not just problems), and require approval before merging.
Why It Matters
Code review catches bugs before production, shares knowledge across the team, and maintains code quality. It is the single most effective quality practice in software development.
Real-World Example
A developer opens a PR with 200 lines of code. Two reviewers examine it, find a potential race condition, suggest a simpler approach for one function, and approve with minor suggestions. The bug is caught before it reaches production.
When to Use
For every code change that affects shared code. Even solo developers benefit from self-review and automated review tools (linters, CI checks).
Advantages
- Catches bugs before production
- Shares knowledge across team
- Maintains code consistency
- Improves code design through feedback
- Creates documentation of decisions
Disadvantages
- Adds delay to development
- Can become a bottleneck
- Reviewer fatigue for large PRs
- Can create interpersonal friction
- Requires a healthy team culture
Related Terms
Frequently Asked Questions
How long should a code review take?
Aim for under 24 hours for initial review. Large PRs (>400 lines) should be broken into smaller chunks. Reviewers should spend no more than 60 minutes on a single review. Keep the cycle tight.
What should I look for in a code review?
Focus on: correctness (does it work?), design (is the approach sound?), readability (can others understand it?), security (any vulnerabilities?), and tests (are they adequate?). Don't focus on style—use linters for that.
How do I give constructive code review feedback?
Be specific ("Line 42: consider using a Map here for O(1) lookups"). Ask questions ("What happens if this is null?"). Suggest alternatives. Praise good work. Avoid personal language ("you should") and use impersonal ("this could be").
Should I review my own code before requesting review?
Yes. Self-review catches obvious issues and shows respect for reviewers' time. Read through your changes as if reviewing someone else's code. This often catches typos, logic errors, and missing tests.
Can code reviews replace testing?
No. Code review and testing catch different issues. Code review catches design problems, logic errors, and maintainability issues. Testing catches functional bugs and regressions. You need both.