# Code review

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/code-review

## Quick definition

A code review is when another person looks at your code before it becomes part of the main project. It helps catch bugs, improve the design, and make sure the code follows team rules. Think of it like having a friend proofread your essay before you hand it in. It makes the final product better and helps everyone learn from each other.

## Simple meaning

Code review is a process where developers check each other's work before the code is added to the main project. Imagine you are building a model airplane from a kit. You might think you have followed all the instructions correctly, but if a friend looks at your work, they might notice a wing is attached upside down or a glue joint is weak. That is what code review does for software. One developer writes some new code to add a feature or fix a problem. Then, instead of immediately adding that code to the main collection of code (called the main branch), they ask one or more teammates to read through it. These reviewers look for mistakes, such as logic errors, security holes, or performance problems. They also check if the code is easy to understand and maintain in the future. The reviewer can leave comments, ask questions, or suggest changes. The original developer then fixes any issues and asks for another review. Once everyone is satisfied, the code is approved and merged. This process does more than just catch bugs. It spreads knowledge across the team, so no single person is the only one who understands a part of the system. It also ensures a consistent style, which makes the whole codebase easier to work with. Code review is a key practice in DevOps because it fits into the continuous integration and continuous delivery (CI/CD) pipeline, helping teams deliver high-quality software faster.

## Technical definition

Code review is a structured quality assurance activity in software development where source code is examined by one or more peers before integration into the main code repository. It is a cornerstone of modern DevOps practices, particularly in continuous integration (CI) and continuous delivery (CD) workflows. The process typically begins when a developer creates a new branch from the mainline, commits code changes, and opens a pull request (PR) or merge request. This triggers an automated CI pipeline, which runs unit tests, static analysis, and security scans. Once the automated checks pass, human reviewers are notified. The review itself involves inspecting each line of code for correctness, adherence to coding standards, proper error handling, efficient algorithms, and appropriate use of APIs and design patterns. Reviewers also verify that the code includes adequate unit and integration tests and that documentation is updated. Common standards checked include language-specific style guides (e.g., PEP 8 for Python), naming conventions, and architectural patterns. The review tools (like GitHub, GitLab, or Azure Repos) provide a diff view, inline commenting, and approval workflows. Microsoft's Azure DevOps, for example, uses pull requests with branch policies that require a minimum number of reviewers, comment resolution, and successful builds before merging. This ensures that every change is vetted both automatically and manually. From a technical standpoint, code review is often a mandatory step in branch protection rules. It prevents direct pushes to protected branches like main or master. In Azure DevOps (relevant for AZ-400 exam), branch policies are configured in the repository settings. They can require a specific number of reviewers, check for linked work items, and enforce a successful build from a CI pipeline. Code reviews can be synchronous (pair programming) or asynchronous (pull requests), with the latter being more common in distributed teams. In Azure Repos, the pull request flow includes a discussion tab for general comments, an overview tab showing commits and policies, and a files tab for line-by-line review. The reviewer can approve, approve with suggestions, or reject. The developer resolves comments by making new commits directly to the PR branch, which updates the diff in real time. Once all policies are satisfied, the PR can be completed, often using a squash merge or rebase to keep the history clean. Code review also ties into telemetry and deployment rings, reviewed code that passes all gates can be automatically deployed to a staging environment for further validation. Code review is not just a manual process; it is a deeply integrated component of the modern DevOps toolchain, combining automated checks with human judgment to maintain code quality, security, and team collaboration.

## Real-life example

Think of a team of chefs preparing a large banquet for a wedding. One chef, Maria, is responsible for the main course, a roasted chicken with a special herb sauce. She prepares the chicken, seasons it, and puts it in the oven. Before the dish is served to the guests, the head chef comes over to inspect it. The head chef checks the temperature to make sure it is fully cooked, looks at the color to ensure it is not burned, and tastes a small piece of the sauce to see if the seasoning is balanced. If the sauce is too salty, the head chef tells Maria to add a little cream to mellow it. If the chicken is undercooked, Maria puts it back in the oven. This inspection is the code review. The head chef is the reviewer. Maria is the developer. The chicken is the code change. The wedding banquet is the final software product served to customers. Without this inspection, a salty dish could ruin the entire meal. Similarly, without code review, a buggy piece of code could crash the application. The head chef also learns Maria's technique for the herb sauce and might suggest using fresh rosemary instead of dried for a better flavor. This knowledge sharing is a huge benefit of code review. In the same way, when a developer reviews a colleague's code, they might learn a new way to handle an error or a more efficient algorithm. The review process ensures that only high-quality, consistent dishes leave the kitchen. In software, it ensures that every change meets the team's standards and integrates well with the rest of the application. The banquet is a success because each dish was checked before being served.

