Comment by austin-cheney | Hacker News Reader

Comment by austin-cheney | Hacker News Reader

That depends upon how your organization manages branches, releases, and such.

Just take it file by file. If you are using something GitHub Enterprise or the Bitbucket or GitLab equivalents then just leave comments file by file of your progress in reviewing the PR.

Is there a parallel stream for corresponding changes to test automation? If so that helps tremendously. Are there rigorous automated lint/validation/conformance rules in place, because if so that helps tremendously. With enough automation in place your review should be a quick look line by line for major violations and questions about why some change was needed from the business requirements perspective as answered by code comments or documentation. 1500 line PRs don't have to be painful if the platform is mature.

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.

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.

Reply on news.ycombinator.com