Code review is one of the most common topics here on the SubMain blog. Today’s post covers this subject again, this time attacking a very specific angle: code review tools. If you’ve been a software developer for a while, you’re probably familiar with at least a few of them.
But do you know the different types of tools out there? Would you know how to categorize them? Knowing how to do so might be the difference between adopting the right tool for the right situation or being paralyzed by doubt. Which situation would you prefer?
Code Reviews Are a Good Thing
If you’re a regular reader of this blog, then you know our position on code reviews. And if you’re a new reader…well, the title above just spoiled it for you. We consider code review to be an excellent practice every software development team should adopt to increase the quality of their output. Sure, there are other practices—such as pair-programming—that might help you reap the same benefits. All things considered, though, we still think that code review is a clear winner due to it being more universally applicable, especially to organizations that work in a more asynchronous or remote fashion.
Am I making it sound like it’s all a bed of roses? Because then not so fast.
But Doing Them Without Help Will Only Take You so Far
Code reviews are awesome. But they come with their share of disadvantages and potential problems. Ask anyone who’s been in the field for a significant length of time for some code review horror stories. You’ll probably hear a lot of them…and then some more. Software developers are—gasp!—only humans after all. They’re not less likely than the average person from falling prey to ego, communication problems, cognitive bias, and a lot of other things that can lead to toxic code review scenarios.
There are several ways you can cope with those potential problems. For this post though, I want to focus on one specific approach: the use of code review tools.
Code Review Tools: Yes, You Need Them
I hope by now you understand that A) code reviews are a good thing, and B) they’re kind of hard to get right. There are a number of measures you can take in order to prevent the most common code review problems.
You can better prepare for code reviews and eliminating inefficiency. You can—and you should—periodically re-evaluate your code review process in search of potential problems or points that could use some improvement. Also, you should always be studying and reading. That way you’ll be aware of common code review myths that can undermine your efforts if your team members start believing them. You’ll also learn some anti-patterns that are so bad that they’ll make your better developers quit.
Finally, there are plenty of tools at your disposal that can help you with your code review process. From tools that are meant to “nudge” developers into performing—and asking for—code reviews to other ones that actually automate a lot of the process for you, there’s a huge pool for you to pick from. And that’s what the next section will cover.
Understand the Different Types of Code Review Tools
Not all code review tools are created equal. There are several types of them, each one with their unique specialty. You must understand how to categorize a code review tool so you can make an informed decision about whether or not such a tool is a good fit for you or your organization. For this post, we’ll cover three broad categories of tools: the “assistant,” “enforcer,” and “automator” tools. Keep reading to learn about each.
There’s nothing stopping you from implementing a code review process from scratch. The reviewer could generate a patch file containing their changes and then email this file to the relevant people on the team. After receiving the response from the reviewer(s), the developer could then commit the changes, but only if the proposed changes were approved. In the negative case, they would be back to making changes, generating a patch file, and emailing them to the reviews, and all that jazz again.
If such a process sounds inefficient and error-prone, that’s because it is. It wouldn’t take long before someone proposed some kind of tool to help manage all of this. It could be a plugin for the IDE, a command-line utility, or even a web application, but eventually, someone would end up coming up with something. The good news is that several “someones” already came up with something, so you don’t need to. These types of tools are what we call the “assistant.”
So, in the previous section, you learned about one category of code review tools, which I dubbed the “assistant.” But maybe you’re wondering, “how do I actually get people to use those tools? How do I make my developers submit their work for review?”
That’s where the “enforcer” category of code review tools comes in. Tools in this category enable you to create and enforce workflows that rely on code reviews. Such tools come in a variety of shapes, but the thing they have in common is that by employing them, you guarantee that not a single line of code reaches productions without being reviewed and approved.
Everything that is automatable should be automated. That’s a sentence I like to say when I’m trying to convince people of the value of automation in a software development context. Time is precious, and the salary for developers—at least in developed countries—isn’t exactly low. It makes zero financial sense to have smart, well-paid humans perform tasks that any computer could easily do.
That takes us to the last type of code review tool: the “automator.” Tools in this category automate many or even do most parts of the code review process. This makes the whole process incredibly more efficient and less error-prone, and it frees up a lot of developer time. That way, you and your peers can focus on the parts of the review that truly require our uniquely human traits.
3 Code Review Tools You Must Have
Now that we’ve covered three broad categories of code review tools, let’s see some specific tools that can be a valuable addition to your toolset.
Let’s start with Review Assistant. Its name makes it very clear which category it belongs, right? Review Assistant is a code review tool for Visual Studio. It allows developers to request for reviews and respond to them from inside Visual Studio itself. The tool supports a number of different version control systems, like Git, of course, but also Mercurial, TFS, Subversion, and Perforce.
Colin’s ALM Checkin Policies VS 2017
The second tool we’ll cover is called Colin’s ALM Checkin Policies VS 2017. This tool is a check-in policy for Visual Studio 2017. By employing it, you can create and enforce a workflow in which a code review is required before the developer checks in their code.
That way, you can guarantee that just code that’s reviewed and approved can be integrated into the mainline of your project.
CodeIt.Right by SubMain
Last, but not least, we have CodeIt.Right, a SubMain offering. CodeIt.Right is an automated code review tool. It works by checking your source-code against a set of rules—either the standard ones that come out of the box or ones customized by the developer. Then, it gives you instant feedback, letting you know how well your code did against the verifications. For some scenarios, CodeIt.Right even offers automatic fixes, allowing the developer to easily apply the corrections to their code.
To learn more about CodeIt.Right, check out the series of posts we made explaining its rules in great detail.
Code Review Tools: Know Them so You Can Master Them
For whatever reason, it seems to me that some people in the software development community are kind of allergic to the idea of employing tools that can greatly aid us in doing our jobs. Which is particularly weird, since, if you think about it, our jobs basically amount to creating different kinds of tools. Sure, you should try not to be dependent on tools—or techniques, methodologies, or anything else, for that matter. But if you use them wisely, the right tools can be the boost your software team has been waiting for.
But before you go around wisely using the right tools, you must first know what the right tools are. And not only that, but you should also how to categorize them so you can apply the right tool in the right scenario. And that’s what today’s post was all about.
We’ve started by showing that, while the code review is a very useful technique, performing without aid can only get you pretty far. And tools are a great help. We also proceeded to cover some of the different types of code review tools by talking about the difference between them. Finally, we talked about three specific code review tools that can make for a great addition to your tool belt.
Thanks for reading and see you next time!