Code review is, hands down, one of the most fundamental best practices a software shop can employ to produce better software. A good code review practice can shed light on design problems, improve the readability of the code, and spread knowledge throughout a team. It also helps you find bugs early (when it costs less to fix them).
Code reviews sound like a gift from the heavens, right? While far from being a panacea, I’d say they are a spectacular tool to ensure software quality?when done correctly. And that, of course, is the tricky part. It doesn’t take much for a code review practice to go downhill. If you’ve been a developer for at least a few years, then I’d bet you have your share of scary stories to tell.
But that’s not what we’re here to talk about today. Forget the truly horrific stories?toxic workplaces and the like. Today we’re going to cover inefficiency in code reviews. Or, more precisely, we’ll offer you tips on how you can avoid it.
So, without further ado, let’s get to it: four tips that will help you when preparing to implement a code review practice in your software shop.
1. Break the Work Into Small, Discrete Tasks
If you want a software team to successfully adopt code review, you have to ensure that it goes as smoothly as possible. Don’t make the code review a heavier burden than it has to be. It should be as easy as possible, especially for the reviewers.
Why do I say that? A typical software shop won’t have dedicated reviewers (and?that isn’t an advisable practice; more on that later). Instead, the reviewers have other attributions. More often than not, they are also developers, which means they have features to implement and bugs to fix.
By dividing the available work into small units, you make the reviewers’ lives a lot easier. It’s less tiring to review a single class than, say, 50. The smaller the units of work are, the less likely reviewers are to make mistakes. The time it takes to complete the review also goes down.
With tasks that are as small and independent as possible, you’ll also make it less likely for the developers to get stuck waiting for the reviewer to finish. If the tasks are discrete and don’t depend on each other, the developer can submit some code for review and start working on another task right away, decreasing idle time across the board.
2. Have As Many Reviewers As Possible (Within Reason)
When trying to implement a code review practice, there are a lot of potential mistakes that will lead to an inefficient process. But there’s one?mistake that I consider the gravest of them all. What is it? It’s defining a single person (generally someone in a senior position) as the sole reviewer for all code in the organization.
Why would that be a mistake? It kind?of makes sense, right? After all, if you’re going to have reviews, you’ve got to choose reviewers. And who’s better to judge the quality of a given piece of code than the most senior developer? This reasoning is seriously misguided. The exact opposite is more often than not the desirable scenario.
For starters, defining the senior developer as the sole reviewer robs the software team of the perspective of its juniors members. It’s beneficial to get feedback from team members that aren’t yet fully caught up in the organization’s status quo. They often offer a fresh perspective, asking questions that wouldn’t even occur to older members. Although they’re probably younger, more impressionable, and susceptible to being dazzled by the “shiny new thing of the week,” they’re probably also highly in tune with the latest developments in technology, which can be a nice counter-balance to the more pragmatic approach of established members.
Having too few reviewers is a sure way to overwhelm them. Unless your team is very small, the constant flow of new review requests will disrupt their work, damaging the quality of their output. The quality of the reviews themselves will also suffer. Reading code is hard work. Reading and evaluating code from 9 to 5, while also offering feedback and suggestions? Pure craziness.
The lone reviewer/few reviewers approach quickly makes the code review practice the bottleneck of the software development process. Combine that with work organized in huge tasks, and the result is a software team unable to work because they’re waiting for a miserable reviewer to go through an endless queue of review requests.
3. Get Rid of Ambiguity
Want to have an incredibly inefficient code review practice? Well, here’s a great tip: make the whole thing as ambiguous as possible. What do I mean by that?
Sometimes software teams will adopt code reviews without really understanding what problem they’re trying to solve. If you go around asking the team members what the purpose of the code review practice is, you’re bound to hear several different answers. “To find bugs,” one developer will say. “To enforce a coding standard,” another will say. “Well, this review thing is nonsense. It’s just to satisfy Sally’s desire to enforce her tabs over spaces preferences”, says a third.
If you want your review practice to be as efficient as possible for your team, then every member must be on the same page about the practice’s purpose. Every reviewer should know what to look for when reviewing code. For instance, if the team’s verdict is that the reviews are meant to examine business logic, then you shouldn’t refuse your coworkers change because it doesn’t adhere to your aesthetic preferences.
4. Have a Standard Document to Keep Reviews Mostly Opinion-Free
This point is the logical result of the previous one. Removing ambiguity from your process is one step; the next step is to take whatever is left after that and make it?standard. Document this standard and publish it to some easy to access place.
What should this standard document contain? It depends on the purpose of your code review process, as defined by you and your team after pruning ambiguity out of your process. For instance, if you’ve decided that your code review process will be solely focused on aesthetics concerns, then the standard document will contain topics addressing:
- Spaces and white lines
- Placement of opening and closing brackets
- Naming guidelines
On the other hand, you may have decided that your code review process will concern itself only with higher level concerns, for example, to ensure a good design for the application and avoid bugs. Then your standard document would contain topics such as:
- Guidelines for catching and throwing exceptions
- Design principles for classes and methods
- How to choose between inheritance and composition
And so on.
Regardless of the actual contents of your design document, what’s important is that it exists and is readily accessible by everyone on the team. This will ensure that the review process is as free from personal opinions and preferences as possible.
Tools at Your Disposal
We’ve just presented four tips on how to achieve more efficiency in your code review process. Do you know that can help you implement the third and fourth tips more easily? Automation.
I often say that everything that is automatable should be automated. Meaning, if you can automate a process, then you probably should. Are some parts of a code review process automatable? Absolutely!
SubMain offers a tool called CodeIt.Right, which is an automated code review tool that works by checking your code against a set of rules. By doing this, CodeIt.Right gives you instant feedback about the quality of your code and even offers automatic fixes to many of the issues.
Download CodeIt.Right today and give it a try. Start harnessing the power of automation to take your code review efficiency to the next level!
Learn more how CodeIt.Right can help you automate code reviews and improve the quality of your code.
