Review
A review is a process in software engineering where a work product, such as code, design, or documentation, is examined by individuals other than the author. The goal is to identify defects, improve quality, ensure adherence to standards, and facilitate knowledge sharing among team members.
1970s
3
Definitions
General Software Engineering Context
In the general context of software engineering, a review is a systematic examination of a work product by one or more individuals. The primary goal is to identify and resolve defects, improve quality, and ensure the product meets its requirements and adheres to established standards.
Work products that undergo reviews can include requirement documents, design specifications, source code, test plans, and user manuals. This process is a cornerstone of quality assurance, aiming to catch errors early in the development lifecycle when they are cheapest and easiest to fix. It also serves as a powerful tool for knowledge sharing and team alignment.
Code Review
A Code Review, often used interchangeably with Peer Review, is a specific type of review focused on the examination of source code. Developers submit their code for evaluation by their peers before it is merged into a central repository. This is a common practice in modern software development, often facilitated by tools like GitHub, GitLab, and Bitbucket through Pull Requests or Merge Requests.
The objectives of a code review are multi-faceted:
- Defect Detection: To find bugs, logic errors, and potential security vulnerabilities.
- Quality Improvement: To enhance code readability, maintainability, and performance.
- Knowledge Sharing: To distribute understanding of the codebase among team members and mentor junior developers.
- Adherence to Standards: To ensure the code follows team-wide coding conventions, style guides, and best practices.
Design Review
A Design Review is a critical evaluation of a system's proposed architecture or detailed design. This review occurs before significant implementation work begins. Participants, typically including architects, senior developers, and product stakeholders, assess the design against functional and non-functional requirements like scalability, security, and performance.
The purpose is to validate the design's feasibility and soundness, identify potential flaws in the architecture, and ensure it aligns with the overall technical strategy. A successful design review can prevent costly rework and architectural dead-ends later in the project.
Origin & History
Etymology
The term 'review' originates from the Middle French 'reveue', meaning 'a viewing, a review'. This comes from the verb 'revoir', which translates to 'to see again' or 'to go over'. The etymology directly reflects the core activity of a review: looking over a piece of work a second time with a critical eye.
Historical Context
The concept of having a second person check one's work is ancient. However, in the context of software engineering, formal review processes gained prominence in the 1970s. Michael Fagan, an IBM engineer, published his seminal paper on software inspections in 1976. He introduced a structured, data-driven process for finding defects in code and other documents, which became known as Fagan inspections. These formal inspections were a hallmark of traditional Waterfall methodologies, emphasizing rigorous, phase-gated quality checks. With the rise of Agile methodologies in the early 2000s, the nature of reviews shifted. They became more lightweight, frequent, and collaborative. The advent of distributed version control systems (like Git) and platforms like GitHub (launched in 2008) revolutionized the practice, particularly for code reviews. The 'Pull Request' (or 'Merge Request') model integrated the review process directly into the development workflow, making it an asynchronous, continuous, and transparent activity for teams of all sizes.
Usage Examples
The team has a mandatory code review process for every pull request to maintain code quality.
Before we start coding the new microservice, we need to schedule a design review with the senior architects.
My peer review feedback suggested I should add more comments to the complex algorithm.
The security team will conduct a final audit of the authentication module before the release.
During the requirements walkthrough, the product manager clarified several ambiguous user stories.
Frequently Asked Questions
What is the primary purpose of a code review?
The primary purpose of a code review is not just to find bugs. It serves multiple key functions:
- Improving Code Quality: Enhancing readability, maintainability, and adherence to best practices.
- Knowledge Sharing: Spreading understanding of the codebase across the team and mentoring junior developers.
- Enforcing Standards: Ensuring consistency with team-wide coding conventions and style guides.
- Finding Defects: Catching logic errors, potential bugs, and security vulnerabilities before they reach production.
How does a design review differ from a code review?
A design review and a code review differ in their timing and focus. A design review happens before implementation begins and focuses on the high-level architecture, system components, and data flows to ensure the proposed solution is sound and meets requirements. A code review happens after the code is written and focuses on the low-level implementation details, such as logic, style, and correctness.
Name two different styles of software reviews.
Two common styles of software reviews are:
- Asynchronous Review (e.g., Pull Request): This is the most common style today. A developer submits their work (e.g., code) for review, and reviewers provide feedback at their own convenience. It is flexible and well-documented.
- Walkthrough: A less formal process where the author of the work product leads the review session, explaining the product to the participants, who then ask questions and make comments. It is more interactive than an asynchronous review.