Code Review
Code review is the practice of having other engineers examine proposed changes before they merge. It catches defects, spreads knowledge across a team, enforces conventions, and improves design quality through structured peer feedback on pull requests or changesets.
itSoftware engineering | OpenSkills.info
Intro
Code Review
Code review is a structured examination of a proposed code change by someone other than its author. The reviewer studies the change before it joins the shared codebase. The author responds by revising the code, explaining a decision, or discussing an alternative.
The review is not a search for a flawless change. Its purpose is to decide whether the change improves the codebase while meeting its intended goal. A useful review also spreads knowledge and records important reasoning.
Most teams perform code review through a pull request or a similar change-list tool. The tool shows a diff, which is the difference between the proposed code and its base version. It also keeps comments, revisions, checks, and the final review decision together.
Why review code
Automated checks can compile code, run tests, enforce formatting, and detect known patterns. They are fast and repeatable. They cannot fully judge whether a change solves the right problem, fits the surrounding design, or handles business rules correctly.
A human reviewer adds context. You can compare the implementation with the stated intent. You can inspect behavior that the tests omit. You can notice unnecessary complexity, unclear names, unsafe data flow, or a design that makes the next change harder.
Review also creates a second point of ownership. The author knows how the change was built. The reviewer learns why it exists and how it fits. That shared understanding matters when the code later fails or needs modification.
The unit of review
A code review begins with a proposed change. On GitHub, that proposal is a pull request. Other tools may call it a change list or merge request. The name differs, but the working unit is the same: intent, code, tests, discussion, and a decision.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://google.github.io/eng-practices/review/reviewer/
Supports
- The reviewer workflow, review standard, inspection order, response-time guidance, comments, and disagreement handling
- The course mental model, review sequence, decision threshold, and first two study-path rationales
- https://google.github.io/eng-practices/review/reviewer/standard.html
Supports
- Approval based on improving code health rather than achieving perfection
- Technical evidence and adopted style guides taking precedence over personal preference
- https://google.github.io/eng-practices/review/reviewer/looking-for.html
Supports
- Review lenses for design, functionality, complexity, tests, naming, comments, documentation, style, context, and every assigned line
- Stating scope when review responsibility is divided
- https://google.github.io/eng-practices/review/reviewer/navigate.html
Supports
- Reading the description first, examining the main design early, and then covering the remaining files
- Sending major design findings before spending time on details that may be replaced
- https://google.github.io/eng-practices/review/reviewer/comments.html
Supports
- Courteous comments about code, explanations of reasoning, balanced guidance, positive feedback, and explicit severity labels
- The course comment pattern and comment-writing examples
- https://google.github.io/eng-practices/review/reviewer/speed.html
Supports
- Prompt reviewer responses, focused work boundaries, early broad feedback, and splitting oversized changes
- The healthy-loop material in the introduction, slides, cheatsheet, and narration
- https://google.github.io/eng-practices/review/developer/
Supports
- Author guidance on useful descriptions, small changes, and handling comments
- The author-handoff checklist and author-guide link rationale
- https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
Supports
- Pull request review collaboration, line comments, suggestions, review requests, code owners, required reviews, and the three review states
- The GitHub overview link rationale
- https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request
Supports
- Understanding pull request purpose, reviewing files and diffs, tracking viewed files, and submitting a review
- The tool-workflow link rationale
- https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html
Supports
- Manual secure code review as a complement to automated tools
- Security review of business logic, data flow, authentication, authorization, cryptography, and context-specific vulnerabilities
- The OWASP Cheat Sheet link rationale and security-focused quiz answers
- https://owasp.org/www-project-code-review-guide/
Supports
- The guide's intended audience and its coverage of review practice and vulnerability identification
- The advanced OWASP study-path rationale