The benefits of Code Reviews

Introduction

Code reviews, despite the many benefits they bring, are sometimes treated as a necessary evil. Programmers are convinced that this is unnecessary worktime, which extends the delivery time of the product, and that it is an unpleasant duty to look at a huge amount of unintelligible changes or unpleasant comments.

However, if the reviews of the code are approached in a good way, they become a powerful tool not only improving the quality of what we produce as developers, but also reducing the number of errors occurring in later stages of product development. Remembering a few simple rules during the review, we will feel their value and the actual improvement of the quality of our work.

Why should I do it?

Software developers will find many excuses for not doing code reviews. The most common would be lack of time, or boredom. But the benefits of reading your co-workers’ code are undoubtful, and the three most important would be:

• finding bugs – we all know that tests are very important in our code verification, but do we realize that reviewing of our code will also decrease the number of bugs shipped to releases? When we write the code we can easily be fixed on our ideas or mindsets, and to have another person’s view can be really eye-opening,
• code quality – having many people work on the same part of the code will simply make it better. With an exchange of ideas we will achieve a sort of synergy – the end result will be even better than just the simple sum of code parts,
• knowledge sharing – every developer has some knowledge and experience in code writing. One of the fastest ways to share that knowledge would be through pair-programming, as a part of the code reviewing process. Whether it is a single not so common method in java.util package or a new framework – every single tip will help you improve.

How can I do it better?

Now that we know that code review is important, we need to do it right. Below you will find a few tips, which could be the most beneficial, but feel free to add your own:

• code style – having a common, coherent code style will help you avoid meaningless discussions about white spaces or semicolons. There are a lot of ready-made code styles which you can import to you favourite IDE. Google has a set of such code styles (https://github.com/google/styleguide),
• small changes – the more changes there are in a single review, the fewer tips you will receive. The developer will be more eager to review your code if there are 7 files, than if you send him the result of a week’s work with 40 files. If you develop a single feature for a whole week, provide changes to the review in small patches once a day, or even a few times a day. It will be significantly easier to read them,
• sample code – most tools for code review provide us with an easy way to include samples of codes, be it in comments among the lines of the code or even in big code snippets. If you present a code sample to your fellow-worker, he or she will have much easier time understanding your approach,
• explain why – be explanatory in you comments. Writing “Fix it.” is not only impolite, but it provides no information on what’s wrong, or what can be improved,
• go and talk – in some cases we can save a lot of time by simply walking to our colleague’s desk and discussing a part of the code. Don’t create a ten-pages-long discussion in Crucible that will last for days or even weeks. Just simply go and talk.,
• only good vibes – never use code reviews to release anger or stress, or to show you superiority. Everyone makes mistakes, and even if you find one in someone else’s code, you can write about it in a polite and nice way. And remember to write something nice or complement a good piece of the code – code reviews are also about encouragement,
• integrate in process – it would be easy to forget about reviewing a code, if it isn’t a part of you everyday’s work. Make code reviews mandatory: create git hooks to report them, block deployments without code reviews, force code review tasks – there are very many possibilities to make you get used to code reviewing.

Any software?

To make code reviewing more pleasant and easier we can help ourselves with many tools available on the market. Some of them are free, some will require money investment. It might be a good idea to search and compare them before we make the final decision. Below you can find a few of the most common tools available, but of course there are more:

• Gitlab – apart from Github it is one of the most common tools for storing and sharing  any source code. It is based on Git,
• Crucible – originating in Australia, Crucible is a tool from the Atlassian company. It has many helpful features for reviewing the code, and it very easily integrates with JIRA – another very common tool in our everyday’s work,
• Gerrit – coming from Google, this tool might be the best option if we need to rely on open-source community,
• Phabricator – this tool will work with Git, SVN or Mercurial. Its origins are in Facebook.
  

Summary

Among many tools we use as developers, code reviews are really powerful ones. They can be used on every programming language, in every office, by anyone. You don’t need to spend many hours on learning them from books, testing them on strange compilers or platforms. You know how to do it. “Just do it”.