Code reviews have become a pretty standard part of how dev teams operate. But I've talked to a bunch of developers about this recently, and it seems like everyone wishes the process was different/better. For some it's an emotional thing - no one likes to get critiqued. For others it's a procedural thing - their company doesn't have clearly defined procedures in place for doing code reviews.
So I'm turning to the HN community for some expert feedback.
What do you hate most about code reviews? What would do do differently do make it better/more effective?<p>Thanks!!
Maybe an obvious one, but at my last org I often wished for more emphasis on keeping patch sets SMALL. I might have liked some kind of soft ban against putting huge patch sets up for review. I'm talking like 1000+ line stuff. In my experience, no one wants to review those; it's incredibly tedious.<p>I say "soft" ban because there are exceptions. I don't mind huge patch sets if the changes are proportionately trivial: One example is mechanical search-and-replace jobs on large codebases. But the 3000-line new module that just gets dumped on reviewers all at once is in bad taste. It's the responsibility of the author of the code to ensure that it is broken up in a way that makes reviewers' job tolerable. My opinion.
Review is often a judgemental concept. It really should be about collaboration and compromise. So I would expand on the tools to compromise, and not just a change list