## Why it matters

Code review matters because it directly impacts software quality, team productivity, and system reliability. In a professional IT environment, no developer writes perfect code every time. Even experienced engineers miss edge cases, introduce security vulnerabilities, or make assumptions that do not hold in all environments. Code review catches these issues early, before they reach production, where fixing them would be far more expensive and time-consuming. It also enforces coding standards, which makes the codebase more consistent and easier to maintain. When everyone follows the same patterns, a new team member can understand the code faster, and automated tools like linters and formatters work more effectively. Code review also spreads knowledge across the team. When a senior developer reviews a junior's code, they provide mentoring. When a junior reviews a senior's code, they learn new techniques. This reduces bus factor, the risk that only one person understands a critical part of the system. In a DevOps context, code review is a key quality gate in the CI/CD pipeline. Azure DevOps branch policies can block a pull request until it gets the required number of approvals, passes all automated checks, and has no active comments. This ensures that every change is peer-reviewed before it reaches the main branch, which is then deployed. Without code review, a team might introduce a breaking change that halts production for everyone. Code review also helps with compliance and audit trails. For regulated industries, having a record of who reviewed and approved each change is essential. The pull request history in Azure Repos provides that trail, including timestamps, comments, and decisions. Finally, code review encourages a culture of collaboration and shared ownership. When everyone is responsible for reviewing code, no one feels like they own a piece of code exclusively. This reduces blame and encourages collective improvement. For the AZ-400 exam, understanding code review is critical because it is part of the 'Develop an Instrumentation Strategy' and 'Develop a Site Reliability Engineering (SRE) Strategy' domains, specifically around managing code quality and using branch policies.

## Why it matters in exams

The AZ-400 Microsoft Azure DevOps Solutions exam covers code review extensively, especially under the 'Configure Repositories' and 'Design and Implement Branch Strategies' objectives. The exam expects you to know how to set up branch protection policies in Azure Repos that require code reviews before merging. You may encounter scenario-based questions where a team is experiencing production issues because code is being merged without review. You need to recommend configuring branch policies that enforce a minimum number of reviewers and require successful CI builds. Another common question type involves handling pull request workflows. For example, you might be asked what happens when a reviewer rejects a pull request, the correct answer is that the developer must address the comments and request a new review. You also need to understand the difference between synchronous (pair programming) and asynchronous (pull request) code review. The exam tests your knowledge of integrating code reviews with other Azure DevOps features, such as linking work items to pull requests, enforcing comment resolution, and using branch naming conventions. Questions might present a scenario where a team wants to ensure that every code change is reviewed by at least two people from different teams. The solution involves configuring a branch policy that requires a specific number of reviewers and uses a checklist for security and compliance. You should also know that code review is part of the larger quality feedback loop in DevOps. It is not just about finding bugs, it is about improving the overall development process. The exam may ask how code review reduces mean time to recovery (MTTR) by catching issues before deployment. For the AZ-400, code review is central to the 'Source Control' and 'Continuous Integration' sections. Objective 1.2 involves configuring branch policies, and code review is the primary human gate in those policies. Objective 2.1 on implementing CI includes code review as a prerequisite for build triggers. You will also see code review in the context of security, where reviewers must verify that secrets are not hard-coded and that dependency updates are safe. The exam traps often involve confusion between automatic code review tools (like CodeQL or SonarCloud) and human code review. The exam wants you to understand that both are needed, static analysis tools catch pattern-based issues, but human reviewers catch logical flaws and design problems. Code review is a high-frequency topic in AZ-400, and you must be comfortable with configuring branch policies, understanding the pull request life cycle, and knowing how code review fits into the overall quality strategy.

## How it appears in exam questions

