Even though I trust my team.
As a technical lead, I think code reviews are essential to ensuring the quality of the code. On a project I worked on, due to changes in Project Management, I ended up switching between code reviews as standard and code reviews by exception, and in every case, releases delivered with code reviews baked in had fewer bugs, and were far more likely to meet deadlines.
I believe that code reviews done after integration have roughly the same benefit on these metrics as no code reviews at all. Although this guy prefers optimistic merging, I’m not convinced, and I think pessimistic merging is the only way to review code, especially when automated testing and static analysis are part of the review process.
However, my experience is with working with small-ish, cohesive teams, rather than open source projects seeking new contributors, so please bear that context in mind.
- It’s easier to fix problems pre-merge;
- Blockages pre-merge are far easier to detect (kanban!) – fix the bottleneck, don’t break the process;
- Code reviews are the process by which the team takes ownership of the code;
- The code remains continuously shippable;
- Each code review is a checkpoint for discussion, and segways into refactoring and other improvements.