How to Speed Up Your Code Reviews

Every team eventually struggles with slow code review. The process necessarily takes time, and that’s time that developers badly need to build their own features. Code review should be thorough and meticulous, but we don’t want it to take up any more of a developer’s time than it must.

Slow code review usually isn’t due to too little time available in the developer’s workday, however. Rather, it’s often a symptom of both the process and the code being too tedious for quick review.

So, our job as developers is to have our code as ready and readable as possible before we ask our teammates to review it. We need to make our code review UX as simple as possible.

Fortunately, a few simple steps can cut hours or even days off of the time between pull request submission to merging it.

Ship Smaller Pull Requests

Break your work down into parts. For example, do you have a big ticket? Do you see unrelated things that all need fixing?

Trying to swing for the fences and get everything done in one go is tempting. Doing too many things in one chunk makes it difficult for your team to review your PR, however. It’s OK if one ticket has multiple, smaller PRs.

I hold the opinion that it’s better for PRs to be too small than too big. Your team is much more likely to review and re-review a very small PR than a very large one.

If a PR is small, a teammate can look at your code and quickly understand the work and underlying logic. As such, they’ll likely approve it without a second thought. That way, you cut your code review time to a fraction of what it would have been. You’ll also increase your team’s confidence that the code is correct because it is small and easy to understand.

On the other hand, if a PR is too big, your teammates might not even look at it until they can carve out enough time in their day to understand it deeply, which may add hours or days until they can finally get around to it. If the code gets merged before an individual gets a chance to look at it, they might never see that giant piece of code or understand important changes.

Alternatively, when they do find the time to review it, at worst, they’ll be reviewing the same massive chunk of code repeatedly and get “code review fatigue.” When this happens, your teammates may eventually become reluctant to review your code at all.

Of course, you don’t need to create an individual PR for every line of code. But breaking work into multiple, smaller pull requests will produce more effective and efficient code review overall. Make your PRs small, and you’ll see how much more quickly your team will be to review them.

Read More From Paul Rowe26 Great Tools and Websites Every Developer Should Know

Review Your Own Code First

Basic Fixes

Once you have a PR up, put a work in progress (WIP) tag on it and do an initial code review yourself. Be nitpicky on your work because your team will be.

Look carefully for basic things, including:

• Typos

• Better variable names

• Code formatting

• Code is easy to read and understand at a glance

• Avoid linter errors

• Good unit test descriptions and formatting

• Following your own repos rules (examples: removing code comments, file naming patterns, PR formatting, etc.)

When your peers see these issues reappearing in your code often, they’re less likely to readily jump to review it because they don’t want to have to remind you of fundamental issues repeatedly. Fix the basic problems in advance, and you’ll see your teammates stop avoiding your work. Instead, they’ll probably start coming to your code to learn from it.

Structural Fixes

While reviewing your code, and after fixing the basics, start looking for structural improvements and optimizations. Here are some questions you should ask yourself:

• Can you break big functions into smaller parts?

• Can repeat code be extracted and shared?

• Are tools like state managers overused? Underused? Misused?

• Is it easy to understand how code is talking to other parts of the application?

• Are the tests actually testing things effectively?

Even if you don’t find anything to fix, you should add comments to explain your approaches in complex sections. If you have to pay close attention to keep track of your code’s logic during review, think of how difficult it will be for the reviewer who’s coming to it without any preexisting knowledge.

Leave Comments on Your PR

You may find areas of your code that cause you to say, “This works (or doesn’t), but I don’t know why.”

When you run into this kind of problem, PR reviews are your best opportunity to learn, ask for help, or get a second opinion. Asking questions and collaborating is a good thing, no matter how long you’ve been doing your job.

Your code also may need a little extra explanation for teammates to understand why you did something a certain way, and you probably already know what areas those are. By leaving comments, you can answer their questions in advance.

So, in GitHub/Bitbucket/your service of choice, leave comments on your PR.

• “This function throws an error sometimes, and I can’t figure out the cause.”

• “This works but feels clunky, is there a better way to do this?”

• “This is a temporary mock until our data layer is added.”

• “Hey teammate, here’s an example of the code we were discussing earlier.”

Start the discussion and prompt your teammates for targeted answers. That way, they’ll know the first things to look at, and you’ll get the most important parts of the review taken care of early.

Consider the Reviewer’s Experience

Create a better code review experience for your teammates, and they’ll return the favor.

Code review is already hard. Make it easy on your teammates.

When you make your code easy to understand and your work has minimal simple issues, your team will not hesitate to review your work for the more important things. Respond to comments quickly, keep track of the feedback you’re addressing, and notify the reviewer that you’ve addressed their feedback (a simple “updated” in response is often enough).

And of course, be excellent to each other.

Has your team implemented practices to improve your code review process? Do you need help building a process that is thorough and effective? At Method, we are always trying out new ideas and strategies to improve our client’s teams, processes, and enjoyment of work. Feel free to reach out with any discussion!