Code review isn’t a single practice. The term can mean different things to different people, from a lightweight, informal process to an oppressive, bureaucratic one. Some people consider tests and static code analysis tools like Visual Expert to offer “automated code reviews” while others insist that code reviews require manual human inspection.
There are also many different code review tools out there, and not all of them lead to great results.
I believe that code reviews are great for improving code quality, but they can go terribly wrong, hampering the software development process and producing the opposite results of what you’re trying to achieve. This post is here to help you, though. We’ll cover some code review tools that can help you and your team avoid the worst code review pitfalls, the worst being, in my opinion, ruining your team members’ flow states.
Table of Contents
- Code Review Fundamentals
- 4 Code Review Tools You Should Check Out
- Take the Pain Out of Your Code Review Process
Code Review Fundamentals
Before walking you through our list of code review tools, let’s take a step back and talk about some fundamentals. As I said, code review is somewhat of a loaded term, which means the way engineers perform reviews at my organization can be dramatically different from yours. That’s why it’s vital we’re on the same page regarding the meaning of code review, the benefits it can bring, the different types of code review tools at your disposal, and the reasons why this process often goes wrong.
Let’s get started.
The What and Why of Code Reviews
Let’s start with the “what.” What are code reviews, in my view? They are lightweight processes in which engineers review the code of their peers in a comprehensive but relatively quick way.
What are the benefits of code reviews? Engineers review code to find bugs, give suggestions to improve style, security, or performance, and maybe even learn something in the process. The overall quality of the source code rises immediately, and only continues to rise as the code review process becomes evermore refined in a team.
(If you want to get started doing code reviews on your teams – they’re really quite easy to implement – check our Guide for Team Leads and our Best Practices for Pull Requests.)
I’ve introduced code review processes to companies that didn’t have them, and, in my experience, they also improve code in a different, subtler way: just by knowing that their code would be reviewed, most engineers became more careful and diligent when coding, writing better code than they would’ve written otherwise.
Code Review Tools: Several Sizes and Shapes
When it comes to code review tools, there are many for you to choose from. They can differ in several ways:
- Standalone tool vs. being part of a larger ecosystem
- Dependent on Git or version control system agnostic
- Integrated with the IDE (integrated development environment) or not
- Open source project or closed source project
These are just some of the ways in which code review tools differ. However, to me, these characteristics—while important—are secondary. The most pressing question should be: does your tool of choice lead to or prevent code review anti-patterns?
Code Reviews Can Go Wrong, but That’s Not Inevitable
There are many ways in which a code review process can go wrong:
- They can decay into toxic processes, with too much subjectivity and personal attacks.
- In some organizations, code reviews are long, bureaucratic code-inspection processes in which committees approve every change.
- Another terrible anti-pattern is the gate-keeper: when a single person—e.g. a team lead—is the only one responsible for approving every change or pull request.
- Code reviews can significantly slow down cycle time.
This last point is an important one, especially in a continuous integration/continuous deployment paradigm where speed is paramount. LinearB analyzed over 773,000 pull requests and 3.9 million comments from 26,000 developers. We found that on average, PR review time accounted for almost 70% of cycle time. And of that 70%, the PR spent the majority of it sitting idle.
A bad code review process can seriously hurt how quickly your team ships code. That’s why we developed, WorkerB, a bot helps you get your PR reviewed 10x faster.
But in my opinion, the biggest problem with a bad code review process is that it disrupts engineers. If you’re familiar with the concept of flow, coined by professor Mihaly Csikszentmihalyi, you probably know that, after someone interrupts you when you’re in deep focus, it can take a long time to regain that focus.
We recently interviewed Katie Wilde, VP of Engineering at Ambassador Labs, on the Dev Interrupted podcast and she had a great explanation flow state.
You can listen to the full episode here.
Protecting the focus and attention of a team is a sure way to ensure its productivity is as high as possible. So, let’s walk through some code review tools that can make your review process better while respecting your flow.
4 Code Review Tools You Should Check Out
You can use these review tools to create a sane review process.
GitHub
It might feel weird to think of GitHub as a code review tool. After all, the platform offers so much more. However, GitHub offers powerful-yet-lightweight code review facilities. It’s possible for reviewers to comment on single lines or offer general comments. They can leave suggestions, approve changes, or make requests for mandatory changes that need to be resolved.
GitHub’s UI offers a clean, easy way to compare the old and new versions of files, and it allows the reviewer to mark already-reviewed files as completed.
The workflow that GitHub enables provides an asynchronous experience for code reviews and pull requests. Reviewers aren’t forced to stop what they’re doing and review pull requests right away. Moreover, the very nature of Git allows authors to work on other tasks while their pull requests await feedback.
Review Assistant
Review Assistant is a code review tool by Devart. The tool consists of a Visual Studio plugin that allows developers to request—or respond to—code reviews without ever leaving the IDE.
Even though Git is, by now, the de facto industry standard when it comes to version control tools, there are other tools out there, and Review Assistant supports several of them in addition to Git:
- TFS
- Perforce
- Subversion
- Mercurial
Review Assistant is a paid tool, but it offers both a 30-day trial and a free plan that can be used by up to three users.
Since this tool is an IDE plugin, it allows developers to perform and request code reviews without a lot of context switching, minimizing the risk of disrupting their flow. This is also important since peer reviews that happen more quickly can become more collaborative code reviews in which the reviewer and reviewee are engaged in a deep and productive conversation about how to improve the code.
Gerrit
Gerrit is a free and open-source tool for code collaboration. Unlike some other tools on our list, it supports only Git. Gerrit allows not only discussion and code reviews but also can act as a Git server itself. So, Gerrit can be your free, open-source, on-premises alternative to GitHub, GitLab, and the like.
Unlike Review Assistant, Gerrit isn’t an IDE plugin but a web-based tool. That means you must leave the comfort of your IDE to use it; but at the same time, it does provide for an asynchronous review experience, so your team is free to design a workflow that minimizes interruption and context switching.
Crucible
Crucible is a code review tool by Atlassian. It supports Git, SVN, Mercurial, CVS, and Perforce, meaning you can use it regardless of your choice of source control system.
Like GitHub, Crucible is flexible when it comes to the discussion it fosters. Users can comment on single lines, files, or leave general comments. Additionally, Crucible offers users the flexibility of starting formal, more structured review processes or quicker, lightweight ones.
Like GitHub and other tools, Crucible enables an asynchronous, iterative code review process.
LinearB
We built LinearB to be the ultimate tool to help dev teams produce higher quality code and speed up their development times. A key part of this mission is improving the process around code reviews. As mentioned before, we’ll help your team eliminate the problem of idle PRs which will greatly speed up cycle times. We’ll also keep an eye on the quality of reviews and our WorkerB bot will send out alerts when a PR review may have been cursory or didn’t occur at all.
But notifications like these are just one small piece of what we offer. With LinearB you can track over time the speed and quality of the reviews being conducted on your team, in addition to tons of other metrics.
But metrics alone won’t improve dev teams. You need a holistic system that helps you establish goals, provides you with the tools you need to accomplish those goals, and tracks the improvement of your development process. That’s what LinearB really offers.
Take the Pain Out of Your Code Review Process
As a software engineer, I’m always searching for ways to improve the quality of my code and reduce technical debt in my organization. After many years, I’d be hard-pressed to find a technique that’s more effective in improving code than code reviews—with the honorable exception of automated testing, of course.
Despite being a generally accepted practice—and lauded by big names in the industry—code reviews aren’t without some controversy. There are people who dislike them for various reasons. Code reviews can derail into dark patterns—such as processes that disrupt the flow of engineers. But with the tools we went over in this post, you can avoid these downsides and reap the immense benefit of code reviews.
If you want to give LinearB a try, get in touch with us to set up a demo.
