Code Reviews Are Not Effective at Finding Bugs(shepherdly.io)
shepherdly.io
Code Reviews Are Not Effective at Finding Bugs
https://www.shepherdly.io/post/code-reviews-are-not-effective-at-finding-bugs
8 comments
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.
Not an unreasonable thing to say. I did provide data to back up my point of view so folks are at least free to disagree on the details rather than just the high-level 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.
- 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.
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.
[deleted]
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.