The 800-File Gorilla: Lessons from Reviewing a Very Big Pull Request
Code review, like many practices in software development, is best served “right-sized:” not so small it’s annoying, and not so big it’s daunting. You might even limit a pull request’s (PR) scope to a given feature, aligned with some user story. But what if the PR comes from outside your organization, so you couldn’t play a direct hand in how it was broken down? And what if it concerned something cross-cutting, something like a major framework upgrade that impacts an entire application? In this session, we’ll outline a strategic approach to reviewing large, complex PRs in a manageable way. We’ll look at how to evaluate so many lines of code, effectively track updates, diplomatically provide feedback, and pragmatically select what must, should, or could be done (and by whom). I’ll draw on my own recent experience reviewing a critical pull request from a community member that clocked in at almost 900 files. It took about a month to review and approve, and another month to address follow-up pieces. While it was a laborious and less-than-ideal process, it had to be done, so I sought the best path—and the one I found might make your life less painful too! We’ll examine what went well, what didn’t, and why we would prefer to go small any time we can.
Prerequisites
Some familiarity with coding and code review will help!
Take Aways
- Approach to break down very large body of code changes
- How to prioritize problems, comments, and concerns pragmatically
- How to deliver feedback kindly and intentionally when there is lots of it
- The benefits of code review in small doses (by way of the drawbacks to large ones)