*Large pull requests slow down code review up to a point where large enough pull requests promote less thorough and quicker review Spared you 5 minutes
[deleted]
Large pull requests slow down development
11–20 of 79 posts
Re: Large pull requests slow down development
#12The key is to define the term "large" in this context. Pull requests size is an artifact of a humans brain ability to process changes. Therefore its best to tailor the content of a PR based on how difficult you think it is for the stakeholders you are merging can understand the change. "large" is more a measure of complexity.
When I make changes to a codebase that very few people are experts in and is generally perceived to be difficult to understand, I make "smaller" pull requests so that the change log is followable and changes easier revert.
As with many things in software development: be pragmatic, think of others, and do the best you can.
Re: Large pull requests slow down development
#13There is one place where large pull requests are essential:
In dysfunctional orgs with enormous code review time per PR, with lots of nitpicking, and a CI/CD pipeline that is constantly broken and takes a LONG time to get things into a staging environment.
Re: Large pull requests slow down development
#14*Large pull requests slow down code review up to a point where large enough pull requests promote less thorough and quicker review Spared you 5 minutes
I can attest that super large PRs get through faster due to review fatigue.
I suspect they still slow down development in the long run though due to more bugs and less theory building among the team
Re: Large pull requests slow down development
#15I believe that there's certain things (particularly ambitious net new feature development) that isn't served well by artificially minimizing PR size. You should absolutely strive to keep smaller PRs, but I've frequently seen this become "you should only have small PRs."
> artificially minimizing PR size
Not sure I understand the "artificial" part here. There's nothing "artificial" about breaking up your larger changes into smaller PRs. It's just good practice.
Helps reviewers who are reviewing the code, and helps the author be more focused with their changes.
Even in net new feature development it's a good idea to break up your large changes to something more manageable.
Sorry if I'm not understanding, what do you believe the downside to be?
Re: Large pull requests slow down development
#16Never more than 200 lines.
Re: Large pull requests slow down development
#17there's a principle of small batches that would be worth following
Re: Large pull requests slow down development
#18I'm writing a book, "Bytes Of Wisdom: From Start To Merged" that focuses around code reviews.
I agree that larger PRs can increase the latency of getting feedback and getting quality feedback. I also have another view.
Most code reviews struggle not from the reviewing part and shockingly not the authoring part, but the laying groundwork part. The laying the groundwork part is before any hands to the keyboard to write actual implementation. This part focuses on explaining what is trying to be solved and for what problem. It is bringing everyone who would like to participate in the conversation up to speed on terminology, background, understanding of past decisions and the different proposals looked at, ruled out, etc.
I've seen too many PRs ask for reviews where the reviewer had to read the description half a dozen times and spend an additional hour understanding other systems that interact with the diff to be able to even attempt to discuss if the implementation solution is even the "correct" implementation that should be tackled for the problem at hand.
IMO, there are four key parts to better quality PRs, laying the groundwork, authoring the technical implementation, reviewing and feedback.
Re: Large pull requests slow down development
#19*Large pull requests slow down code review up to a point where large enough pull requests promote less thorough and quicker review Spared you 5 minutes
Also it’s (indirectly) an ad for a product that they’re selling to help devs achieve this.
Re: Large pull requests slow down development
#20I believe that there's certain things (particularly ambitious net new feature development) that isn't served well by artificially minimizing PR size. You should absolutely strive to keep smaller PRs, but I've frequently seen this become "you should only have small PRs."
> artificially minimizing PR size Not sure I understand the "artificial" part here. There's nothing "artificial" about breaking up your larger changes into smaller PRs. It's just good practice. Helps reviewers who are reviewing the code, and helps the author be more focused with their changes. Even in net new feature development it's a good idea to break up your large changes to something more manageable. Sorry if I'…
It's artificial to break up a PR to satisfy the rule of small PRs.
Often you need the full context when evaluating a new feature end to end.
Or you spend 2 days splitting up a PR into smaller PRs so that a person can review it in 30 minutes instead of 2 hours.
I can't say I've ever seen benefit from it both as a reviewer or as a developer, but it could be an effect of different companies and different teams.