[flustercan]

I don't see how taking it file by file lowers the complexity. If a file introduces a new method and that method it used 10 times in different files throughout the PR, looking at the 1 file doesn't really tell me much. This is compounded when those other 10 files have other changes unrelated to whatever new function I'm trying to review.

We have good unit test coverage and a decent deployment process so I'm rarely concerned about something seriously breaking, its more trying to answer the question "is this approach reasonable" or "could this be done more simply" that I find really hard to answer when there are so many changes bundled together.

[austin-cheney]

Then, yes, if the risk is largely off loaded to automation tasks then larger PRs become far more reasonable. Reviews file by file does not lower complexity, but just segments your effort so as to allow the task to become less daunting. Since you do have good automation in place perhaps the most important thing to review during your PRs is organizational complexity, which appears to be your primary concern. If the change requires tremendous effort due to organization concerns that might be a strong point for push back and refactor such that like conventions are grouped together to lower complexity into the future. Although refactors like this increase effort in the immediacy they lower tech debt at future maintenance. Another benefit of strong automation already in place is that large scale refactors are low cost efforts.