The power of code review

Author: Magda Piechota

Developing products for clients puts an enormous responsibility on all of us at codequest. Our goal is to deliver the best product, look-and-feel-wise as well as the quality-wise.

And while the look-and-feel can be done with the client and users, assuring that our quality standards are met would not be possible without the proper code review procedure we use for all our projects — big and small alike.

What is code review?

Simply put, it is checking the code written by one developer by other developers, assessing it and giving feedback. The primary goal of code reviews is to ensure code correctness and quality. We also gain something as a by-product of the code review, and that is the knowledge our junior devs get with every code review they have done.

In our code review routine, we mix automated code review and manual code review.

The automated code review is good for the initial stage of reviewing as it speeds up the process by finding the common “code smells” (faulty pieces of code) quicker than a human.

We use code-reviewing tools that are available online, but seeing their shortages, we have decided to create our tool, codebeat, that would fill in the gaps and provide us with more reliable data. codebeat will be available in March, and you are most welcome to try it.

Manual review, on the other hand, takes more time, but is more thorough and gives better results. We use a pull request procedure, known to all the developers, to be sure the quality of the code we push onto production is verified before we push the code.

How does a pull request work?

This process is done quickly as we cannot afford to wait for reviews. We aim at a maximum 48-hour review time, so a hanging pull request does not halt the development process. And not only senior developers or team heads look at the PR, anybody on the team can do this and can add their comment. The discussion is always open. This ensures the best solution and code quality, as sometimes even junior devs can have adequate knowledge about a specific issue.

Such process ensures the code quality, open development process, and peer-learning within the team. And the rules are simple: collaboration (all team members look at the code), insight (no information is spared), safety (the code is kept outside of the master branch), branches (branches are good, but once you are done, you need to clean them).

The traps of the code review

Code review is not perfect. There are some traps developers and software houses may fall into when using the code review procedure:

All these are for real, and we also made these mistakes in the past. This is why we created a strict code review procedure and now are striving to create codebeat, a good (if not the best) automated code reviewing tool to speed up the review process without losing the quality.

We do believe code review is the key to a good quality code and a good quality product. And by mixing the automated code review with the manual one, and by keeping the procedures, we manage to achieve these goals without falling into the code review traps.