Review code (CR) - for some people unnecessary nightmare, others will say that it slows down the development process. In each of these statements, there is a grain of truth and, unfortunately, negative truth. And what if I told you that CR can be a source of knowledge, team motivation and accelerator of the application development process?

For those really uninitiated, a very simple definition. Code review is a process aimed at detecting errors made during software development, which improves the quality of the product being created.

In this article, I am going to focus more on the theoretical and psychological side of the issue. The technical part will appear in other articles.

Why do this?

The main purpose of browsing code is to draw attention to its quality. It is extremely important to be consistent with generally accepted or internal standards. Thanks to that, the new person who will join your team will feel that the code was written by one person. Such code is then easier to maintain and modify. I don't mean good editorial standards here, because ESLint should do it for us. We should focus on architectural aspects, code structure and design patterns used, its readability and performance.

In my work, I often come across unreadable code. I do not want to talk here on what it means that the code is readable or not, but I refer to the great book by Robert C Martin "Clean Code". I will briefly say that if you can't read what the line is doing, it means the code is too complicated.

The second very important aspect is finding possible errors. This task presents a difficult challenge for code reviewers. Finding errors by looking only at the code, you need to have extensive experience and a lot of practical knowledge. This is a difficult task and is not always successful. Even the most seasoned eye will sometimes not see hidden errors. How to protect yourself against such a situation? You need to accept the fact that you won't pick up everything. Errors should also be caught by automated tests and that's what developers write them for.

To sum up this part, I think that the first aspect is more important - structure, architecture and broadly defined code quality.

Psychological aspect

Every artist, craftsman, and here I will put a programmer on an equal position because I think they are such a modern craftsman, trying to make his product of the highest quality. Therefore, he often identifies personally with his work and is associated with it emotionally. When you are doing someone’s code review, you must remember that you may offend them accidentally criticizing they work.

Let's put ourselves in the role of a software developer. We tried to do our job as best we could and now someone criticizes us and thinks that our ideas are bad. How to find the border between the viewer and the creator so that everyone understands each other well. More on this later, but here is my advice. When you write a comment to someone's code, try to make it constructive and assertive. Using wording that this part of the code is simply bad or you can’t program like that is not a good comment. Justify why something is bad and suggest how to do it differently. Post an interesting article on this topic to broaden knowledge. Then this person reading an additional, outside opinion on a given topic will understand that they have misinterpreted this part of the code and will also have the satisfaction of learning something new. 

When you are the creator of the code, put pride in your pocket and do not treat it as an attack on you because it is just code. Check what the reviewer wrote and if he was right thank him for teaching you something and if you disagree with him let it be constructive, support yourself with articles or examples.