Code Review – a Brief Guide

Code review is a common practice in every software development company as it helps monitor the code quality and promotes self-education. Even though the process of conducting a code review seems obvious and clear, many developers still struggle to perform it on time and in a proper way. As a result, the benefits of a code review get completely eliminated by a poor approach and lack of knowledge.

In this article, we have collected the code review tips and practices that will help you structure this process and approach it in a wise manner that will result in a win-win for both an author and a reviewer, resulting in a quality bar raise across your company. For better readability, we split the article into two parts. Part one will give you an overview of code review, its types, and the overall process while part two will provide code review best practices and tips.

The types of code review

The review process may come in different formats, be it an over-the-shoulder review or a formal meeting with a detailed discussion of every line of the code. However, there are only two types of code review: lightweight and formal.

Lightweight code review

A lightweight code review is a process that does not take much time and corresponds to the agile methodology. The main goal of a lightweight review is to provide almost instant feedback in order to save time. There are four types of a lightweight code review:

• Over-the-shoulder: meaning, a reviewer simply sits near an author and comments on the code while it’s being written. It is also known as a synchronous review. 
• Pass-around by an email: the code for a review is distributed among reviewers via an email. This approach is not recommended as it is rather hard to track down the changes in numerous emails.
• Tool-assisted: an author and a reviewer use various tools for code review performance. The tools may automate some of the code review processes or notify an author about the comments left by a reviewer. This is the most popular approach these days.
• Pair programming: can be called an elevated form of over-the-shoulder review. Pair programming takes more time and effort from both an author and a reviewer and also calls for preparation (while over-the-shoulder review can be done at any time).

Formal code review

A formal code review is a pre-planned meeting that is attended by an author and reviewers. At the meeting, the code is reviewed line by line and the review is performed in an extremely thorough way.

Even though formal code review is effective due to high attention to detail, it takes too much time and does not fit the agile methodology. But if you work by the waterfall methodology, it is a really good option.

Why is code review so important?

In short, code review significantly raises the quality bar across the company – now let’s see how exactly it does that.

When an author prepares code for submission, it instantly boosts their motivation to “polish” the code in order for it to look good and function as intended. Because an author knows that their work will be evaluated by another person, they tend to consolidate TODOs, eliminate loose ends, and review the code independently before presenting it to a reviewer. In this way, authors become more attentive and are encouraged to take better care of their code instead of hoping that someone will fix the bugs for them.

Another critical benefit of code review is knowledge sharing. If code is reviewed by an experienced developer, they may share some useful or innovative insights so an author can learn. As for junior developers, they might perform code review as well – it gives them a chance to see the insights of their peers’ work and overall, learn how to review someone else’s code.

As well, when code is reviewed by other people, it’s easier to focus on bugs and errors from an outside perspective and find the issues that an author might otherwise miss. This also contributes to producing better code and significantly raising its quality.

Last but not least – code review contributes to better teamwork and communication. By learning how to provide and accept feedback and communicate with peers, employees become more professional, flexible in terms of negotiation, and learn how to resolve and prevent conflicts caused by differences in ideas and approaches.

The process of performing a code review

Judging from our experience, we see the following common practice: an author creates a pull request which is a request to merge his branch into the main branch. The request is created in a GitHub or Bitbucket. Once the request is created, an author tags a person whom he wants to see as a reviewer. The reviewer will automatically be notified of the created request and will be able to see all the changes that occur.

The code review process happens in rounds. A round is a full-cycle process that starts with an author sending the request to a reviewer and ends with an author receiving feedback from a reviewer. There are usually several rounds and the review process is considered complete when a reviewer approves the request and does not suggest any further edits.

When submitting a request for a review, the author must self-review and self-test it before sending it to a reviewer. It is highly recommended to break down large chunks of code into smaller parts so the code review process can go faster and easier. Also, it is important to write informative commit messages so reviewers can easily understand what a specific change is about.

As for the reviewers, they should check the code’s security, scalability, performance, and correspondence to the style guide. Reviewers also check whether code accomplishes the purpose that the author stated in the commit message.

While the general process of code review is clear and understandable, many developers often ask questions such as what exactly needs to be reviewed, how to choose a reviewer, and when should a team perform code review. Since the code review process is unique in every development company, we will provide the answers based on our own experience. 

What exactly needs reviewing?

There is no universal answer to this question. It might be a review of every change that is merged into a branch or it might be a review of a huge chunk of code that contains dozens of features. 

As for the things to look for in code, here are the most common ones that the reviewer focuses on:

• Correspondence of proposed changes to the task that is specified in a ticket
• Potential problem areas (bugs/crashes, performance issues, scalability issues, complexities)
• Correspondence to the team coding style and/or style guide
• Clearness of the code, proper naming, architecture design (if it’s a feature), correspondence to SOLID principles
• Test coverage (if deployed on the project). 

An important thing to remember: code review is an obligatory practice for every developer, whether they are junior or senior. So do not ignore it even if you believe your code is nearly perfect.

When do I do code review?

Usually, teams do it after completing automated checks and before merging the code to the main branch. 

Once a pull request is created, CI automatically runs code style checks and unit tests to test it. The tool (GitHub or Bitbucket) will allow to close the pull request only if all reviewers approved changes and all tests from the CI side have been successfully completed.

Who should perform a review?

This is decided by a team lead. The assignment of a reviewer will depend on the team and the established rules. The options may be a fixed list of potential reviewers, a review performed by everyone, one reviewer only or a specific number of reviewers. Code review is normally performed by developers only – no QA specialists or PMs involved.

In this article, we have looked at the code review process, the roles involved, and its main benefits. In part two, we will discuss code review best practices that will help you significantly save time and effort as well as optimize the review process and increase the quality level across your company.

