How Big is Your Pull Request?

Pull requests have become a part of modern development workflows. It provides the grounds for peer reviews that provide a common learning ground for both new and experienced engineers.

Having an effective development workflow will reduce the bottlenecks in your CI/CD pipeline. Allowing you to ship frequently and iterate so you add value to the business. But how to make sure we have an effective PR driven development workflow is the responsibility of every engineer in your team.

For an example, in a company that follows feature based development workflow would ideally spend x number of days/weeks building a new feature and open a PR with 100+ files and 1000’s of lines changed. The mental fatigue involved in trying to relate 100+ files and to understand its scope so both the reviewer can provide constructive feedback and learn something new from that PR gets limited. This defeats the purpose of PR’s being a tool for learning.

In an alternative approach, the same company that follows a feature based development workflow can adopt a feature branch flow with a collection of smaller PR’s that would construct the complete feature. That results in having a sizeable PR that is not too large. The downside for this is the feature branch would build up and at the point of merging in it would be quite massive, but the overall code would have gone through reviews in quite an effective manner.

Its also possible to refine this further, since feature branches are not everyone's cup of tea. It’s sometimes a bit of a headache to keep the feature branch in sync with the master. In a perfect world, we should be able to break the feature into phases that let us work on the features in smaller chunks and open PR’s against the master. Having the new code disabled or protected with a feature flag so if the whole feature is not ready for public use you can still release the code. This is generally effective at the end of the project you simply remove the flag so the feature becomes publicly available.

Apart from new features, when you work on general maintenance if you do a fix that changes 10 lines but you decide to clean up 10 more files. Better take a step back and break it into different PR’s one for the fix and another for the cleaning up. That way, the context of your PR is always clear to those who review. And the discussions become far more productive.

To sum it up, keep your PR’s small so you can learn more effectively from them. As they always say “Less is more !”