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.
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.