Code reviews need to happen in-band with the main development & deployment process. To do otherwise limits their effectiveness and generates resistance–like every other out-of-band task that interrupts flow.
Tests and code coverage, linting, and complexity metrics are some of the tools we can use to help focus our code review efforts, and I believe there is a lot more these tools can do. For example, I would love to have rules for creating function names. Good function names should start with a verb–it’s not that difficult to enforce that rule, and you could easily establish a vocabulary of verbs to use across projects. Similarly, the nouns should reflect the problem domain, with the vocabulary building up as the tests and code evolve. This would be much better than the simple, naive autocomplete suggestions currently provided by editors–as useful as that feature is.
Anyway…If it’s not possible to inspect 100% of code changes, something else is required to maximize the overall effectiveness of code reviews. The key terms here are triage and risk. Triage is fast and simple sorting, based on obvious indicators. Risk is the probability of loss or damage due to an adverse event.
To most effectively allocate your code reviewing time, you triage changes to manage risk:
- Changes that impact security incur high risk.
- Changes that impact more critical functions, incur a higher risk than changes that impact less critical functions.
- Changes that impact more frequently used functions incur a higher risk than changes that impact less frequently used functions.
- Senior engineers will make fewer mistakes than junior engineers performing the same task. Consequently, you’d like to scrutinize their work a little more closely. Code reviews are also teaching opportunities.
- An engineer will introduce more defects into a complex function than a simpler function. Consequently, you’d like to limit complexity and scrutinize changes to complex functions more than others.
- A more intensive change incurs a higher risk than a simpler change, but keep in mind that even the smallest change can have major consequences.
- Everyone’s code needs to be reviewed once in awhile.
- All code should be reviewed every once in awhile.
If you use BDD, then you should be able to identify your most critical, service-defining scenarios.