Skip to main content
Version: 10.2.8

Peer code review

Code review benefits​

Code reviewing is a Learning Opportunity for everyone who works on a project.

Code review, also referred to as peer review, is a systematic examination of software source code. It's conducted to find bugs and improve overall quality of the software.

There are at least two roles that are always present in a code review:

  • Author is the person responsible for creating the code being reviewed
  • Reviewer is the person responsible for examining the code and reporting the findings to the author

Why code reviews matter?​

So, why bother reviewing code? It's better to say it in other words. What benefits can we get from code review?

The benefits or the goals of code review are the following:

  • Finding bugs early, when they are cheap to fix.
  • Coding standards compliance. Code review helps to maintain a consistent coding style across the company.
  • Teaching and sharing knowledge. During review, team members gain a better understanding of the codebase and learn from each other.
  • Consistent design and implementation. Peer review helps to maintain a level of consistency in software design and implementation.
  • Higher software security. Applications that require a high level of security benefit from targeted security reviews.
  • Team cohesion. Review discussions save team members from isolation and bring them closer to each other.
  • Confidence of stakeholders. You build the confidence of stakeholders about the technical quality of the execution.

But code reviews take time!​

Sure, they take time. But that time isn't wasted–far from it.

Here are three ways to optimize for that.

Share the load​

Many teams require two reviews of any code before it's checked into the codebase. Sounds like a lot of overhead? Really, it's not. When an author selects reviewers, they cast a wide net across the team. Any two engineers can give input. This decentralizes the process so that no one is a bottleneck, and ensures good coverage for code review across the team.

Review before merging​

Requiring code review before merging upstream ensures that no code gets in unreviewed. Which means that the questionable architectural decisions made at 2 am and the improper use of a factory pattern by the intern are caught before they have a chance to make a lasting (and regrettable) impact on your application.

Use peer pressure to your advantage​

When developers know their code will be reviewed by a teammate, they make an extra effort to ensure that all tests are passing and the code is as well-designed as they can make it so the review will go smoothly. That mindfulness also tends to make the coding process itself go smoother and, ultimately, faster.

Don’t wait for a code review if the feedback is needed earlier in the development cycle. Early and frequent feedback makes for better code, so don't be shy about involving others – whenever that may be. It'll make your work better, but it also makes your teammates better code reviewers.

Process​

Demonstrate three users interaction over code ownership.

Demo case: Set up and demo two peers code review using GitHub​