How to Perform a Thorough Pull Request Review

If you’re a software engineer, you’ve most likely encountered pull requests in your career. If not, it’s time. A pull request should be a standard part of the process when developing an application. Once a developer has completed a feature, they will create a pull request to have their code reviewed before it gets merged into the codebase.

Pull requests are a vital part of the development process and can often become the most cumbersome part, if not treated like a first-class citizen by the developer and the rest of the team. As a reviewer of the request, your job is to ensure the code is correct and of the highest quality before reaching the master branch.

How often should I be reviewing pull requests?

Pull request reviews are notorious for being tedious and time-consuming but should be completed with every task completion. We’re going to lay out some ways to make your pull request reviews more efficient.

How to review pull requests as a software engineer?

Most software engineers understand the importance of reviewing pull requests as they can prevent hiccups later on in the build. At Entrision we’ve done our fair share and understand how they can be frustrating and time-saving in the long run. Follow these basic tips to streamline your review process while maintaining quality.

Make Pull Requests That Are Smaller

This tip is specifically for the developer, not the reviewer. Efficiency often starts at the foundation; drafting pull requests is no different. Making smaller requests is the best way to conduct a thorough review and increase efficiency simultaneously. It is easier to work through the issues in smaller chunks and to more easily understand what the piece of code is supposed to achieve. Massive requests can take much longer to wade through. It is easier to get lost in the weeds resulting in a lower quality review with a much slower turn-around.

Automate As Much As You Can

As a reviewer, there is no need for you to constantly find yourself caught up in the boring, technical aspects of a review. Using code auditing tools will allow you to automate mundane and repetitive tasks that will not only save time but reduce human error and allow you to focus on deeper and more interesting issues for a better review. Processes to automate include:

• Check for white space errors
• Verify automated tests pass
• Double-check code builds
• Point out unused variables

Know the Style Guide

Debates about which style to use is wasted time and steals focus away from other crucial parts of the review. Software development teams need to know the style guide that is the standard for both authors and reviewers. Having this open and available to the developers will help them stay consistent and efficient during coding, making it easier to review the pull request.

Begin with High-Level Issues

Many pull request reviews take multiple rounds before the code is ready to be merged. To conduct a thorough review, it is best to work systematically. Start with high-level issues. Once those are resolved, work your way down to lower-level issues. Working through requests in this manner will also save time because many of the lower-level issues will not be a problem once the high-level issues are resolved.

Communicate Effectively

Effective communication with your team is always going to be a tip for getting a job done better, but we’ll keep reminding you. Misunderstandings can result in wasted time and a lower quality review. Reaching out to the author after the first round of feedback has been submitted is a great way to clear up any confusion and reach a middle ground on differences of opinion about the approach taken in the code.

Don't be afraid to take the conversation out of GitHub comments and into some synchronous form to discuss issues directly with the author.

Avoid Splitting Hairs

Refrain from nitpicking comments that are unnecessary for the code to be successfully merged. These issues should be addressed outside the pull request review, as they often indicate an issue with standards or tooling and not with the request itself. Nitpicking in the pull request review detracts focus from the code's actual issues and results in a lower quality review. Instead, make a note of outside issues you encounter and save them for software development team meetings.