Don’t skip the code reviews!

Published in

UFG news

5 min readJun 4, 2021

Code reviews are essential part of software development lifecycle in medium-to-large sized tech companies. But what about smaller dev teams? Is it worth the time investment?

Time management problem

Code reviews are adding the extra step into your release process. Depending on where you place it in the process, it can create problems with context switching for your developers. Most common usage is to do code review when merging a feature branch into the main branch of your codebase.

This creates a problem in time management for both author of the code and reviewer. Should developer wait for the review and thus avoid switching context between tasks? This would be the optimal scenario but the one that is not often possible in reality. Because the reviewer usually works on his own task. There is no solution for this problem unless you have dedicated code reviewer on your team waiting for incoming code reviews. But such role does not exist in most of smaller dev teams.

You should create an internal rule for prioritizing code reviews. The usual way to go is something like:

If there is a code to review waiting for you, do it as your next task, right after you finish your current one.
Check the code reviews as the first thing of your workday.

Using these rules, we ensure the developer receives the review next workday at latest and he can plan his tasks accordingly.

What are the advantages of code reviews?

The most apparent reason to do code reviews is to minimize the possibility of easily spotted errors getting into your codebase. Nobody is perfect. Another pair of eyes checking the code helps avoid obvious mistakes. At the same time it can help your codebase to stay consistent coding-style wise. Sure this can be done by using automatic tools too but not everyone uses them (we will get to this in one of the following articles).

In my opinion, one of the most important advantages and the one that is often overlooked, is that by doing code reviews, there is constant learning in your dev team. Both creator of the code and reviewer can learn a lot from the process of reviewing code.

So improving your codebase and your developers at the same time, while creating the mechanism to reduce errors in production? What are you waiting for? :)

What should be reviewed?

There are plenty of things to check in the code reviews. I recommend writing your internal checklist to make sure reviewer doesn’t forget anything.

The key is to keep code reviews small. The code to review shouldn’t be much longer than 400 LOC (lines of code). Longer code reviews take too much time and it is much more difficult focus on the changes in the big picture. If the task requires more LOC, try to divide it into subtasks. You can then do code reviews on pull requests of subtask branch into the main task branch.

We decided to cover these points while doing code reviews:

Correctness of the code
Find hard to understand code
Unclear names
Unnecessary comments — commented out code
Unhandled edge cases

We are not focusing on coding style, because automatic tools do that for us. The one thing that is very important, but also very difficult to review, is how well do new changes fit in the codebase. Do they follow the architectural design of your application? Do they break any other part of your application? Being able to look on the code review from this perspective is difficult, but it can keep your code base healthy.

Who should be the reviewer?

Everyone in your team. Really, even the junior developer, who just started working in your team yesterday. As mentioned before, reviewer can learn from code reviews. In case of junior developer, he will learn about your codebase by reviewing it. At the same time he can spot those obvious error in the code of more senior developer. If you are not sure if such code review would ensure the quality check you need, you can assign another, more experienced developer, for the same code review.
For managing developer or technical team lead code reviews can be the way to stay in contact with the codebase. You can still pass your experience to your developers by tweaking their code using code reviews!
Create a mechanism, where everyone does the code reviews and there are no constant pairs of developer and reviewer. In other words, create as many possibilities for developer to read code of another developer as possible.

How to write good code review?

When you study existing resources regarding code reviews, you will find out that lots of them are dedicated to the following problem. How to write code reviews that would not offend the creator of the code. First I found it kind of funny. Then I remembered few past experiences when it was apparent that developer took criticism of his code personally. It is not difficult to imagine why. Code is, in a way, result of creative work of one’s mind. So think about it when writing code reviews.

We identified few rules to help with writing code reviews:

Ask open-ended question instead of making strong statements. — Write “What do you think about the name ‘userId’ for this variable?“ instead of “This variable should have the name ‘userId’.“
Offer alternatives that might work better for the situation.
Assume you might be missing something (context) and ask for clarification instead of correction.
Don’t be afraid to applaud nice solutions in code review.
If there are too many questions to be clarified, set up a call. Make sure to create a written report from such call.
Use I-Messages — Write “It’s hard for me to grasp what’s going on in this code.” instead of “You are writing cryptic code.“
Talk About the Code, Not the Coder — Write “This code is requesting the service multiple times, which is inefficient.“ instead of “You’re requesting the service multiple times, which is inefficient.“

If you still have questions about code reviews and how to implement them in your development team, feel free to ask anything in the comments. Or google it, there are lots of articles about how to do the reviews properly.
Implement code reviews now. Thank me later.