...
Reviewing pull requests can also be one of the most time consuming activities of a team’s software development process.
Making smaller pull requests is the best way to speed up time spent reviewing your peer’s work. By applying the discipline to break down pull requests into smaller, manageable batches of code, it’s much quicker for reviewers to understand the context and , reason with the logic and detect defects that need remediation.
What does ‘good’ Pull Request Size looks like?
Small pull requests are easier to review, making also make it more likely for code to be thoroughly reviewed before approval. It helps to speed up the review, reduces risk of introducing bugs into the codebase, helps not to block other developments developers and speeds up the process to finalise and ship the product development process.team’s product to customers for feedback.
Large pull requests tend to be glazed over and rubber stamped, limiting the effectiveness of defect detection.
What does ‘good’ Pull Request Size looks like?
Common practice suggest developers should review Pull Requests no more than 200-400 lines of code (LOC) at a time. The This is because the brain can only process so much information at a time. Beyond 400 LOC, the ability to find defects diminishes.
Research also indicates that a review of 200-400 LOC over 660-90 minutes should yield70yield a 70-90% defect discovery .Large pull requests tend to be glazed over and rubber stamped, limiting the effectiveness of defect detectionrate.
How Umano measures Pull Request Size
...
Practices that influence Pull Request Size
Number of lines in a
Number of lines added
Number of lines removed
Number of issues addressed in a PR
What’s included?
Each model looks and at specific activities within the tools. Below a list of activities that contribute to Balance of Communication Pull Request Size and activities that do not have an impact on this metric.
Included | Not included |
|---|---|
All Pull Requests in selected repositories | xNumber of files per Pull Request Number of comments made by reviewers Number of tasks created by reviewers |
Tips for improving Pull Request Size
| Tip |
|---|
Review fewer than 400 lines of code at a time for effective defect detection |
| Tip |
|---|
Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in , done frequently throughout the sprint is the most effective code review practice |
| Tip |
|---|
Shout out for Acknowledge Pull Requests that are deleting delete lines of code in your code base as this usually indicates a good cleanauthors are cleaning-up of the code base, removal of removing technical debt and improves improving maintainability of the your code base |
| Tip |
Review fewer than 400 lines of code at a time for effective defect detection |
Resources
Dias, H., The anatomy of a perfect pull request, 2018, <https://medium.com/@hugooodias/the-anatomy-of-a-perfect-pull-request-567382bb6067 >
Osepchuk, B., Optimal pull request size, 2017, <https://smallbusinessprogramming.com/optimal-pull-request-size/>
Riosa, B. The (written) unwritten guide to pull requests, 2016, <https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests >
Dias, H., The anatomy of a perfect pull request, 2018, <https://opensource.com/article/18/6/anatomy-perfect-pull-request>
Hewa, G., How Big is Your Pull Request?, 2017, <https://hackernoon.com/how-big-is-your-pr-32c4d67ad76c>
Yu, Y., Wang, H., Filkov, V., Devanbu, P. and Vasilescu, B., 2015, May. Wait for it: Determinants of pull request evaluation latency on GitHub. In Mining software repositories (MSR), 2015 IEEE/ACM 12th working conference on (pp. 367-371). IEEE.
...