Code Reviews
Code reviews are a common practice when writing software. A lot of advice says a primary benefit of doing them is reducing or preventing bugs.
I disagree.
This is after many years of experience, from over-the-shoulder code reviewing to using GitHub, GitLab, Bitbucket, and Swarm (Perforce). On small teams and large teams. I’ve seen too many obvious bugs go undetected by reviewers, especially me!
Good design, style standards, and tests reduce and prevent bugs. So what are code reviews good for?
Sharing knowledge. It’s like when Batman whispers to Jim Gordon in Batman Begins, “Now we’re two.” Someone else is aware of changes to the code. When something goes wrong, there is more than one person familiar with it.
Leave the style suggestions and code coverage checking to automation. Architecture and design choice feedback should come earlier than a code review. Sure, you might spot a few things, but don’t depend on this step to catch bugs.
Plus, the more folks that know about more of the code, the more readily they can help debug it.