5 Tips for a good code review

Code review is one of the most valuable engineering practices.

1. Code reviews improve code quality: one head is good and two is better.
2. Code reviews are a great tool for developers to learn about the parts of the application that they can follow.
3. Code reviews help you learn best practices from other developers.
4. Code reviews can be used to check the clarity and simplicity of the entire application.

As you may have noticed, I did not mention in this list that conducting code reviews helps to find errors and comply with coding standards, and here is why:
')
1. Code reviews MUST NOT be conducted in order to find errors.
2. Code reviews MUST NOT be conducted to verify compliance with coding standards.

10 years ago, these two points would make sense in code reviews. However, you should now use automated testing tools and code tracking tools. This does not mean that at the time of the review you should not notice coding and design errors, it means that finding them is not the purpose of the code review.

From this perspective, let me give you 5 tips for a good code review.

1. Conduct code reviews frequently.

In my work there were cases when I suffered from the fact that the review of the code was carried out too late. I worked at a company where a large-scale review of the entire application code was the last stage of development. This was completely useless, since later reviews of the code have the following disadvantages.

• The more code you need to view, the greater the likelihood that the developer will not agree to subsequent refactoring.
• The longer the developer is engaged in some part of the code, the more likely it is that the site becomes “personal”. I would like to remind you that one of the main problems of developers is their ego. If a developer has written code that works, then despite the fact that this code may be bad, the programmer ego will resist any suggestions for improving the code.
• The closer the release date, the less priority will be to work on improving the code.

Personally, I review the code every time after I finish writing something non-trivial - usually several times a day.

2. Make reviews quick and informal.

Forget about the lists, just turn around and ask someone from colleagues to give you 5 minutes. If you have a list, then something from this will happen:

1. During the review, only what is listed on your list will be viewed.
2. Code reviews will turn into a formality. People will have less time to look through the code and pretend that they really need it.

Short and informal reviews are essentially dialogues in which a person does not feel that he is being reviewed, rather he is simply advised.

3. Conduct code reviews with different people.

If possible, ask different people to see your code. There are three main reasons why a new person should be asked about this each time.

1. It is useful to hear different points of view.
2. In the future, your code will be able to accompany more people.
3. Increased teamwork.

4. Tune in a positive way.

Remembering that one of the main problems of the developers is their ego, a positive attitude will help you make the reviews more enjoyable, and all participants will more likely agree with the changes suggested during the reviews. And remember: you are not your code!

5. Learn to enjoy the reviews.

This is the most important tip. If you work in a team in which people like to conduct reviews, then everyone will be involved in writing code that is pleasant not only to the author, but to the whole team.

__________

In the comments you can share, do you conduct reviews of the code, how do you do it, is there any interesting experience, etc.