Code reviews have become a vital part of the software development process. They improve code quality, developer performance, and save development teams time. But only when done correctly.
So what does a good code review look like? Why is it so important? And can any part of the process be automated?
To answer these questions, let’s look at the best ways you and your team can handle code reviews.
Table of Contents
- Code Review Definition
- Main Issues a Code Review Process Solves
- Give Your Reviewers Context
- Keep the Code Changes Small
- Give Constructive Feedback
- Include All Team Members in Your Code Review Process
- Automate to Improve
- Measure & Iterate on Your Code Review Process
- Best Practice and the Right Tools: A Perfect Combination
Code Review Definition
A code review or peer code review requires one or multiple team members to check another team member’s work. You need to review any changes made to the source code before implementing them into the codebase. Doing so will improve code quality and help programmers work in collaboration.
Main Issues A Code Review Process Solves
Code Quality
Are you looking for a checklist to standardize your PR process and fix code quality issues? This happens because too many developers merge their code without review, or the review depth is a single comment that says, “Looks good to me,” without any real feedback.
Establishing a code review process and reinforcing it with your team, should improve your code quality and reduce rework or code churn.
High Cycle Time
Another important problem that a review process solves is preventing bottlenecks in your software development lifecycle and reducing cycle time. Code reviews typically have lots of idle time and severe context switching.
Remember that cognitive load increases when revisiting code. The longer it has been since a developer wrote the original code, the harder it will be for them to regroup their thoughts and get in the state of flow.
This creates idle time as a developer tries to re-read what they have written before revising the code. Therefore, both context switching and idle time are the biggest productivity killers in the code review process.
So let’s look at six steps you can implement into your code review process to ensure your software engineering team is reaching its full potential with code quality and cycle time.
Give Your Reviewers Context
By default, code reviews cause context switching, but if you can supplement the review with context, the reviewer will be able to make better decisions and potentially have to switch context fewer times.
As you go into review the lines of code, you must know what to look for. For example, a reviewer might ask themselves these questions:
- Do you understand what the code is supposed to do?
- Does the code work as you expect it to?
- Does the code fulfill all regulatory requirements?
Answering these questions requires them to go to Jira or whatever project management tool you use to read about the issue.
We’re on a mission to keep developers from ever having to log into Jira again. Our developer bot WorkerB provides the context that developers need to start a review: related issue and estimated review time. It can even detect when a pull request isn’t linked to a Jira ticket and help you create one in a single click, all in an automated notification.
Keep the Code Changes Small
There are two general rules of thumb around code reviews: the 60 Minute Rule and the 400 Lines Rule.
The 60 Minute Rule says do not review code for longer than 60 minutes in a single sitting. Attention to detail and performance level drop after that point. So, conduct code reviews in short sessions.
The 400 Lines Rule recommends you never check more than 400 lines of code in a single review session. This will ensure that you review the code with maximum efficiency and concentration.
Our data science team at LinearB studied nearly 2,000 dev teams and discovered that elite engineering teams keep their average code reviews to under 225 changes.
Give Constructive Feedback
Give constructive rather than critical feedback. Advise your team to ask questions and avoid making statements. Praising good efforts by your team members will help encourage this behavior as well.
You must foster a positive review culture. So, it should not matter who initiated the error. What matters is that you caught the bug before it affected your product.
Encourage your team to collaborate on peer reviews via Zoom or MS Teams if there are significant changes. It’s a more effective means to communicate feedback because you can hear the person’s positive tone that you might miss in an async communication method.
Plus, genuine feedback results in developer growth and deeper reviews.
Include All Team Members in Your Code Review Process
Make sure everyone on your team is given the opportunity to review code. Include both engineers as well as software architects. The collaboration and back-and-forth feedback exchange between junior developers and experienced developers can raise the overall awareness and experience of your entire team.
Automate to Improve
In a challenging new world where engineering teams work remotely (at times thousands of miles away), code review automation tools are becoming the new normal. These code review tools save time, eliminate manual tasks, reduce context switching, and project idle time through personal automation for developers.
Our developer bot WorkerB was designed with these objectives in mind. As you make changes to your code review process, you can actually set goals in LinearB and then automated WorkerB notifications warn your team when these goals aren’t met.
For example, I noted earlier that code quality issues are often related to code being merged without a review at all or being merged with superficial feedback. You can set goals to ensure that no code is merged without review again, and WorkerB will notify the team when this occurs. Your team can then take action to revert it and review it before it goes to production.
Measure & Iterate on Your Code Review Process
The last step in improving your code review process is measuring the improvements and impact with team-based metrics.
Since one of the main issues a better code review process can solve is high cycle time, a great metric to start tracking for improvement is cycle time. But additionally, if the code quality improves in the process, your code churn or rework ratio should decrease.
For this, you can use the LinearB Metrics Dashboard. It provides a birds-eye view of the information you need to see if your process changes are improving your team performance and software development lifecycle.
Best Practices and the Right Tools: A Perfect Combination
When performed correctly, the code review process improves nearly every aspect of your team. Imagine what less rework and a shorter cycle time could mean for your sprint planning accuracy. You might actually be able to deliver on your promises and ship features faster!
