The first part of practical tips for effective code inspection was written more than two years ago, but has not lost its relevance. This article contains some more tips that can improve the effectiveness of this complex and responsible practice. In short, the inspection should be carried out quickly, talk about them, visualize and not try to grasp the immensity.

In the rhythm of the waltz

Inspections should end quickly. A completed inspection is when the entire code is inspected, all defects found are corrected, and corrections are checked by the inspector. If the inspection lasts a long time, the following problems arise:

• It is difficult to understand who does what.
• Developers will defocus, that is, several inspections and tasks on which they work appear simultaneously, which leads to a deterioration in productivity.
• Inspections become irrelevant, that is, one code was issued for the inspection, but in the version control system it is different.
• Inspections become defocused. The longer the inspection goes, the more the inspected code gets corrected, the more difficult it is to conduct the inspection.

If the inspection lasts more than three days, then something is wrong with it - either someone delays or tries to embrace the immensity.

Embrace

Sometimes the inspector sees that a task of this kind has already been solved several times, and if some refactoring is done, similar tasks could be solved much cheaper. As a result, there is a dilemma in front of the inspector: either to write a remark within the inspection framework that refactoring should be done, or not to write, since refactoring can be time consuming and unplanned.
')
On the one hand, the remark must be recorded, since the understanding of the need for refactoring is a useful result of the work of the inspector, which must be preserved. In addition, if you do not perform refactoring, then we will continue to waste efforts when performing the next similar task. On the other hand, if the inspector leads such a defect, another problem will appear - very long inspections. The way out is to create a new refactoring task outside of this inspection. That is, it is better to start heavy defects in the form of a separate task for which a separate inspection will be created. An approximate assessment of what a “serious defect” is is a defect that needs to be spent over two hours to correct.

Better to hear once

Nothing replaces live communication. There are objectively complex tasks that have complex solutions. In this case, before conducting an inspection, the author can live and tell the inspectors a solution using his fingers, IDE, pieces of paper, or a board with felt-tip pens. And in the ideal case, the author will do it before the implementation of the decision, although it is better late than never. But there is a danger here - you shouldn’t try to fix the poor unreadable code with verbal explanations. The code remains bad, even if everything was told in detail about it.

By the way, sometimes it is useful to invite testers to such stories. Knowledge of the implementation details will help them test better and find non-trivial errors.

Visualize it

Code inspection is an important phase in the life cycle of a task, along with development and testing. If you are using a scrum or canban board, then it makes sense to select another column for the inspection phase between the “under development” and “ready for testing” columns. In this case, the board will more accurately reflect the real state of affairs, which is what is required of it.