The inefficiency you speak of is not inefficiency of code review, but rather the inefficiency of reaching a shared, deep agreement on what your code should look like and how it should work. Code review is just a place that it pops up.
Thinking of it as inspection alone is a disservice to the cultural value of code review. You want a process that can teach a team member to contribute with lesser inspection? Code review.
I've typically found that with a new team or team member, initially there are a lot of patches returned for modification. After 3-9 months, it tends towards 80% of patches being one-shot LGTMs, the remaining 20% having spec issues or substantive style issues (ie. this module structure will bite us in the butt because...)
This idea of communicating shared knowledge also points at more efficient ways to do that, if CR is a bottleneck:
- Technical onboarding - Google does a great job of this. Taking time to explain how to work with your technologies, and what the expected code style is.
- Linting + style guides - Arguing over style is dumb.
This is great as long as you've got a culture which tends towards trusting LGTM's. That's not inevitable; you can just as easily get to a point of escalating nit-pickery.
However, even if you get to a point where most PR's get waved through, it's still inefficient in the sense that finished code ends up sitting around in a queue, waiting for its LGTMs before it can go to production. That can add days of delay, for no added value in the majority of cases.
Thinking of it as inspection alone is a disservice to the cultural value of code review. You want a process that can teach a team member to contribute with lesser inspection? Code review.
I've typically found that with a new team or team member, initially there are a lot of patches returned for modification. After 3-9 months, it tends towards 80% of patches being one-shot LGTMs, the remaining 20% having spec issues or substantive style issues (ie. this module structure will bite us in the butt because...)
This idea of communicating shared knowledge also points at more efficient ways to do that, if CR is a bottleneck:
- Technical onboarding - Google does a great job of this. Taking time to explain how to work with your technologies, and what the expected code style is.
- Linting + style guides - Arguing over style is dumb.