Thanks for raising an important topic. A critical part that I think is missing here is what are the goals behind code review process. They may be quite different:
- improving quality of software
- compliance requirements
- building shared understanding of the codebase
- mentoring for less experienced engineers
- ...
Depending on the goal, speed of the code review may be a goal or a non-goal. In some cases optimizing for speed may hurt primary goal. In another extreme, the fastest code reviews are no code reviews. If the speed of code delivery is your only goal, than maybe the right solution will be remove code reviews from the process and invest heavily into automated tests.
To sum up, my main advice for building the best code review process is start for setting the goal and use it as a guidance.
Thanks for raising an important topic. A critical part that I think is missing here is what are the goals behind code review process. They may be quite different:
- improving quality of software
- compliance requirements
- building shared understanding of the codebase
- mentoring for less experienced engineers
- ...
Depending on the goal, speed of the code review may be a goal or a non-goal. In some cases optimizing for speed may hurt primary goal. In another extreme, the fastest code reviews are no code reviews. If the speed of code delivery is your only goal, than maybe the right solution will be remove code reviews from the process and invest heavily into automated tests.
To sum up, my main advice for building the best code review process is start for setting the goal and use it as a guidance.
Segmenting PRs by amount of risk they create is GOLD! Thank you for the insight