Best practices for speeding up code reviews

Code review is a natural process of software development. It is required to ensure the quality of the code and functionality of the final product. But for software engineers, it is often a painful experience as reviews can be extremely slow, causing delays and switching between tasks. For developers, code reviews can be extremely frustrating, especially when the reviewer is nitpicking or bikeshedding.

Software development teams employ several tactics to correct this problem. While smaller groups working on small-scale projects can eliminate the code review process, it is not an option for enterprise-level companies. Rather than removing pull requests and code reviews altogether, you can improve the experience for both developers and code reviewers by adopting some best practices.

This article will explore some best practices for speeding up code reviews.

Keep pull requests small

One of the biggest reasons developers dread reviewing pull requests is the high quantity of changes in the code base. When there are 1000+ lines of code changes, reviewing these changes can take hours or even days. Often, a reviewer skims through the code rather than carefully reviewing the changes. As a result, the quality of the code is compromised.

Keeping pull requests small is an excellent idea to have high review quality. When a small number of changes are to be reviewed, engineers do not have to spend too much time creating a mental map of how these changes interact with the code. Less number of changes means fewer errors and comments. The reviewer doesn’t have to run to the author often when pull requests are kept smaller.

Keeping the pull requests small can seem daunting if you are not efficiently breaking down your work into smaller tasks. Try to segregate tasks such as separate re-factoring from new features or bug fixes. You can also use feature flags in your code to directly merge small changes into the main branch of the code without showing up in the production app.

Implement Response Time SLAs

The code review cycle becomes inefficient when pull requests are regularly unreviewed for long durations. You must set clear expectations for how quickly a new pull request should be reviewed. What is the maximum time your team allows a code review request to stay pending? Is it an hour? or 24 hours? Two days?

The answer most likely depends on the size of your team, but the best practice for code review is to establish a precise, responsive time SLA (service level agreement). An SLA usually refers to how quickly our response is given when a technical issue is raised. There should be the right balance in deciding response time SLA.

You cannot expect the code reviewers to attend to your new pull requests immediately and drop whatever they are doing. At the same time, it is detrimental to wait for hours to get the changes reviewed. The right approach is to set a regular response time SLA for pull request reviews. For instance, your team can establish a three-hour response time SLA for internal team code reviews and a 24-hour response time SLA for external pull requests.

The right balance of response time SLA puts your team in a flow state where every developer can work on the report and review pull requests throughout the day without affecting their productivity.

Set up continuous integration pipelines

If code reviewers have to go through minimal changes such as comments like “Missing Semicolon” or “Incorrect Indentation”, it will be highly tedious for them to complete the review. Ensure that developers are not spending time on issues that code formatters and code linters can easily take care of. Several tools are available to ensure that code is formatted correctly so developers can focus on essential things.

For example, suppose you are working on a JavaScript project. In that case, you can configure a formatter like Prettier and a linter like ESLint low to automatically format the code in your repo. Additionally, you can set up continuous integration for the repo using tools like Travis CI and GitHub Actions. This CI pipeline will run the formatting and linting task when you’re unit testing. The CI pipeline will block the pull request from merging with the main branch if the pipeline fails at any step.

This approach can automate several essential parts of the code review process, saving hours.

Train junior and mid-level engineers 

One way to improve the capability of your team to conduct quick and effective code reviews is to teach less experienced engineers. During a code review, help junior and mid-level engineers understand what’s important and what’s not. Teach them the grammar of code review comments to communicate efficiently. You can also take references from Google’s Code Review Developer Guide, an excellent guide for code authors and reviewers.

Conclusion

Code review is an integral part of the software development lifecycle, but in the absence of optimization, it can result in unwarranted delays. We hope these steps will help you streamline the code review process.

To learn more, refer to the guide on understanding and improving code quality from Talent500. We are a platform for software engineers to find career re-defining opportunities with global companies. Join us here.