Decrease PR Size

Why Is It Important?

There are several vital reasons why PR size should be as small as possible. These include:

• Improved code quality: The smaller a PR is, issues such as logic errors, bugs, and lack of compliance with the company coding standard can be more readily identified, allowing the quality of the code to be better.
• Improved code review communication: Fewer developers and stakeholders need to be consulted the smaller a PR is.
• Reduced review time: The smaller a PR is the easier and quicker it is to review. This is because there are fewer changes to consider, allowing the reviewer(s) to keep the implications of the change readily in mind and the less overwhelming the task will seem.
• Easier to test changes: Smaller PRs touch fewer parts of a codebase. As a result, they’ll need fewer tests to be created, and the implications of the changes will be more readily and rapidly understood.
• Fewer merge conflicts: The smaller a PR is, the quicker it can be submitted before another PR seeks to touch one or more of the same areas. By doing this, the probability of merge conflicts between two or more PRs is greatly reduced.

What KPI Should You Track?

No two PRs will ever be the same size, as their contexts will always differ. However, by keeping track of the median PR size, you can stay abreast of whether PRs are growing too large.

What Are The Underlying Metrics?

To assist with this, there are three metrics to track:

• Pull Requests Created
• Number of Pull Requests reviewed
• The proportion of Pull Requests under 500 lines

How Do You Decrease PR Size?

There are five key ways to decrease PR size. These are:

• Have focus: Similar to a good commit, a PR should only change one logical aspect of an application, nothing more. A PR should never change multiple things nor let how it changes something grow too large. Split out unrelated changes into separate PRs.
• Have clear output expectations: The developer creating the PR should know what they are expected to achieve and be able to ascertain that quickly, by being able to talk with their Engineering Manager or the relevant Product Owner.
• Have empathy for the reviewer: Put yourself in their shoes and consider how challenging it will be – and how long it will take – to review an excessively long and complicated PR. To help know if a PR will be too long, ask yourself if you could explain the purpose of the PR in one short sentence.
• Use feature flags: Until the changes introduced in a PR are considered production-ready, feature flags should be used. These allow functionality to be hidden until specifically desired, which avoids customers and stakeholders accidentally seeing it. ‍
• Use git properly: Use tools such as git stash, rebase, and cherry-pick to keep a PR as small as possible, while letting a developer work as makes the most sense for them. These (and other git functionality) allow PRs to be pared down, to move changes from one PR to another, and to keep changes for another time.