Code Reviews Are Not Effective at Finding Bugs
shepherdly.ioIf your code review approvals are taking days, you're doing it wrong. That's not a system problem; it's a culture problem (your company doesn't factor in review time as part of a developer's job), and possibly a signaling problem (the person isn't aware that you're waiting on them).
You can also open up PRs that merge into another PR it depends upon. Once the bottleneck PR gets merged to main, your dependent PRs get rerouted to be PRs that go to main.
Then comes the issue of deciding what kind of change should be considered trivial enough to not require code review before merging, and who will make that call on a per-change basis. Number of lines is not a good enough metric, because not all lines can cause the same potential damage.
While I agree, a company making a post that is a subtle advertisement for their software is probably the least trustworthy source for pretty much any take.
The purpose of Code Reviews is not to find bugs. The purpose of code reviews is:
- Verify unit tests have been created, have passed, and have sufficient coverage
- Ensure the code addresses requirements/bugs
- Ensure adherence to coding guidelines (I don't like coding guidelines, but most teams do)
- Ensure documentation is present, if needed/required
A code review should not take long, and the purpose is not to find bugs.
> Code review should still happen here, just independent of approval.
If code review is not necessary for approval, then for most engineering teams, it will simply never happen.
For the lowest risk changes in terms of review comment activity, that appears to almost already be happening.
Building upon Microsoft's earlier analysis (https://pdfs.semanticscholar.org/c079/0dc547c56ca48b78bc418b...), our data, which is composed through an objective risk measure, confirms similar findings about code review efficacy w/r/t finding bugs.