Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

What is Pull Request Size?

Pull Request Size is a measure of the number of lines changed within each pull request submitted for review.

Why does Pull Request Size matter?

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 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 block other developments and speeds up the product development process.

Common practice suggest developers should review Pull Requests no more than 200-400 lines of code (LOC) at a time. 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 6-90 minutes should yield70-90% defect discovery.

Large pull requests tend to be glazed over and rubber stamped, limiting the effectiveness of defect detection.

How Umano measures Pull Request Size

Umano measures Size of Pull Request through:

  • Number of files changed

  • Number of lines added and/or removed

Practices that influence Pull Request Size

  • Number of lines

  • Number of lines added

  • Number of lines removed

  • Number of issues addressed in a PR

What’s included?

Each model looks and specific activities within the tools. Below a list of activities that contribute to Balance of Communication and activities that do not have an impact on this metric.

Included

Not included

All Pull Requests in selected repositories

x

Tips for improving Pull Request Size

Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review

Shout out for Pull Requests that are deleting lines of code as this usually indicates a good clean-up of the code base, removal of technical debt and improves maintainability of the code base

Review fewer than 400 lines of code at a time for effective defect detection

Resources

  1. Dias, H., The anatomy of a perfect pull request, 2018, <https://medium.com/@hugooodias/the-anatomy-of-a-perfect-pull-request-567382bb6067 >

  2. Osepchuk, B., Optimal pull request size, 2017, <https://smallbusinessprogramming.com/optimal-pull-request-size/>

  3. Riosa, B. The (written) unwritten guide to pull requests, 2016, <https://www.atlassian.com/blog/git/written-unwritten-guide-pull-requests > 

  4. Dias, H., The anatomy of a perfect pull request, 2018, <https://opensource.com/article/18/6/anatomy-perfect-pull-request> 

  5. Hewa, G., How Big is Your Pull Request?, 2017, <https://hackernoon.com/how-big-is-your-pr-32c4d67ad76c> 

  6. 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.



  • No labels

© Umano. All rights reserved.