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

In the rhythm of a waltz

Inspections should end quickly. A complete inspection is when the code is inspected, all detected defects are corrected, and the corrections are checked by the inspector. If the inspection takes a long time, then the following problems arise:

• It’s hard to understand who does what.
• Developers are out of focus, that is, there are several inspections and tasks at the same time that they are working on, which leads to poor performance.
• Inspections become irrelevant, that is, one code was issued for inspection, but in reality it is already different in the version control system.
• Inspections become defocused. The longer the inspection takes, the more inspected the code will receive corrections, the more difficult it is to carry out the inspection.

If the inspection lasts more than three days, then something is wrong with it - either someone is delaying, or trying to embrace the immense.

To embrace

Sometimes the inspector sees that a task of this kind has already been repeatedly solved, and if some refactoring is done, then similar tasks could be solved much cheaper. As a result, the inspector faces a dilemma: either write a remark within the inspection that refactoring should be performed or not write, since refactoring can be time-consuming and unplanned.

On the one hand, the remark must be recorded, since understanding the need for refactoring is a useful result of the work of the inspector, which must be preserved. In addition, if you do not refactor, then we will continue to waste our efforts when performing another similar task. On the other hand, if the inspector makes such a defect, another problem will arise - very long inspections. The way out is to create a new refactoring task outside the scope of this inspection. That is, it is better to start severe defects in the form of a separate task, for which a separate inspection will be created. A rough estimate of what a “severe defect” is is a defect that requires more than two hours to fix.

Better to hear once

Nothing can replace live communication. There are objectively complex tasks that have complex solutions. In this case, before carrying out the inspection, the author can tell the inspectors live and show the inspectors the solution with the help of fingers, an IDE, a piece of paper, or a board with felt-tip pens. Moreover, in an ideal case, the author will do this before implementing the solution, although it is better late than never. But there is a danger - you should not try to correct bad unreadable code with verbal explanations. The code remains bad, even if everything was told in detail about it.

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

Visualize it

Code inspection is an important phase of the task life cycle 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 “in 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.