3 ms·

Last place I worked (big company, not FAANG) I remember a PR for our main app that affected 500 files and occasionally dozens of places in some of them. All the

• ascagnel_ 5y ago
  I forget where I first saw it, but there's a joke of "ten lines, ten issues; 1,000 lines, looks good". There's a human limit to how much you can hold in your head when reviewing code.
  • whimsicalism 5y ago
    I think it's a double edged sword - people are also way too nitty for small commits, which only incentivizes behavior like this.
  • thetallstick 5y ago
    Looks like the programmer's version of: "If you owe the bank $100, that's your problem. If you owe the bank $100 million, that's the bank's problem.” https://www.goodreads.com/quotes/214064-if-you-owe-the-bank-100-that-s-your-problem-if https://www.goodreads.com/quotes/214064-if-you-owe-the-bank-...
  • sockpuppet69 5y ago
• doix 5y ago
  When you refactor a commonly used structure, it's easily possible to hit situations that you described. In those cases, having nicely organized commits are super important. You need to make sure that the commit that does the refactor only does the refactoring. Nothing else, then you can review the PR commit by commit and it becomes much more manageable. When people start doing multiple things in a single commit with 1000's of changes, it does become mentally exhausting to review. Unfortunately, it requires either being extremely diligent when making the commits or being familiar with git rebase -i. Of course, sometimes it's just thousands of lines of new code and impossible to review :).