| Review decision | What the evidence supports | Planning use |
|---|---|---|
| Review time | Home Office engineering guidance says time should be allocated as part of the sprint to review code. | Put review capacity into sprint planning instead of treating it as spare time. |
| Change size | At Google, the usefulness of review feedback decreases as review size increases, and 90% of reviews have fewer than 10 files changed. | Cap the size of each pull request and split large work before it reaches a reviewer. |
| Turnaround | At Google, small changes are reviewed within 1 hour and larger ones within 5 hours. | Use these as a benchmark from one large company, then set your own targets by change size. |
| Reviewer count | More than 75% of Google reviews have just one reviewer, which speeds review but hurts rigor. | One reviewer suits routine changes; add a second where rigor matters more than speed. |
| Automation | Testing and linters can be automated. | Move style and test checks into the pipeline so reviewers can spend their time on logic and risk. |
The figures come from the Home Office engineering guidance on code reviews and a write-up of code reviews at Google.
What is code review? Code review is the human inspection of a proposed change before it is merged, and it works best when time is planned for it and changes stay small enough to read properly.
This page sits within our software development guide. It covers what review does for a team, what reviewers should check, how the common formats differ and a compact process a team can adopt within a sprint.
What review changes for a team
Home Office engineering guidance, last updated 10 April 2025, calls code reviews a vital part of the software lifecycle. It says they keep quality high and share knowledge. A team that reviews consistently gets a second pair of eyes on every change, and more than one person ends up understanding each part of the system.
- Fewer defects in production. Review verifies functionality and prevents bugs and errors from reaching production, so it is cheapest to treat it as a gate before merge rather than a cleanup step afterwards.
- Shared knowledge. Authors learn from comments and reviewers learn how unfamiliar areas work. This suits teams where only one person currently understands a given module.
- A complement to other controls. According to a glossary entry on code review, review often sits alongside testing, static analysis and operational monitoring rather than replacing them. Do not relax test coverage because reviewers will read the code.
- A healthier tone. The Home Office guidance tells reviewers to focus on the code, not the author, and to explain their reasons rather than their feelings. Comments phrased around the code’s behaviour are easier to act on and less likely to stall a merge.
Size, speed and reviewer count
Review size is the variable a team controls most easily. The Google analysis reports that feedback becomes less useful as reviews grow, so large changes tend to receive shallow comments. Splitting work into smaller pull requests is the practical response.
- Review every change. Google requires each code change to be reviewed, with no exceptions. A rule without exceptions is simpler to enforce than one that depends on judging which changes look risky.
- Choose reviewer count deliberately. A single reviewer keeps work moving, but the same analysis notes that it hurts review rigor. Use one reviewer for low-risk, well-tested changes and add another where a mistake would be costly.
- Treat turnaround figures as reference points. The Google figures for small and larger changes show what fast review can look like in a large engineering organisation. A smaller team should pick its own targets and stick to them.
- Clean up before requesting review. Authors at Google run their code through a static analysis tool before sending it, which keeps reviewer time for questions a tool cannot answer.
What reviewers should check
A reviewer’s attention is limited, so spend it on the items below. The list draws on the Home Office guidance and the code review glossary.
- Functional correctness. Confirm the change does what it is meant to do and will not let bugs or errors through to production.
- Tests. Check that the current tests pass and suggest further automation where a manual check could be turned into a test.
- Security of inputs and errors. Look for code injection, user inputs that are not validated and Personally Identifiable Information (PII) in error messages.
- Trust boundaries. Ask whether the change alters trust boundaries, creates new attack surface or bypasses authorization logic.
- Reuse of shared code. Check that the change uses existing shared functions and services rather than duplicating them. The Home Office guidance asks for particular attention here when code may have been generated by AI.
- Reviewer fit. BrowserStack’s guide notes that reviewers must have the relevant expertise to assess the code properly. Assign by knowledge of the area, not by who is free.
A pull request template can turn this list into a checklist that authors complete before asking for review and reviewers confirm afterwards.
How a review works in practice
The same glossary notes that definitions vary across vendors and teams on whether code review means only formal pull requests or also includes pair programming and sign-off. Pick the formats that fit the work, and write down which one applies to which kind of change.
Pull request review
In Git-based systems such as GitHub, developers often create pull or merge requests to ask for review. Sourcery describes an asynchronous peer review after a pull request or merge request has been opened as the most common form. It suits distributed teams because the reviewer reads the diff when time allows.
Pair programming
Pair programming puts two developers at the same computer, with one writing code while the other reviews it in real time. It gives immediate feedback and suits work where a design question needs settling as the code is written. It also uses two people’s time at once, so reserve it for changes where early feedback matters most.
Checklist review
In a checklist review, a checklist is used to evaluate the code. This is the format that most directly supports a compact, repeatable process, and it combines well with pull requests when the checklist lives in the template.
Review platforms and automation
BrowserStack’s guide names GitHub, GitLab and Bitbucket as common platforms, with Crucible and Review Board as review-specific tools. Which one fits is mostly decided by where the code already lives, so choose the platform that hosts your repository before looking at specialist tools.
Automation belongs in the CI/CD pipeline. Sourcery notes that linters and static analysis tools can catch and fix inconsistent style automatically, and checks in CI are one of the ways teams review code. Reviewers then do not need to leave style comments by hand. A pipeline is only as useful as the tests it runs, so see JavaScript Unit Testing: A Practical 2026 Guide To Faster, Safer Code – Interestingdevelopment for building that safety net. Reviewers checking whether a change reuses shared services can find useful context in Microservices Architecture Patterns: Practical Choices For Scalable, Resilient Systems In 2026 – Interestingdevelopment.
A sprint-ready review process
A good code review process is small enough to apply immediately and specific enough that everyone follows it. These choices fit inside a single sprint.
- Plan the time. Allocate review time when the sprint is planned, as the Home Office guidance recommends, so reviews are not squeezed out by feature work.
- Adopt a template. Put the reviewer checks above into the pull request template, so the checklist appears on every change without anyone having to remember it.
- Automate first. Let tests and linters run before a human looks at the change. A failing pipeline is a reason to send the change back before review starts.
- Keep changes small. Ask authors to split work when a diff grows, since feedback quality drops as size rises.
- Review the code, not the person. Frame each comment around the code and the reason for the suggestion.
- Match the format to the risk. Use asynchronous pull request review as the default, pair programming where live discussion helps and a second reviewer where rigor matters.
After the sprint, check whether reviews were completed in the time you planned and whether size limits were respected. Adjust the template and targets from what actually happened.
Frequently asked questions
Does code review replace automated testing?
No. Review complements testing, static analysis and monitoring. Reviewers also check that existing tests pass and can suggest more automation.
Is pair programming a form of code review?
It can be. Definitions vary, but pair programming gives real-time review because one developer writes while the other reads. Many teams still add a pull request review before merge.
Who should review a change?
Someone with the relevant expertise to assess the code properly. For routine changes one qualified reviewer is common practice, while riskier changes justify more.
Which platforms support pull request review?
GitHub, GitLab and Bitbucket support pull or merge requests, and Crucible and Review Board are review-specific tools. Start with the platform that already hosts your repository.