Code review appears in AZ-400 exam questions primarily in scenario-based and configuration formats. A typical scenario question might describe a team that uses Azure Repos and wants to ensure that every change to the main branch is reviewed by at least two senior developers and must pass a continuous integration build. The correct answer would be to create a branch policy on the main branch that requires a minimum number of reviewers (two) and requires a successful build. Another common scenario is when a team's pull requests are being merged without any discussion because reviewers are not notified. The solution is to configure the branch policy to check for comment resolution or to require that all comments are resolved before merging. There are also troubleshooting-type questions. For example, a developer pushes a new branch and creates a pull request, but the merge button is disabled. The question asks why, and the answer might be that the branch policy requires a build to succeed first, or that there is a merge conflict that needs resolution. Configuration questions might ask you to set up a branch policy that blocks direct pushes to the release branch and requires a code review from a team lead. You would need to know that branch policies are found in the repository settings in Azure Repos, under 'Branch Policies'. A more complex question might integrate code review with CI/CD pipelines. For instance, a team wants to run a security scan on all code changes before they are reviewed. The correct approach is to configure a CI trigger on the branch that runs a security scan, and then set the branch policy to require that build to succeed before merging. There are also questions about the pull request experience itself. You might be asked what happens when a reviewer leaves a comment that says 'Needs fix for memory leak'. The developer should fix the code, push a new commit to the same branch, and the reviewer will see the updated code. The question might ask how to ensure the developer does not forget to respond to a comment, the answer is to enable comment resolution policy. Another trap question might say 'A developer claims that code review is slowing the team down. What should you suggest?' The correct answer is not to remove code review, but to adopt a risk-based approach where low-risk changes (like fixing a typo in a comment) can be merged with a single reviewer, while high-risk changes require more scrutiny. In all these questions, the key is understanding that code review is a policy-enforced quality gate, and Azure DevOps provides the tools to automate and enforce that gate. You also need to know the difference between the types of reviewers, required vs. optional, and that branch policies can be configured per branch or per folder path.

## Example scenario

You are a developer on a team building an e-commerce website using Azure DevOps. Your manager says that too many bugs are reaching production because code is being merged too quickly. She asks you to create a branch policy that requires code review for every change to the main branch. You go to the Azure Repos repository settings for your project called 'ECommerce'. You select the main branch and click 'Add branch policy'. 
You enable 'Require a minimum number of reviewers' and set it to 2. This means every pull request to main must get approval from at least two people before it can be merged. You also enable 'Allow reviewers to approve their own changes' but you leave that unchecked, because you do not want someone to count their own approval. 
Next, you set 'Require comment resolution'. This ensures that if a reviewer leaves a comment asking for a change, the developer cannot merge until the comment is resolved. You also select 'Check for linked work items' and set the requirement to 'Required', so every pull request must be linked to a work item in Azure Boards. This ties the change to a business requirement, making it traceable. 
Finally, you configure the 'Build validation' policy. You add a new build pipeline that runs the automated tests and code analysis. You set it to 'Required' with a trigger that re-evaluates whenever a new commit is pushed to the pull request branch. Now, when a developer wants to merge a new feature, they create a branch, write code, commit, push, and create a pull request. The CI build runs automatically. The build fails because a unit test is broken. The developer fixes the test and pushes again. The build passes. Two reviewers look at the code, leave comments about variable naming and a potential null reference exception. The developer fixes those, resolves the comments, and the two reviewers approve. Now the merge button is enabled, and the code is merged to main. 
Over the next sprint, the team notices that the number of production incidents drops by 40 percent because bugs are caught during review. The team also learns from each other's code, and the codebase becomes more consistent. This scenario shows how a simple branch policy with code review can dramatically improve software quality.

## Common mistakes

- **Mistake:** Thinking code review is only about finding bugs.
  - Why it is wrong: Code review also checks for code style, maintainability, adherence to design patterns, security, and proper test coverage. If you only look for bugs, you miss many quality improvements.
  - Fix: Use a review checklist that includes style, naming, documentation, error handling, and test coverage, not just functional correctness.
- **Mistake:** Using code review as a substitute for automated testing.
  - Why it is wrong: Human reviewers cannot reliably catch regressions or performance issues that automated tests can. Relying solely on manual review leads to missed defects.
  - Fix: Always run a CI pipeline with unit tests and static analysis before or during the code review. Treat the automated build as a mandatory gate.
- **Mistake:** Requiring the same number of reviewers for every change regardless of risk.
  - Why it is wrong: Low-risk changes like documentation fixes or comment typos do not need the same scrutiny as a new payment module. Over-reviewing wastes time and slows down the team.
  - Fix: Use branch policies with different rules for different branches. For example, require fewer reviewers for feature branches and more for release branches. Or use file path rules to require specific reviewers for sensitive folders.
- **Mistake:** Ignoring that the reviewer is also responsible for understanding the change.
  - Why it is wrong: A reviewer who approves without understanding the code is ineffective. This leads to a false sense of security and wasted effort.
  - Fix: Train reviewers to ask questions until they understand the change. Use the 'approve with suggestions' option if unsure, and never approve code you do not fully understand.
