How Should Code Reviews Be Conducted?

‍

Code reviews are essential before releasing code. They have become a common collaboration practice and help teams distribute knowledge, maintain consistency and avoid bugs. During this process an open dialogue is generated between the software developer and the reviewer. Together they improve the code quality and learn from the process by asking themselves questions such as: 

• Is the new code written in the same style as previous codes?
• Have all the requirements for the code been met?
• Can other team members learn something from this?
• Are there more efficient ways of completing the task?
• What are the most common vulnerabilities, and are these patched for?
• Are there any obvious bugs?

In this article we talk about why effective code reviews are important to sharing knowledge within an engineering team, and improving its performance. We recommend practices that improve the code review quality, its speed and effectiveness. And then show you how Athenian can help you improve your code review strategy to become a high-performance team.

Why are code reviews important in the first place?

We all make mistakes when writing code. So, it seems logical that reviewing our work will reduce our errors. But, a code review has many other benefits that might not be evident at first. For example:

• Team: Bring together people to provide the opportunity to share knowledge and experience. 
• Streamline: Accelerate the process of software development.
• Validate: Confirm the design and implementation of features. 
• Consistency: Help maintain a style between different team members and various projects. 
• Quality: Increase the quality of software and help software developers improve their skills.
• Velocity: Improve the team’s velocity, and decrease the team’s change failure rate. 

How do you get access to the benefits that reviewing code promises? There are certain practices that will help you maximize the advantages of reviewing code. 

What are the best practices to review code?

Request code reviews on small chunks as early as possible:

Code reviews should be requested on small pieces of code as early as possible. Waiting to complete the work on a full feature will normally make the code reviews draining for the reviewer. He will face many lines of code and this will increase the potential for errors. 

Use automated tests

Let automated tests do the initial work before issuing a request. By doing so, you ensure that the code reviewer’s time is spent checking for issues that the machine might miss. This will reduce your opportunity cost since your team is allocating their time effectively.

Only related changes in the same PR

By including something unrelated to the current task, you might be blocking off something that requires immediate action. Therefore, unrelated features should be moved to another branch, with an additional pull request, to ensure that immediate action will be taken and no blocks occur.

‍

Reduce the pull request size

A case study of 2500 peer reviews at Cisco revealed that developers should review a maximum of 200 to 400 Lines of Code (LOC) at a time. This is because their ability to find defects diminishes beyond 400 LOC. When pull requests are too large, they usually have two negative outcomes. 

1. Delayed review: Caused by reviewers not wanting to take on a large pull request because it would reduce time spent on other tasks. 
2. Decrease in review quality: When codes are reviewed, different styles and frames of work are shared. When dealing with thousands of LOC it becomes more difficult to spot bugs and understand which parts of code are affected by what.

Take your time on code reviews

Relying on peers to find bugs is tempting when you have a big workload awaiting you. But, speeding through a code review to get it done won't make you a high-performance team member. 

A study on Cisco concluded that when the rate of inspection is less than 300 LOC per hour it results in the best defect detection rate. They found that speeding through a code review at a rate faster than 500 LOC per hour reduces the velocity of a team and decreases the amount of knowledge shared. 

Promote a constructive code review culture

Peer code reviews can generate stress between team members due to the critique received. However, instead of seeing each inconsistency in the code as a defect, it can be seen as an opportunity to learn from within the team. Peer reviews are: 

1. An opportunity to learn for less experienced team members from senior software engineers.
2. A chance to break bad habits that would remain unnoticed if not pointed out during a code review.
3. A method that promotes lower defect density: The case study on Cisco showed that peer reviews incentivize developers to write cleaner code. Since they know that their code will be checked by peers, they will double check it before issuing a pull request. This has proven to improve the code quality by reducing the defect density, while not consuming too much time.

Reduce the response time of code reviews

The importance of beginning code reviews as soon as possible becomes clear once the drawbacks of a delayed review process are understood. When the response time to a code review is slow: 

1. Code health will be impacted: Code cleanups, refactoring and further improvements to existing change lists are discouraged. This will (1) increase the amount of leftover structures and other unwanted materials within filesystems, and (2) won’t foster the understanding, maintenance, and modification of code within a team. 
2. The velocity of the team decreases: New features and bug fixes are delayed for the rest of the team, increasing the overall lead time of the product and reducing the ability for team members to learn. 

So how fast should the code review stage be?

According to Google’s Engineering Practices it should be performed shortly after the review request comes in and completed within a day to allow for multiple rounds of review. However, it should not deflect a reviewer's attention from current high-concentration work. This is because it has been shown that it will take a lot of time for the reviewer to get back into the flow and resume his work.

Capture internal process metrics

It is helpful to capture and analyze internal process metrics. Without metrics it is tough to judge how effective code reviews really are. How do you know if a quality review was performed on a team member’s work if the reviewer just says “Looks good to me”? Without metrics it becomes difficult to gather objective insights and make data-driven improvements on how code reviews are performed within your team. Metrics like the following become important to analyze:

• Size of inspection: The LOC size of pull requests inspected. 
• Rate of inspection: The average speed with which a review is performed.

By gathering the data of various projects and team members, metrics allow software engineering teams to visualize and conceptualize their work. This fosters the sharing of knowledge among the team, and motivates suggestions on how to improve the review process.

Establish who will review the code

Code reviews shouldn’t be one-sided conversations or done only by a select group within your team. If you include everyone in the process it will improve the collaboration and relations between programmers within a team, while: 

1. Increasing involvement of all team members in the coding process.
2. Diversifying their skills while keeping them trained and their skills sharp.  
3. Speeding up the process as a whole, reducing the overall lead time. 

It is also important for engineers and software architects to work together. They can spot different issues in the code given their different areas of expertise. This fosters a more extensive code review, targeting issues related to both the broader codebase and the overall design of the product, and reduces the bus factor (information risk) in the team. 

‍

How can Athenian help you improve your review stage?

As we have seen, there are many benefits to having an agile and fast review stage. However, if you don’t have access to live metrics and data it becomes difficult to improve the efficiency of the review process. You also lack a continuous timeline of how it has improved over time. Furthermore, more transparency in information always helps in decision making.

Athenian gives insight into what affects your average cycle time, and when. Our software delivery dashboard measures your average review cycle time and lets you identify pull requests that have been blocked in the review process. Athenian also identifies stuck pull requests and notifies you before they have a negative impact on the lead time of your software delivery pipeline. 

Using Athenian, you will be able to incorporate many of the best engineering practices mentioned above and improve your review process. You can:

1. Make smaller pull requests by separating unrelated LOC into different branches to be worked on immediately. 
2. Perform self-code reviews to reduce issues before requesting a review. 
3. Think about breaking tickets down before starting to code.
4. Write useful and concise PR descriptions to give more context to the reviewer.
5. Assign software architects to review a PR’s compliance with the overall product design.
6. Help reviewers navigate pull requests with inline comments, defect logs and code history. 
7. Discuss code reviews face-to-face or via VC, to discuss the feedback from both parties.
8. Run automatic tests before requesting a review, reducing the opportunity cost of your team. 
9. Check metrics such as size of inspection and rate of inspection.