[sorkarhira]

Code review is inevitable. Therefore, it is necessary to prepare for it... a little in advance. Perhaps even a couple of years in advance. In general, this article will be useful for both those who already check other people's work and for young specialists who have Code review ahead. Last year, Google shared their own experience, which will be briefly and adaptedly presented in this article.

Remember your true purpose
Code review is done to check the code, fix errors in it and improve it, and not to hurt your colleague. Also, if you have to evaluate the code that is part of a large and multi-level project, do it from the position of the entire system, and not the part that was provided to you.

Remember: you are only an evaluator.
And not website development service a great guru or a master of destinies. Therefore, evaluate both the code and your criticism sensibly. Try to be adequate, correct and polite in your wording, otherwise there is a chance that the developer will be disappointed not only in himself and his skills, but also in the profession.

On the other hand, don't let problems accumulate. A hack can go unnoticed and generally not spoil the product at all if there is only one of it. At best, one and a half. But when the application is overflowing with problems... Don't do that.



Feedback
Be sure to leave feedback after checking the code. It is best not only to politely point out the errors, but also to explain how to fix them and why they appeared in the first place. This is necessary so that the developer can make the code better next time and, moreover, independently.

Google also recommends using the prefix "Nit:" (from the word "nitpicking") when writing recommendations. This is not necessary, "Nit:" is simply a universal mark that in most cases you will not have to explain to other people (and it is also easier to search the log by it).

Here are some tips on how to write comments after a review:

imagine a waterfall. Great. Now start writing, remembering that you and the code creator are not enemies, but colleagues. And you solve one problem: be kind and tolerant. After all, everyone makes mistakes;
If you give any instructions, explain them. It looks less harsh and rude, and will also help the programmer understand what is wanted from him;
explain, but do not do all the work for the coder. It is his code, at least because he will fix everything better and more accurately. Especially if this is a full-time and permanent employee - he needs to understand the error, learn how to write code so that this does not happen. Therefore, it will be better for him to fix everything with his own hands (except for very sad cases, of course - if everything is bad with the specialist, change the code yourself);
If the code is very cumbersome and cannot be simplified, suggest that the developer add detailed comments to it. Explain their necessity so that the person does not perceive the request as a desire to load him up as much as possible and make fun of him;
Stick to your team and company standards. If a coder complains about being picky, tell them they should have known what they were getting into. The main thing is that neither of you goes overboard with this;
If a programmer offers you to accept a job on the condition that he will finish it later, unofficially, do not agree. The cake is a lie. At least in 9 out of 10 cases.
Anyone can offend an artist
If you do end up in conflict with an employee, try to find a compromise by all means possible. To do this, put your emotions aside and suggest that your developer do the same, refer to the project standards. Talk in person or via video link, this way it is usually easier for people to understand each other.

If none of the above helps, involve experienced team members who are not involved in this task in the discussion. However, do not get carried away, because the developer should not wait for your or their answer for too long. This not only has a detrimental effect on the work, but also significantly reduces the level of motivation of the programmer, his loyalty and involvement in this project.

So what is there to check?
Everything.
Every line.
The entire code: from start to finish.

And now the list:

The overall structure and whether the code fits into the current project.
Functionality, namely whether the assigned tasks are closed using this code.
Ergonomics: UI and compliance with the overall style.
Multithreading - code should not conflict with other elements of the code base when executed in multithreading. Code should not conflict at all: neither externally nor internally.
Laconicism, including in the literal sense. The code should not be ultra-complex and large. If something can be simplified, do it, if such actions do not harm its functionality and quality as a whole.
Potential for scaling, if you notice something in the code that could be used in the future to optimize or develop the product, tell your developer about it and praise him.
All existing tests, including integration, unit, etc., should also be analyzed at least for errors.
Code compliance: style and architecture. This is covered in more detail in the next section of the article.
Code Clarity: Check, double-check, double-check that all fields, functions, and variables (and everything else) are clear, unambiguous, and don't require additional explanation for a hypothetical replacement for the person working on the code.
About the eighth point
In addition to errors that cause the final development to function incorrectly, attention should also be paid to the style and architecture of the code. The former should correspond to that adopted in the team or company. If this aspect was not discussed with the developer, there is no need to ask him. It is not his fault that he does not read other people's thoughts.

As for the architecture, it should be in harmony with the principles on which the development as a whole is based. If you notice an error and see a solution that will correspond to them as much as possible, you can recommend it.

To prevent possible difficulties in discussing these aspects, show the developer the code base. This should be done before the person starts working. And only if familiarity with the accumulated materials will not negatively affect the result (copying, attempt to imitate someone else's and unusual style, etc.).

That's understandable. But what to do?
The optional but desirable sequence of actions is as follows:

Before you start evaluating the code, remember what the development is and what the coder is trying to do. Does his work make sense, or is he trying to do something wrong? In that case, he will need to be coordinated.
Study the main part of the code being checked. If it is not entirely clear to you what is the main thing, ask the programmer. Check the highlighted parts for errors and shortcomings. If you find any, tell the developer about them immediately. As for the details: there is no point in moving on to their assessment until the main problems are fixed. At the very least because in the process of eliminating the main errors, these same details can undergo major changes.
Study the rest of the code. Remember the logic and linear sequence of actions. Test everything. In general. You can resort to creating unit tests to have an idea of ​​what changes the programmer is planning.
Recommended by Google
Don't delay Code Review. React to the finished code and its corrections immediately, suggest small changes that affect the quality of the code, and monitor the coder's corrections.

In this case, try to fit it into one day (taking into account the developer's time zone). However, if you are focused on another task at the moment of receiving the code, first close it and only then proceed to checking. Otherwise, there is a high probability of doing two things poorly at once.

Strive to work faster, but never take actions to the detriment of the idea and quality.
_________________
website development service

[Reklama]