Code review is a common practice in every software development company as it helps monitor the code quality and promotes self-education. Even though the process of conducting a code review seems obvious and clear, many developers still struggle to perform it on time and in a proper way. As a result, the benefits of a code review get completely eliminated by a poor approach and lack of knowledge.

In this article, we have collected the code review tips and practices that will help you structure this process and approach it in a wise manner that will result in a win-win for both an author and a reviewer, resulting in a quality bar raise across your company. For better readability, we split the article into two parts. Part one will give you an overview of code review, its types, and the overall process while part two will provide code review best practices and tips.

The types of code review

The review process may come in different formats, be it an over-the-shoulder review or a formal meeting with a detailed discussion of every line of the code. However, there are only two types of code review: lightweight and formal.

Lightweight code review

A lightweight code review is a process that does not take much time and corresponds to the agile methodology. The main goal of a lightweight review is to provide almost instant feedback in order to save time. There are four types of a lightweight code review:

• Over-the-shoulder: meaning, a reviewer simply sits near an author and comments on the code while it’s being written. It is also known as a synchronous review. 
• Pass-around by an email: the code for a review is distributed among reviewers via an email. This approach is not recommended as it is rather hard to track down the changes in numerous emails.
• Tool-assisted: an author and a reviewer use various tools for code review performance. The tools may automate some of the code review processes or notify an author about the comments left by a reviewer. This is the most popular approach these days.
• Pair programming: can be called an elevated form of over-the-shoulder review. Pair programming takes more time and effort from both an author and a reviewer and also calls for preparation (while over-the-shoulder review can be done at any time).

Formal code review

A formal code review is a pre-planned meeting that is attended by an author and reviewers. At the meeting, the code is reviewed line by line and the review is performed in an extremely thorough way.

Even though formal code review is effective due to high attention to detail, it takes too much time and does not fit the agile methodology. But if you work by the waterfall methodology, it is a really good option.

Why is code review so important?

In short, code review significantly raises the quality bar across the company – now let’s see how exactly it does that.

When an author prepares code for submission, it instantly boosts their motivation to “polish” the code in order for it to look good and function as intended. Because an author knows that their work will be evaluated by another person, they tend to consolidate TODOs, eliminate loose ends, and review the code independently before presenting it to a reviewer. In this way, authors become more attentive and are encouraged to take better care of their code instead of hoping that someone will fix the bugs for them.

Another critical benefit of code review is knowledge sharing. If code is reviewed by an experienced developer, they may share some useful or innovative insights so an author can learn. As for junior developers, they might perform code review as well – it gives them a chance to see the insights of their peers’ work and overall, learn how to review someone else’s code.

As well, when code is reviewed by other people, it’s easier to focus on bugs and errors from an outside perspective and find the issues that an author might otherwise miss. This also contributes to producing better code and significantly raising its quality.

Last but not least – code review contributes to better teamwork and communication. By learning how to provide and accept feedback and communicate with peers, employees become more professional, flexible in terms of negotiation, and learn how to resolve and prevent conflicts caused by differences in ideas and approaches.

The process of performing a code review

Judging from our experience, we see the following common practice: an author creates a pull request which is a request to merge his branch into the main branch. The request is created in a GitHub or Bitbucket. Once the request is created, an author tags a person whom he wants to see as a reviewer. The reviewer will automatically be notified of the created request and will be able to see all the changes that occur.

The code review process happens in rounds. A round is a full-cycle process that starts with an author sending the request to a reviewer and ends with an author receiving feedback from a reviewer. There are usually several rounds and the review process is considered complete when a reviewer approves the request and does not suggest any further edits.

When submitting a request for a review, the author must self-review and self-test it before sending it to a reviewer. It is highly recommended to break down large chunks of code into smaller parts so the code review process can go faster and easier. Also, it is important to write informative commit messages so reviewers can easily understand what a specific change is about.

As for the reviewers, they should check the code’s security, scalability, performance, and correspondence to the style guide. Reviewers also check whether code accomplishes the purpose that the author stated in the commit message.

While the general process of code review is clear and understandable, many developers often ask questions such as what exactly needs to be reviewed, how to choose a reviewer, and when should a team perform code review. Since the code review process is unique in every development company, we will provide the answers based on our own experience. 

What exactly needs reviewing?

There is no universal answer to this question. It might be a review of every change that is merged into a branch or it might be a review of a huge chunk of code that contains dozens of features. 

As for the things to look for in code, here are the most common ones that the reviewer focuses on:

• Correspondence of proposed changes to the task that is specified in a ticket
• Potential problem areas (bugs/crashes, performance issues, scalability issues, complexities)
• Correspondence to the team coding style and/or style guide
• Clearness of the code, proper naming, architecture design (if it’s a feature), correspondence to SOLID principles
• Test coverage (if deployed on the project). 

An important thing to remember: code review is an obligatory practice for every developer, whether they are junior or senior. So do not ignore it even if you believe your code is nearly perfect.

When do I do code review?

Usually, teams do it after completing automated checks and before merging the code to the main branch. 

Once a pull request is created, CI automatically runs code style checks and unit tests to test it. The tool (GitHub or Bitbucket) will allow to close the pull request only if all reviewers approved changes and all tests from the CI side have been successfully completed.

Who should perform a review?

This is decided by a team lead. The assignment of a reviewer will depend on the team and the established rules. The options may be a fixed list of potential reviewers, a review performed by everyone, one reviewer only or a specific number of reviewers. Code review is normally performed by developers only – no QA specialists or PMs involved.

In this article, we have looked at the code review process, the roles involved, and its main benefits. In part two, we will discuss code review best practices that will help you significantly save time and effort as well as optimize the review process and increase the quality level across your company.