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:
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.
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:
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.
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.
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.
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.
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.
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.
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:
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:
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.
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:
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.
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:
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.
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: