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.
You're spot on that the code review process goals can vary - further, even within a single organization, different reviews may have different key purposes and differing levels of risk.
For organizations at scale, leveraging different PR workflows based on the context of the PR is essential to improving efficiency.
Thanks for the kind words! I find that most PRs fall into one of these categories:
1. Safe changes that create little to no risk, such as zero-risk resources or PRs from owners of non-production code. These should be approved automatically
2. Standard improvements that create low to moderate risk for production systems. These PRs should go through your standard peer review process before being merged.
3. PRs that touch particularly sensitive or complex parts of the code or that have the potential for significant security risks. These should have extra scrutiny, and you should implement automations to ensure your team has the context they need to properly review the code.
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.
You're spot on that the code review process goals can vary - further, even within a single organization, different reviews may have different key purposes and differing levels of risk.
For organizations at scale, leveraging different PR workflows based on the context of the PR is essential to improving efficiency.
Segmenting PRs by amount of risk they create is GOLD! Thank you for the insight
Thanks for the kind words! I find that most PRs fall into one of these categories:
1. Safe changes that create little to no risk, such as zero-risk resources or PRs from owners of non-production code. These should be approved automatically
2. Standard improvements that create low to moderate risk for production systems. These PRs should go through your standard peer review process before being merged.
3. PRs that touch particularly sensitive or complex parts of the code or that have the potential for significant security risks. These should have extra scrutiny, and you should implement automations to ensure your team has the context they need to properly review the code.