Code reviews as one of the most important and fun team activities

I am a big fan of code reviews. All teams, I was a member of, practice code reviews and it is a very important part of daily job.

Why is it so important and how to make it fun?

The main purpose of code reviews is to find problems in the code earlier than it affects the system. It might be not only bugs, but also architectural or style problems. The advantage of that is very obvious. But what makes it even more useful and how to make it more pleasant routine?

Learning opportunity

Code review is a good opportunity to learn. Learning can be in both directions — for the author of the code and for the reviewer. Developers always aim to create the best code they can produce at the moment. So reviewer can find fresh ideas, new libraries or even new interesting coding style. For the author it is the other way around — reviewers can show the different point of view or propose different solution for the problem. Be open for comments, suggestions and also be able to accept others opinions. Without the dialog it is hard to learn.

Small pull requests are cool

Sometimes I open a pull request and see more than 50 files changed. The only thing I want to do is to close it and never open again. I was on the opposite side as well. Development touched more files than expected and it ends up in a pull request with too many changes. It is not fun and it is not cool. 10–20 files is the largest reasonable number to introduce a change or perform a refactoring. It is important to understand all the relations inside the pull request for the good review. This would take not too much effort and time. Small pull requests also bring benefits upstream. The team learns to make smaller changes, write smaller user stories and produce decoupled code.

Do not try to make it perfect

Do not try to make the code perfect with your comments. Let’s imagine we have a stars rank for the quality. 1-star is for the very bad code and 5-stars is for the code you won’t have any comments. Try not to push for improvements for more than 1 point. If quality is no so good — 2-stars for example, try to find the most critical parts and help author to change it to 3-stars. Next time that developer will not make the same mistakes and write at least 3-stars code. But there is a risk of damaging relations if reviewer insists on changing too many things. He might be never asked to review again.

Review the code, not the person

Sounds obvious, but we all humans and all humans are biased. I’ve seen many situations when pull requests comes and reaction was “Oh, again that guy”. Of course starting review with this introduction is not very productive. Always try to abstract from the author and look what code says to you. The same goes for comments. Do not ignore any comments for your code. Even if it comes from the most junior developer in the world. There is always a learning opportunity.

Ask instead of pointing

Sometimes I see comments in a form of statements. “This should be done like this” and “Do not do it here”. These comments could be valid, but bring incorrect messages. They sound like orders or a criticism. Rephrase comments in a form of questions or suggestions. “Maybe we can do it like this?” or “I would move this part to this file”. This technique helps to understand authors decisions and do not offend colleagues.

Be positive

Usually, comments are requests for changes or questions about implementation. But code also contains good names, nice data structures and beautiful problems solutions. Write about that. Put positive comments if you think something worth it. The author will be proud. Also, it creates positive enforcement and next time you will see more places like that.

These few technics only touch the surface of a good code reviews. It is a start for healthy collaboration. Create your own rules, technics and tricks. Share them with your team, and you will be very happy to review someones code and ask others to review yours.