Code Reviews – The secret of MobiMedia’s quality

Code Reviews – or: Let´s talk about quality made by MobiMedia

MobiMedia is doing manual testing of its software since the beginning. Over the years we also worked more and more with automated testing (unit tests in the beginning), up to completely automated UI tests, which simulate the user interaction of the software to guarantee that everything is still working after every code change.

However, this post is intended for another important topic, that turned out to be very valuable for us as developers and as a company over the last couple of years. Code reviews are an adapted working process where the developer doesn’t just publish his code changes, but they are first being checked by another developer (the “code reviewer”). The code reviewer can make comments and suggestions, and in the end approve or deny the code change. When denied, the original developer has the possibility to improve his code based on the comments by the code reviewer and apply again for code review. This cycle can repeat itself multiple times until the code reviewer approves the code change and practically both parties are pleased with the changes.

When we didn’t do code reviews before, our error rate was higher and the code quality was inferior. We had more isolated separate solutions because the developers only solved the problems in their project, even if we had similar solutions in other projects.

Today, many problems are found, even before anybody starts the software for manual testing at all.
Just because of the additional checks we do from the code reviews. Interestingly, the code reviews were accepted in the team and in the company early on. Today, they are a largely accepted working process, like the programming itself and doing tests of the software.

Code reviews also allow us to integrate new or inexperienced developers early on, and give them more complex work, because every change is still checked by an experienced developer anyway. Additionally, code reviews solve the problem of sick days and holidays, because we have always at least two developers who know about any change. For larger teams the developers can review their code with each other, which improves team communication and problem solving.

We are using a software named “Phabricator” to apply the code review process. This allows us to even define multiple code reviewers for a change. In this case multiple developers have to approve a change before it gets published. This makes sense for more complicated code changes, and it spreads the responsibility over multiple shoulders and minimizes the risk of problems even further.

The single disadvantage of code reviews is the increased time and cost investment, because at least one second developer has to check for code changes. For more complex changes, this can lead to delays up to one or two days, if the code reviewer himself has limited time.

In the end, code reviews improved one thing at MobiMedia: the team work in the development department is stronger than ever. We communicate more, criticize together and solve problems together. This leads to a better working environment and for a better software quality.

Author: C. Zeller, Head of Development Department MobiMedia AG