Have you heard the old saying, “You can have something fast, cheap or good, but you can only pick two”?
Software development is no exception. Code review best practices help you maintain a delicate balance between the need to be efficient and the need to be effective.
Table of Contents
- Git On The Same Page with Code Review Goals
- Eliminate Idle Pull Requests
- Limit PR Size
- Improve Review Depth
- Reinforce Code Review Best Practices
- Celebrate Your Success
Git On The Same Page with Code Review Goals
What are your goals for improving your team’s code review process? Maybe you have some code review best practices documented already. Or maybe you need to canvas your team about what best practices they’re already using. Or you need to get some new ideas.
It may come as a surprise to you, but some teams don’t use pull requests in their Git system at all. The downside to this is that it’s hard to know if your team is improving if you’re not tracking activity. Also, this may mean there is limited feedback from colleagues on code standards. And not to forget – this leads to more bugs being introduced into production, which creates problems for the user and for you, forcing you to put out the fire by hot fixing, rolling back to an older version, or reverting the changes. If you’re already using pull requests, you’re one step ahead; if you’re not, keep reading to see the advantages.
Using PRs in Git and setting goals around them needs to be the first step in establishing best practices for your code reviews. Everybody doesn’t have to do things the same way, but when you set goals for your team, they’ll know what you expect from them and what to expect from their peers. Only then can your team can work with each other more efficiently.
Let’s review 3 goals you can set with your team to improve their peer review process.
Eliminate Idle Pull Requests
It doesn’t do any good to use PRs in your Git if you don’t set goals around how quickly they’re reviewed. One of the most common DORA metrics is cycle time, but cycle time is best understood in four phases, the second of which is pickup time.
Unfortunately, for most teams the average pickup time for pull requests is two days. Quick: what did you have for lunch two days ago? If it took you a minute to remember, or if you don’t remember, then how can you expect a developer to remember the context of a pull request they submitted two days ago?
Eliminating wasted time between issuing a PR and starting to review code cuts down on the time your developers spend trying to remember and then explain. Our Data Science team evaluated nearly 2,000 dev teams and determined that elite development teams have a PR pickup time of less than 7 hours.
Pull requests gather dust for a few reasons.
Sometimes reviewers don’t know the PR exists. Did the developer forget to assign a reviewer? Did they forget to email the team informing them of the need for a review? Did everyone think someone else was going to jump on it? Or did a reviewer get assigned, but they’re too busy with their own coding right now? We’re all human. These things happen.
Or maybe it wasn’t a mistake at all. Often the size or lack of context around the review can leave developers deciding to do almost anything else, which leads me to the next goal.
Limit PR Size
A Smartbear study revealed that reviewers become less likely to catch defects when they’re reviewing more than than 400 LOC in one sitting. This is a great start, but again, our Data Science team suggests you set your team goals even smaller if you want a truly elite team. Limit your PR size to no more than 225 changes.
We found that not only do smaller pull requests lead to improved code quality but they also get merged faster. In contrast, large PR Sizes correlate to longer cycle time and code complexity.
Improve Review Depth
Everybody can and should participate in reviewing code. As a team lead, maybe you don’t code or even review code anymore, but if you’re one of the most experienced team members, they still need your feedback in this capacity.
One of the benefits of code reviews is the ability to level-up the experience of your team and quality of their code quickly. But if your reviewers have too much WIP, lack context or are overwhelmed by the size of the review, you may end up with superficial, “looks good to me” comments just to merge faster.
You can lead the team to improve in this area by setting and tracking goals around review depth. At LinearB, we calculate Review Depth by counting the number of comments on PRs throughout the iteration and dividing them by the total number of PRs submitted. Elite teams average more than 6 comments per review.
Reinforce Code Review Best Practices
If a pull request falls in the forest of GitHub, it doesn’t make a sound, but maybe it should. Setting goals and tracking metrics might improve your code review process a bit, but it won’t establish sustainable best practices in a meaningful way. Neither will harping on your devs meeting after meeting.
This is why we developed WorkerB, an automated bot that saves time.
WorkerB can provide personal notifications to the developer and assigned reviewer via Slack or MS Teams. Plus, because we correlate your Git and project management data, like Jira, your reviewer gets context around which ticket the review is related to.
We also give them an estimated review time, so they can schedule it around other work in progress and avoid context switching. Our personal alerts also feature a snooze button in case now isn’t the best time, but you don’t want to forget.
Plus you can configure notifications that warn your team when your goals aren’t being met. Now the whole team is alerted and accountable for jumping in to give a basic review another look over before merging. Check it out.
Celebrate Your Success
Once you have team buy-in on your goals and you’re automating reinforcement of the best practices needed to be an elite dev team, you have to celebrate your success. Our Team Goals dashboard makes it easy to visual continuous improvement over time.
