Code Inspection. Results

Code inspection is good. We use this technique in our projects not so long ago - about three months - however, there are positive results. We already told on Habré about the implementation of inspections in the development process , about the document circulation during inspections , and how to optimize the inspection process using the Code Collaborator tool. Today we want to take stock and present the results that we were able to achieve during the inspection. Go!..

In fact, there are a lot of advantages, so in this topic we will touch on only a few basic ones.
')
The general style of writing code has been established . Of course, even before the introduction of inspections in our team, there was some idea of ​​what is good and what is bad, which everyone tried to adhere to. However, thanks to the inspections, the overall style was finally sharpened and virtually “entrenched in the head” for each developer.

The bike park is replenished more slowly . There are less and less situations that “I have come up with a brilliant solution,” and more and more often we use proven solutions from third-party libraries. An interesting effect of “collective knowledge” emerged, when one member of the team knows something about a separate library that others do not know, and suggests making optimal use of its best qualities.

Improved overall ownership of the code . There was more live communication on various aspects of the project: why did they do it this way and not in a different way? maybe should do like this? As a result, an understanding of how the various parts of the system work has become evenly distributed among the developers, and not concentrated on one person.

Exchange of experience and knowledge intensified . Now we often use in the development of successful methods and practices of colleagues implemented in other parts of the system. Such an experience, in our opinion, can only be transmitted through reading someone else's code: there is simply no other way. Any method must be “lived through” by oneself, only then can it be made “one's own”, mastered. For such an “immersion”, there is nothing better than a good example of someone else’s code from a familiar domain: this is much more efficient than abstract geometric examples of the shape, circle and box type.

The codebase has become more "accompanied . " Here is a list of improvements:

• magic constants are blocked by verifiers;
• decreased code duplication (DRY);
• algorithms have become simpler (KISS);
• documentation of classes and public methods has improved significantly (almost every public class and method requires inspectors to add documentation);

The only drawback to implementing code inspections is an increase in development time. At the initial stage of implementation, the time increased by 50-100% (sometimes it happened more), but as a result, in the general repository there was much less poor-quality code, less “slag”.

At the moment, after the initial debugging of all processes, the additional time costs have been reduced to about 20–50%. The main surge is associated with the adjustment of the team to the overall coding style; It took a lot of time to adopt common practices and methods. For experienced teams, in our opinion, the normal average increase in development time is 10%.

Checklist

This term is often found in the English literature and means, in essence, the inspector’s memo - a list of test questions to facilitate the inspection process.

It is better to create a checklist for each project and for each team, since it can vary greatly depending on the platforms used, libraries, and architectural solutions. At the same time, the list evolves over time and begins to more fully respond to the current project tasks.

Summarizing the accumulated inspection experience, we began to understand how to make a checklist. This is what our list looks like at the moment.

Checklist - a reminder of the Positive Technologies inspector

1. The correctness of the implementation of the subject area.

• The functionality is implemented in full.
• Compliance with specifications.
• The fidelity of the given constants.
• Justification of accepted assumptions and agreements.
• The correct sequence of processing.

2. "Readability" code.
Here you need to ask yourself the main control question: “Will I be able, if necessary, to add a new feature or fix a bug in the inspected code?”. The answer should be positive, otherwise the author should change the code.

3. The presence and completeness of the test coverage.

• All public classes and methods are tested.
• Boundary conditions are tested.
• Sufficiency testing "positive branches" of execution.
• Sufficiency testing "negative branches" of execution.

4. It is worth adding to your piggy bank good practices from someone else's code.

5. The correctness of the multithreaded code.

• Access to shared data is synchronized.
• Missing deadlocks.
• For synchronization, the idiom RAII is used.
• Correctly handled the return of resources in error handlers.
• No resource leaks.

6. The code handles possible errors correctly.

7. Lack of visible undesirable side effects in other parts of the system.

8. The correctness of language constructs.

• The correct idioms of the language and framework used are applied.
• Use correct libraries.
• The lack of newly invented "bikes".
• No duplication of code.

9. All variables are initialized with the correct values.

Perhaps our checklist will help you make the right one for your project.
It should be noted also one more very important point. For projects that do not have unit tests, inspection is, by and large, the only effective method for preventing defects in code. At least nothing else comes to mind. Therefore, if there are no unit tests in your project, first of all, inspections should be introduced and then the practice of writing unit tests should be implemented.

So why are inspections so effective? It often happens that when designing or working with the code, the developer at some point “blinks”, the mind is firmly attached to a specific design solution or a specific code fragment. Inspection is a simple way to reach out to collective intelligence, which is more flexible and free, on the principle of “two heads better.”

Thanks for attention! We wish you a pleasant inspection :)