- **Mistake:** Merging a pull request that has unresolved comments.
  - Why it is wrong: Unresolved comments mean important feedback was not addressed, leaving potential issues in the codebase. It undermines the entire review process.
  - Fix: Enable the 'Require comment resolution' branch policy. Ensure the developer resolves every comment by either fixing the code or explaining why no change is needed. Only then can the PR be merged.

## Exam trap

{"trap":"The exam presents a scenario where a developer merges a pull request directly into the main branch without any review, and it causes a production outage. The question asks what to implement to prevent this. A common wrong answer is 'implement a CI pipeline'.","why_learners_choose_it":"Learners often think that CI (continuous integration) alone is enough to ensure code quality. They forget that CI checks only automated tests, not human judgment on design, security, or maintainability.","how_to_avoid_it":"Remember that CI is necessary but not sufficient. To prevent unauthorized merges, you must also implement branch protection policies that require code review. The correct answer is 'configure branch policies to require a minimum number of reviewers and successful CI build before merging'. Always pair CI with peer review as a quality gate."}

## Commonly confused with

- **Code review vs Static code analysis:** Static code analysis is an automated tool that scans source code for pattern-based bugs, security vulnerabilities, and style violations without executing it. Code review is a human activity where a peer reads and evaluates the code for logical correctness, design, and overall quality. Static analysis is typically run as part of the CI pipeline before the human review, complementing but not replacing it. (Example: A tool like SonarCloud automatically flags a SQL injection vulnerability in your code (static analysis). A human reviewer then looks at the flagged code to see if the suggested fix makes sense for the context and whether the change introduces any other issues (code review).)
- **Code review vs Pair programming:** Pair programming involves two developers working on the same code at the same time on one machine, with one typing (driver) and the other reviewing in real time (navigator). Code review is typically asynchronous, the developer writes code alone and later submits it for review by someone else. Pair programming is more intensive but provides instant feedback, while async code review allows more flexibility and deeper reflection. (Example: In pair programming, two developers sit together for two hours to write a login module, catching issues immediately. In an async code review, one developer writes the login module in the morning and submits a pull request; a colleague reviews it in the afternoon and leaves comments.)
- **Code review vs Code walkthrough:** A code walkthrough is an informal, often meeting-based activity where a developer presents code to a group to explain its logic and gather feedback. It is less structured than a formal code review and rarely uses a tool with inline comments or approval workflows. Code review is more rigorous, using branch policies, pull requests, and explicit approval gates in a version control system. (Example: A developer sets up a 30-minute meeting to show a new algorithm to the team, explaining the flow (walkthrough). In contrast, a code review is done through Azure Repos where the reviewer reads the diff, comments on specific lines, and the developer responds without a meeting.)

## Step-by-step breakdown

1. **Create a branch and develop code** — The developer creates a new branch from the mainline (e.g., main or develop). They write code, commit changes locally, and push the branch to the remote repository. This isolates the new work from the stable codebase.
2. **Open a pull request (PR)** — The developer navigates to the repository in Azure Repos and creates a pull request. They select the source branch (their feature branch) and the target branch (main). They add a title, description, and optionally link work items. The PR triggers the configured branch policies.
3. **Automated checks run** — The CI pipeline defined in the branch policy triggers. This compiles the code, runs unit tests, performs static analysis, and runs security scans. The build status is displayed on the PR page. If the build fails, the PR is blocked until fixed.
4. **Human review begins** — Reviewers are notified via email or dashboard. They open the PR and see a diff of all changes. They leave inline comments on specific lines, ask questions, or suggest improvements. They can also leave general comments on the PR discussion tab.
5. **Developer addresses feedback** — The original developer reads the comments, makes necessary changes in their local branch, commits, and pushes to the same PR branch. The PR updates automatically. Developers resolve comments (marked as resolved) once they are addressed. This cycle may repeat several times.
6. **Approval and merge** — Once all reviewers approve and all policies pass, the merge button becomes active. The developer or a team lead completes the merge, often choosing a squash merge or rebase to keep history clean. The code is now in the main branch and ready for deployment.

## Practical mini-lesson

