What Is a Code Review, and What Should Reviewers Actually Check?

01

A code review is a second opinion on a software decision

A code review is a structured peer review of a proposed code change before it is merged into the main codebase. The author opens a pull request or merge request, explains the change and asks one or more developers to inspect it. The reviewer can approve it, leave comments or request changes.

The tool is only the meeting place. The review itself is the thinking: understanding what the change is meant to achieve, reading the implementation, checking the evidence and deciding whether it is safe and sensible to merge.

That distinction matters because a pull request can have a green test badge and still contain a poor decision. Automated checks are good at repeatable rules. They can format code, run tests, find known vulnerabilities and flag obvious mistakes. A human reviewer can ask whether the right problem has been solved and whether the code behaves properly in the wider system.

GitLab describes code review as a peer assessment that improves code quality before code is merged and shipped. GitHub supports the same workflow through comments, approvals and requests for changes. The value is not the button that says approve. It is the independent reasoning that should happen before somebody presses it.

02

A four-line change can carry a large business risk

Imagine a business portal where managers approve supplier invoices. The existing rule allows approval up to £5,000. A new requirement raises the limit to £25,000 for department managers.

The visible code change might be tiny. One amount changes. A test is updated. The screen still works. From the author's point of view, the task can look complete.

A useful reviewer looks beyond the changed number. Can somebody approve their own invoice? Does the higher limit apply to every department or only selected ones? Is the approval recorded in the audit log? What happens when an invoice is edited after approval? Does the notification say who approved it and under which rule? Will an existing finance report interpret the new status correctly?

None of those questions are about bracket placement. They are about the business rule and the paths around it. The reviewer is not trying to prove the author wrong. They are trying to find the assumptions that one person, working closely on the task, can easily stop seeing.

That is why code review matters even when experienced developers write the code. Experience improves judgement, but it does not make anybody immune to incomplete requirements, hidden dependencies or ordinary human oversight.

03

What should a code reviewer actually check?

Google's engineering guidance puts overall design and functionality near the start of a review. That is a useful priority. A reviewer should understand the purpose and shape of the change before getting pulled into individual lines.

The exact depth depends on the risk. A copy change on an internal help page does not need the same scrutiny as a new payment rule, permission check or database migration. The table below gives a sensible starting point rather than a rigid script.

04

Tests support the review, but they do not perform it

Automated tests are part of the evidence. They show that selected behaviours still work and help protect those behaviours from later changes. Static analysis, formatting and security scanning can remove a great deal of repetitive checking from the reviewer's workload.

The reviewer still needs to review the tests. A test can pass because it asserts the wrong result, avoids the awkward branch or uses data that never represents the real condition. Google's guidance makes this point directly: tests do not test themselves.

Return to the invoice example. A test proving that a department manager can approve £20,000 is useful. It does not prove that the manager cannot approve their own invoice, that £25,001 is rejected or that the event reaches the audit history. The test suite can be green while the most important control remains untested.

AI coding and review tools fit the same pattern. They can summarise a change, point out suspicious code and suggest tests. They can reduce routine effort. They do not own the business context, and they should not become an excuse for an accountable reviewer to skim the change.

05

The author has work to do before requesting review

A good review starts before the reviewer arrives. The author should make the change easy to understand. That means keeping it focused, explaining why it exists, showing how it was tested and calling out areas where the reviewer should pay particular attention.

Large pull requests make this harder. When a change mixes a business rule, a broad refactor, dependency updates and file formatting, the reviewer has to separate several kinds of work before they can judge any of them. Important details disappear inside noise.

Smaller changes are easier to understand, test, review and roll back. They do not need to be artificially tiny, but each should tell one coherent story. If a refactor is needed before the functional change, submitting it separately can make both reviews clearer.

• Explain the problem and the intended outcome, not only the files changed.
• Link the relevant requirement, issue or decision where one exists.
• State how the change was tested and include useful screenshots for visible behaviour.
• Call out migrations, configuration, security implications and known limits.
• Keep unrelated cleanup out of the same review.
• Review the complete diff before assigning another person.

The author should also read their own diff before asking for somebody else's time. This simple pass often catches debugging code, confusing names, missing files, accidental changes and a description that no longer matches the implementation.

06

Good review comments make the decision clearer

A review is about the code, not the developer. Comments should be specific, respectful and proportionate. “This is wrong” creates heat but gives the author little help. “This path lets the request owner approve their own invoice because the ownership check runs after approval” identifies the behaviour, the reason it matters and the place to investigate.

It also helps to label the weight of feedback. A blocking issue must be fixed before merge. A suggestion may improve the design but is not required. A small style preference should not quietly hold up a release. Google recommends making that severity clear so authors do not have to guess which comments are mandatory.

Questions are useful when the reviewer may be missing context. “Should this permission apply to regional managers as well?” invites clarification. If the answer exposes an undocumented rule, the code, test or documentation should usually be improved so the knowledge is not trapped in a review thread.

Reviewers should mention good work too. A clear test, a simpler design or a careful migration is worth recognising. Review should build shared standards and knowledge, not train developers to expect only a list of faults.

07

Slow review is a delivery problem

Code review adds time to an individual change, but a poor review queue can add far more. Work sits waiting, developers switch context, feedback arrives after the author has moved on and several changes begin depending on code that has not merged.

The answer is not instant approval. It is a predictable response. Teams need a shared expectation for when reviews are picked up, a way to find the right domain expert and permission to split a change that is too large to review properly.

Google's engineering guidance focuses on team speed rather than the speed of one developer. It recommends responding promptly while protecting focused work, and asking authors to split changes that are too large to assess. That balance is sensible: review should improve the software without becoming a silent queue that nobody owns.

Protected branches and required approvals can enforce the checkpoint. Ownership rules can route sensitive files to the right people. Those controls help, but they still need a team habit behind them. A required approval from somebody who does not understand or read the change is theatre, not quality assurance.

08

Code review is one layer of confidence

Code review cannot prove that software is correct. It does not replace automated tests, manual testing, product acceptance, specialist security work, monitoring or a safe release process. A reviewer may miss the same assumption as the author, especially when the requirement itself is unclear.

It is still one of the most useful points in software delivery. The change is visible, the reasoning is fresh and there is still time to improve it before it becomes shared history. Review can catch a logic error, reveal a hidden dependency, improve a test and spread knowledge of an area that otherwise belongs to one person.

A healthy code review process asks for evidence without turning every comment into a contest. Authors make changes small and understandable. Reviewers examine the business rule and the failure paths before debating style. Automated checks handle the repeatable work. The team responds quickly enough that quality does not become a queue.

If you are assessing an inherited application or trying to improve software delivery, look at the review process as well as the code. It often shows how decisions are made, how risk is shared and whether the team can change the system without depending on one person's memory.