How to Perform a Thorough Pull Request Review
Pull request reviews are notorious for being tedious and time-consuming. The good news is that with some of these simple changes, they don't have to be! As a reviewer, your job is to ensure the code is correct and of the highest quality before reaching the master branch. How do you perform a thorough pull request review while saving time? Follow these basic tips to streamline your review process while maintaining quality.
Make Requests That Are Smaller
As a reviewer and a contributor, this is a tip that can make both of your lives easier by providing a faster turnaround. Making smaller requests is the best way to conduct a thorough pull 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. It also results in fewer iterations overall.
Automation is Your Friend
As a reviewer, there is no need for you to constantly find yourself caught up in the boring, technical aspects of a review. Using a 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
Adopt a Style Guide
Debates about which style to use is wasted time and steals focus away from other just as crucial parts of the review. Software development teams need to adopt a style guide that is the standard for both authors and reviewers. There are two ways to adopt a style guide:
- Choose an existing style guide that will become your new standard.
- Create a new style guide for your team.
The option you choose isn't important. What is important is that you now have a standard to refer to when arguments about the code style come into question.
Begin with High-Level Issues
Most 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.
Effective communication is one of the most important components of a thorough pull request review. 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 goal of the final product.
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.
Have some feedback? Does your team have other processes in place that lead to better pull request reviews? Let us know! Our team is always looking for ways to improve.