Code review is not just a ritual, it is a practical quality assurance technique that every professional developer must master. In practice, a good code review starts with understanding the context. Before you even look at the diff, read the pull request description and linked work item. This tells you what the change is supposed to achieve. Then, focus on the most impactful parts first: the logic, error handling, and security. Do not spend too much time on style issues that automated tools can catch. Leave clear, constructive comments. Instead of 'This is wrong', say 'This condition might cause a null reference exception if the input is empty. Consider using a guard clause.' 
From a configuration perspective, in Azure DevOps, you set up branch policies under Project Settings > Repositories > Repository name > Policies. You can set rules for specific branches. For example, you can define a policy that requires two reviewers for the main branch, but only one for feature branches. You can also set optional or required reviewers for specific file paths, like requiring a security expert to review changes to files in the /security folder. The built-in branch policy types are: Minimum number of reviewers, Comment resolution, Build validation, and Work item linking. 
What can go wrong? If you set too many reviewers, the PR sits idle waiting for approvals, slowing delivery. If you set no policies, bad code gets merged. A balanced approach is to use optional reviewers for low-risk changes and required reviewers for high-risk changes. Also, avoid the trap of the 'rubber stamp' reviewer, someone who approves without reading. To prevent this, set a policy that requires reviewers to contribute at least one comment, or use a policy that requires a specific 're-approval' after a new commit. 
Another common issue is merge conflicts. When multiple PRs modify the same file, conflicts arise. The developer must resolve them locally and push. The reviewer then sees the resolved version. To minimize conflicts, encourage short-lived branches and frequent integration. 
Professionals also use code review to enforce non-functional requirements. For example, a reviewer can check that all new features include telemetry and logging. This is often missed in automated checks. Finally, use the 'squash merge' option to keep the main branch history clean. Without it, you might end up with dozens of 'fix typo' commits. Squash merge combines all commits from the PR into one clean commit. 
practical code review requires a mix of human skill and tool configuration. Master both to deliver high-quality software efficiently.

## Memory tip

Think of PR as 'Proof Read', just like a teacher proofreads your essay, a peer proofreads your code before it is 'published' to main.

## FAQ

**What is the difference between a pull request and a code review?**

A pull request is a request to merge code from one branch to another. Code review is the human activity of examining that code. The pull request is the mechanism that enables the code review to happen in a structured way.

**How many reviewers should I require for a code review?**

It depends on the risk. For most changes, one or two reviewers is enough. For high-risk changes (e.g., payment logic, security-sensitive code), two or more may be appropriate. Azure DevOps allows you to set different policies for different branches.

**What happens if a code review takes too long?**

Slow reviews can become a bottleneck. Set time limits or escalation policies. Use small, frequent pull requests to make reviews quicker. Reviewers should prioritize pull requests over other work during code review sessions.

**Can code review replace automated testing?**

No. Automated testing catches regressions and ensures correctness faster than humans. Code review catches design flaws, logic errors, and knowledge gaps. Both are needed for a comprehensive quality strategy.

**What is a 'rubber stamp' review and why is it bad?**

A rubber stamp review is when a reviewer approves code without actually reading it. This gives a false sense of security and bypasses the quality benefits of code review. To prevent this, use policies that require meaningful reviewer interaction.

**How do I handle a situation where a developer disagrees with a review comment?**

The developer should explain their reasoning in the comment thread. If no agreement is reached, escalate to a team lead or use a third reviewer. The goal is to find the best solution for the codebase, not to 'win' the argument.

**Is code review required for DevOps?**

While not strictly required, code review is a best practice in DevOps because it improves code quality, spreads knowledge, and enforces consistency. Most mature DevOps teams use branch policies that require code review before merging into main.

## Summary

Code review is a fundamental practice in modern software development and a critical skill for the AZ-400 exam. It involves a systematic examination of source code by peers before it is merged into the main branch, serving as a human quality gate that complements automated CI/CD pipelines. The process catches not only bugs but also design issues, security vulnerabilities, and style inconsistencies. It is implemented in Azure Repos through pull requests and branch policies that require a minimum number of reviewers, comment resolution, and successful builds. The AZ-400 exam tests your ability to configure these policies, understand the pull request workflow, and integrate code review into the broader DevOps strategy. Common mistakes include relying solely on automated checks, requiring too many reviewers for trivial changes, and merging with unresolved comments. By mastering code review, you improve team collaboration, code quality, and deployment reliability. Use the memory tip of 'Proof Read' to remember that code review is like proofreading an essay, it catches issues before they become public. On the exam, always consider both automated and human checks when designing a quality gating strategy. Code review is not just a formality, it is the backbone of a robust software delivery pipeline.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/code-review