7 How code reviews can suck
This chapter covers
- Common pain points that can pop up in a code review
- Some real developer stories of code reviews gone wrong
Imagine being on a team of five. You’re working on a relatively straightforward, monolithic application. Unfortunately, everyone is pushing their code to the main branch whenever they complete an assigned feature (or worse, whenever they want). You’re stepping on each other’s code, introducing varied naming conventions, overwriting and probably duplicating code, and much worse. It’s the wild, wild West, and it’s what having no code review process can feel like.
If you’ve worked on a team that did not have a code review process in place (or some quality checks as part of a CI/CD pipeline), you have probably experienced these pain points first-hand. A lot of time is wasted fixing things that shouldn’t have been deployed into production in the first place. It becomes nearly impossible to revert to a good, working version of your application. And when those random bugs surface from the legacy code? You automatically multiply your story point estimate to resolve them since the code is quite cryptic—and, of course, the developer who wrote it is no longer here.