Code inspection is a very complex and demanding task that can consume a lot of resources. It is important to conduct inspection responsibly and conduct it effectively. Effectively means spending little time and finding a lot of defects. But how to increase efficiency? Below are a few tips to help with this.

Cutlets separately, flies separately

Often, when modifying a code as part of working on a task, it comes to the realization that this code should be refactored first. It is not necessary to include refactoring and task implementation in one inspection. They should be divided into two different inspections. This is necessary to simplify the life of the inspector and increase the chance of finding errors for him, because if you combine a module with potentially dangerous changes with one 100 modules that have been modified using an automated refactoring tool (for example, renamed the class), then there is a high probability that the inspector will miss potentially dangerous changes.
In other words, it is not necessary to combine in one inspection solutions of different tasks. Refactoring is a separate task, even if it was the result of working on another task.

Boxing by correspondence

Many tools that automate code inspections allow you to leave comments on the source code and defects (for example, Code Collaborator). At the same time, there are often heated discussions when the inspector starts a defect, and the author begins to explain to him in the comments that this is, in fact, not a defect at all. As a result, a holy war begins, which can last indefinitely. To avoid this is very simple: you do not need to leave comments at all during inspections. In this case, the inspection process proceeds as follows:

1. The inspector starts a defect.
2. If the author agrees with the defect, he corrects it, after which the inspector closes the defect.
3. If the author does not agree with the defect, then he verbally discusses this defect with the inspector. No comments are added to the defect.
4. If the author and the inspector have successfully agreed, then, depending on the arrangements, either the author corrects the defect or the inspector deletes it.
5. If a holy war has begun, in which neither of the parties is willing to yield, then an arbiter is called to help, who will judge the inspector with the author.

')

And what are you doing here?

Before conducting an inspection, it is imperative to ensure that you understand exactly the problem being solved by the code being injected. It sounds like another captain's revelation of Evidence, but practice shows that often the inspector mechanically does his job, looks at the observance of formal stylistic requirements, without delving into the task. The code can be as “beautiful” as you like, have all the characteristics of SOLID, handle all possible errors, but if it does not solve the task, then this code is suitable only for demonstration at the next interview.

How disgusting is your fish!

Before the inspection, while the view is not zamylen, think about how you would decide the task? If you suddenly find that your decision is significantly better than that provided for an inspection, feel free to state this to the author. Let him fix it now, while it is still not so expensive and it is not crushed with crutches.

The taste and color of all markers are different

When making defects hold yourself in your hands and do not roll down to taste. Taste leads to conflicts, wasted time on holy wars and is not constructive. It is very easy to avoid it: before starting a defect, you need to prepare a set of weighty arguments, why this defect should be corrected. Arguments like “I like it better” or “so more beautiful” are not considered weighty. If there are no other arguments left, then there is no need to create a defect, let the code remain in the "author's" version, even if you wrote it differently.

And if he had a grenade in his pocket?

Pay attention to alternative scenarios. Often the programmer focuses on the main thread of the program and forgets to correctly handle the alternative. You, as a person not immersed in the task, it is easier to replace a similar puncture.

About the benefits of smell

All defects have their own unique smells that help them to find great. The smells of architectural defects are well described in Martin Fowler’s book Refactoring, which is mandatory for any code inspector to read. But not only architectural defects smell, they also have algorithmic notes. For example, if a multithreaded code in a lock refers to another code from which callback can be made, or if several synchronization objects are used, then it smells deadlock. Smells of algorithmic defects are a good topic for a separate article.

PS: A very big request to share in the comments your experience of inspecting the code. What advice do you have for effective inspection?