Ask HN: What do you hate most about code reviews?
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?
Thanks!!
(
10 comments
| 2 points
| on HN
)
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.
If code reviews are to be done seriously, time should be allocated / scheduled properly (for the reviewer.)