Code reviews need to outgrow pull requests
In the past ten years, the popularity of pull requests has skyrocketed. Today, if you ask most developers about code reviews, they will immediately start talking about pull requests. While you want to review most pull requests, they are not the only (or even the best) way to do reviews. Asynchronous high-quality code reviews can be done without pull requests with the right tooling.__
Pull requests are everywhere!
In the last ten years, pull-based development and pull requests became extremely popular. Last month alone (March 2021), there were over 5.5 million pull requests opened on public GitHub repositories.
And it makes sense. If you have an open source project, pull requests are an excellent tool to systematically validate and accept contributions. It’s only natural that in the open source setting, code reviews will coincide with pull request validation.
However, code reviews are an independent aspect of the development process. Also, the dynamics of a non-open source team is typically very different from the one practiced by open source projects. In such teams, there are many benefits of integrating code reviews earlier in the development process in a review-centric development.
Making code reviews a check on a pull request or using pull requests as the way to do code reviews will hurt your perception of the benefits of code reviews.
Pull requests may be hurting your team
Pull request management is starting to become a costly business. Opening, checking, resolving conflicts, merging a pull request takes time and costs money.
If you use pull requests as the main way to ensure code quality and share knowledge across the team, you have the tendency to start enforcing certain rules to format pull requests. The most widely used one is a size limitation.
We’ve come across teams where a simple refactoring on a codebase had to be split into multiple pull requests to comply with certain requirements. Those recurring situations lead to increasing confusion around the review process.
There are two main aspects associated with pull request validation: automated checks and human reviews. Understanding when you need to perform an automated validation or a human review is key to a better interaction with pull requests.
Running a continuous integration pipeline on every push to a branch that is part of an open pull request is a waste of resources.
Asking a team member to review a pull request with very simple changes when the automated checks have passed is also a waste of resources.
Communication with strangers (as it happens in an open-source project) versus communication with your team members is very different. Pull requests are a method that is very poor in terms of empathy. And that’s okay - it was not designed to be an empathetic/educational way to communicate between developers.
As developers, we need better tooling to help us manage our resources and asynchronously communicate around pull requests. That will help us reduce useless energy consumption, miscommunication between our peers and increase collective ownership.
We are building a better future for pull requests and code reviews - share with us your experience and pains.
Update
(09-04-2021)
We ran a Twitter poll asking how many pull requested were opened by bots in March 2021.
The correct answer is 50 - 75%.
Opened pull requests of March 2021
We crunched the numbers and found out that ~62% were open by bots. dependabot alone opened ~46% of the pull requests.
