Higher Quality Work Through Code Reviews

Melon believes in the power of collaboration and that’s why we love code reviews. Code reviews help us build better projects and faster for our clients and in this post we are going to look into how we do that.

Before you bring a code review process into your team you need to think about what you want to accomplish with doing code reviews. At Melon, we use code reviews as an opportunity to share knowledge about how the application works through the team and to catch small mistakes or logical errors before they end up in a live environment. It’s been estimated that it costs nearly ten times as much to fix a bug in production than if it’s found during QA. Finding it in code review can save even more cost. For our clients this means higher quality projects at less cost.

Because we want to use code review as a time to share knowledge about how a change is implemented and to catch small errors, that means every change needs to be reviewed and everyone needs to participate in the review process. It can’t be based on seniority because everyone is capable of making human mistakes. Senior devs need their code reviewed by more junior members to catch these issues as well as to demonstrate how the code works. It’s an opportunity to clean up code which might have been overly clever and hard to understand. Junior members need their code reviewed as an opportunity to learn and grow through focused and clean feedback on their work. Having at least two developers look through every change means that there is never just a single person who knows how something works. If there are bugs or improvements that need to be made to this area in the future, there are multiple people who can do the work. With those future changes also going through review, the process of exploring and learning about the code base continues through the lifespan of the project.

To help prevent human ego and conflict from spoiling the code review process, we try to automate as many of the checks as we can. That means using a continuous integration (CI) service to run checks for code style/linting as well as running tests. We also use protected branches on Github to prevent changes from being pushed directly onto the main environment branches. Automating checks like code style and test coverage means that the reviewer doesn’t need to and shouldn’t nitpick style points. Running the test suite ensures that it passes but the reviewer can focus on whether the tests correctly enforce the logic and the task requirements. Code reviewers can focus on whether the code can be read and understood by another developer and whether it appears to fulfill the issue requirements. In our experience, a nice side effect of doing code reviews is that developers will start to write code which is easier to review. That means small changes, good tests, simply expressed, and self documented code.

Once you accept that we all have flaws and blind spots and embrace that your development team is there to help you cover those blind spots you can learn to love code reviews as well. We’ve found a way that works for us to help spread product knowledge throughout the team and find bugs when they are less costly to fix.