Writing clean code is just one of many factors you should care about when creating a pull request.
Large pull requests cause a big overhead during the code review and can facilitate bugs in the codebase.
That's why you need to care about the pull request itself. It should be short, have a clear title and description, and do only one thing.
Why should you care?
- A good pull request will be reviewed quickly
- It reduces bug introduction into codebase
- It facilitates new developers onboarding
- It does not block other developers
- It speeds up the code review process and consequently, product development
The size of the pull request
The first step to identifying problematic pull requests is to look for big diffs.Several studies show that it is harder to find bugs when reviewing a lot of code.
In addition, large pull requests will block other developers who may be depending on the code.
How can we determine the perfect pull request size?
A study of a Cisco Systems programming team[1] revealed that a review of 200-400 LOC over 60 to 90 minutes should yield 70-90% defect discovery.
With this number in mind, a good pull request should not have more than 250 lines of code changed.
Image from small business programming[2].
As shown in the chart above, pull requests with more than 250 lines of changes usually take more than one hour to review.
Break down large pull requests into smaller ones
Feature breakdown is an art. The more you do it, the easier it gets.
What