There are certain ways to organize large PRs to make them easier to review and deploy. Some examples: - if a large refactor moves code around in addition to c

There are certain ways to organize large PRs to make them easier to review and deploy. Some examples: - if a large refactor moves code around in addition to changing logic, omit the pure moves from the diff and provide a list of files moved in a description - if a large refactor involves a lot of renaming, or other mechanical manipulation, in addition to a little bit of logic changes, split those apart. That way there will be one large mechanical diff, where you can state in the description, "Yes I changed 500 files and there are 20 pages of diffs but the nature of changes is the same as in the first file." This is vastly easier to review for your peers. - A useful safe deployment trick, when feasible: guard new functionality with a kill switch, as well as some kind of sampling gate (e.g. use new logic only where customer id % 31 == 0). Then when proved remove old code in a followup.