Hi! My name is Viacheslav Aksenov, I have been doing backend development on large and small projects for quite some time. All of these projects have had code reviews in one form or another. I managed to get acquainted with completely different approaches to code review - from the most relaxed and free, to super detailed and strict.

Thus, the purpose of this article appeared - why do you really need a code review and how to conduct it correctly?

What is a Code Review?

As a process, code review is when one developer reviews the code of another team member before merging the branch into main. As a rule, the code review takes place at the moment when the pull request in main is ready and it is carried out either by a team member of the same experience or a more experienced one.

Why Do You Really Need a Code Review?

Depending on the structure of the team’s work, fixed guidelines, there may be several goals for a code review. Let's look at the most basic ones:

The most obvious: do not let problematic code and code that does not comply with the team's conventions into the code base.

For example, there may be agreements on code design that cannot be caught by statistical code analyzers. Or code that is syntactically written according to all the agreements of the team, but ideologically does something unacceptable

The second most obvious is not to release tasks with some obvious bugs caused by the developer's inattention to the test.

When a developer works on a task for a long time, his eyes may get lost and some simple bugs or a logical typo will pass by. It happens - a look from the outside easily helps to solve such a problem.

Involvement in the process - to be aware of what is happening in this part of the project, what tasks are being done, how the code base is replenished.

When the project is large, there are many developers, there is a situation - the business requires the solution of a large number of tasks by each developer. In this case, it is naive to assume that each developer will look at those parts of the project that he does not deal with. Code review in this case is a great tool to quickly get acquainted with new concepts that your colleague has made.

Culture of Code Review

In an ideal picture of the world - code review is a working tool that makes life easier for the whole team. For this to work, it is necessary that all members of the development team adhere to certain rules.

The review must be mandatory, otherwise it loses its meaning.

If some team members can merge any code without review, then there will be anarchy and frustration. If a review code has been entered, it must be required for all participants.

The review should pursue exclusively constructive purposes.

The task of a code review is to improve the code base, period. Humiliating a developer or making fun of mistakes is unforgivable.

As a rule, the time of the reviewer is more valuable than the time of the pull request author.

If the reviewer pointed out an error, the same error should not occur in the future. You need to be careful and keep in mind the advice that was given in the past.

Code review should be meticulous but not uncompromising

It is not enough to look at the pull request diagonally. It is necessary to understand what exactly happens in it - in each line of code. After the review, the reviewer should not have incomprehensible places in the logic.

If something goes obviously wrong, it should be highlighted. However, at the same time, one should not cling to trifles and, for example, present one's personal opinion on the name of a variable as the only true truth.

If there is a personal position that has not been discussed anywhere, you can either bring this item up for discussion by the whole team, or offer your opinion to the developer as advice. But do not require him to follow the personal thoughts of the reviewer without reason.

Additional Tips

Without the points described above, it is impossible to present a competent review code. The following are purely advisory in nature. Following them will only help make code review a more pleasant procedure.

Be polite. It is unpleasant for everyone when I criticize the work done in a rude manner. It's the same with code reviews - instead of rude comments, write something soft, but that will convey the whole point.

Be short and concise. If not required, but you can not paint many lines in one comment. A short comment and a link to the rule in the team's general convention is enough.

If the level of the developer is much lower than the level of the reviewer, then try to teach the developer something new using a specific example. For example, “this method can be written more optimally like this”

Be responsible and bring up controversial issues that are not described anywhere for a team discussion. In order to develop a solution in the future that will suit everyone and will no longer raise questions.

Conclusion

This article discussed the code review process, its main details. And also advice is given on how exactly the code review should be carried out so that it is really useful and effective. I would be glad if my article helped someone, write your tips on code review in the comments. Thank you for your attention!