The practice of code review or, if translated into Russian, code inspections appeared long ago and has already been successfully integrated into development processes in many companies. The programming teams of companies such as Google, Square, Amazon, actively use it, and they do not even have the thought of abandoning it. At the same time, in a large number of companies this practice is either not applied at all, or applied from case to case.

The process of introducing code inspections in our team began a few years ago. Before reaching the current state, various approaches, techniques and tools were tested, a huge number of posts and books were re-read. The greatest benefit to us was the study of the experience of other teams (both positive and negative). This helped to determine the vector of development and to be prepared for arising difficulties. Now, I think, it's time to share our experience with implementing and using code inspections in application development.

Why are code inspections important?

Anyone involved in software development, without hesitation, will tell you that the cost of fixing defects in a product depends on the time they were discovered. The sooner we find a mistake, the cheaper it will be to get rid of it. Therefore, it is obvious that any practice that allows you to reduce the number of errors in the product is of interest to all interested parties: programmers, managers, customers.

At the same time, code inspection helps in training junior programmers. Due to their inexperience, they make quite a large number of errors in architecture, code, and comments. Therefore, it is very important to train them from the first day to follow the established rules regarding the writing of new code and a good tone for interacting with existing code.

Programmers, reading the code that was written by their colleagues, will inevitably get acquainted with him and with the tasks that he must solve. As a result, the team has increased code ownership. Developers are beginning to understand how application modules written by other people work. The probability of duplication of existing functionality (not code!) Is reduced. The risks associated with the departure or temporary absence of a team member are reduced. As a result, any developer is ready to perform even those tasks that affect not only his code.

In the case when developers know that their code will be viewed, they begin to write it more responsibly: they carefully consider how to integrate functionality into the existing architecture, add a sufficient number of comments, etc.

The arguments listed above are obvious, and usually no one argues with them. But, in my opinion, the most attention in code inspections are advantages that are long-term. Indeed, it is in them that the management team or the customer should be interested (in the case of custom development).

Firstly, if code inspection is not carried out, it is very easy to find yourself in a situation where the introduction of new functionality will cause serious problems for programmers. In turn, the customer will be perplexed: why does adding so little functionality take so much time? The answer is quite simple - no one watched the quality of the application architecture, its code and the changes made to them.

Secondly, it is difficult to navigate in low-quality code, which leads to the appearance of new errors both in places where old defects are fixed and when new functionality is added. As a result, the release dates are starting to move. Despite the best efforts of the testing team, releases still come out with defects. This, in turn, increases the load on the technical support service, which ultimately leads to dissatisfaction of users of the application.

Why are code inspections still not carried out?

Programmers, due to the specifics of their profession, are very smart people and can count. In particular, they count their time very well and monitor their productivity. According to them, code inspection distracts from current tasks and reduces productivity. Defects found during code inspection are also not of particular interest to them, because they are mainly a list of minor errors made by junior developers. Moreover, this list is consistently repeated, and its discussion is a rather boring process for experienced developers. A code inspection assumes that all defects found are corrected. However, there is a huge reluctance of programmers to make changes to the working code. Also, if code inspections are rare, then the programmer who was tasked with it, just lost in a huge amount of new code. And for him it looks like a punishment. These points do not motivate the team to conduct systematic code inspections. Programmers believe that the result obtained during code inspections is not worth the effort. This is due to flaws in the approach to conducting code inspections and unwillingness to fix them.

It was mentioned earlier that the customer should be interested in conducting code inspections. But, as practice shows, the application is primarily evaluated by the declared functionality and test results. Almost no one makes requirements on the source code and, accordingly, no one checks it. The question about the low quality of the code appears in two cases:

• when receiving a project from another team;
• with constant postponement of deadlines due to a large number of errors.

Unfortunately, it is too late to change something in these cases, but there are several options for overcoming the current situation. The first, obvious one is to succumb to the entreaties of programmers to “rewrite everything”. However, there is a chance to trust a weak team with unsolved processes and, at the output, again get another hash of code. The second is to analyze (inspect) the existing code and prepare a strategy for its resuscitation. This option is longer and requires a lot of effort from designers and developers.

Types of Code Inspections

There are several types of code inspections [1]:

• formal inspections
• over-the-shoulder review
• code inspection using e-mail (e-mail pass-around reviews);
• pair programming (pair-programming);
• code inspection using special tools (tool-assisted reviews).

In formal inspections, as a rule, the whole team is involved. This type assumes that each programmer will analyze the source code and prepare their list of comments. An integral part is the meeting, which discusses the defects found. The result of the meeting should be a list of further actions of the team regarding the errors found.

In pair programming, two developers solve the same problem together at the same computer. In the case of an over-the-shoulder inspection, the developer simply shows the code to his colleague.

During inspection by e-mail, the changed code is automatically sent for analysis to another programmer.

Inspection of the code using special tools assumes the availability of utilities to assist in the analysis.
They make it easier:

• collection of changes made to the code;
• comparison of the current and previous states of the code;
• dialogue with a particular code;
• statistics collection;
• speeding up the code inspection and correction of defects found;
• etc.

Our Code Inspection Experience

Mobile development began an active development after the presentation of the first iPhone. Due to the fact that this is a fairly young area, programmers working in it are important for cooperation, adaptation of existing approaches from the field of web or desktop development, work on new ideas. And here the practice of code inspections helps a lot.

Our mobile development team has come a long way in implementing code inspections. It all started with periodic formal inspections. Now almost all types of code inspections are used. Most of the same actions in the analysis of the code are automated, which made it possible to painlessly introduce this practice into the software development process.

First of all, in addition to formal code inspections, the verification of projects by static code analyzers was integrated. In the case of Android development, Pmd, Findbug, Checkstyle, Lint were used. This allowed us to automatically find all code problems associated with non-compliance with the coding style, improper use of system APIs, errors in building the user interface, etc. At first, the integration of analyzer data on a build server fully satisfied our needs. However, over time, this approach has ceased to suit us for many reasons. In particular, we did not like that:

• each analyzer had to be configured separately, and when deciding to use a new analyzer, its addition to all projects was done manually;
• there was no convenient and centralized ability to manage the rules of analyzers (disable, add, edit);
• there was no way to ignore false positives without changing the code;
• it was impossible to somehow interact with the comments (for example, to postpone their correction, comment, etc.);
• comments generated by various analyzers could not be combined into a single report.

Project analysis results using PMD (Jenkins plugin)

Details of a defect found using PMD (Jenkins Plugin)

Soon we realized that this could not go on further - the team was growing, and each new programmer had to learn a fairly large amount of information regarding the existing development processes and the utilities used. Then it was decided to try the SonarQube platform [3], which is designed to constantly monitor the quality of the code. Despite our doubts, the platform showed itself only on the good side. She solved most of our problems with static code analyzers, added new metrics by which you can track the status of the project. Management of the rules has become centralized, the opportunity has appeared to draw up plans for the correction of found defects, etc.

Project Analysis Results in SonarQube

Details of the defect found in SonarQube

Static code analyzers certainly help a lot, but you can't completely rely on them. They allow you to save formal code inspections from discussing obvious defects and point out suspicious places. But they are not able to advise something, for example, in terms of application architecture.

Conducting formal code inspections, even taking into account the help of static analyzers, is too time-consuming event. Therefore, on the one hand, if it is carried out frequently, the productivity of programmers will really decrease, on the other hand, if it is carried out rarely, the amount of code that needs to be inspected will increase. According to studies, a large amount of code will only reduce the number of defects found [2].

In search of a solution that would be as effective as a formal code inspection, but not take so much time, we came up with Atlassian Crucible [4]. In fact, this tool took all the work into:

• preparing code changes for verification;
• code navigation;
• dialogue with respect to certain lines of code;
• inviting developers to conduct an inspection;
• tracking corrections as noted by colleagues;
• etc.

The most interesting feature that we actively use in Crucible is that now all changes in the code are tied to a specific task. That is, it allows code inspections regarding a specific task. As a result, the comments of fellow programmers are more substantive in nature and really help to find and fix non-trivial errors.

Example of a user screen when conducting a code inspection using Atlassian Crucible

Example of a screen for creating a code inspection in Atlassian Crucible

Thus, in our team, every commit made by the developer is checked on the build server by static analyzers. All collected statistics are accumulated in SonarQube and used by all interested parties: programmers - for self-testing and identification of problem areas, management - to understand the status of the project. When the programmer finishes work on the task, he begins to inspect the code. Using Crucible, changes associated with the completed task are highlighted and team members are invited. When the code will suit everyone, the code inspection is completed. As a result, each line of code is analyzed, and the whole team is now responsible for it.

Although we went on to conduct code inspections using special tools, there was no complete rejection of formal inspections. They are held anyway, but are more global in nature, because They discuss issues related to the architecture of the application. Formal inspections are carried out without fail for all new projects that come to us.

What we have?

Inspections of the code undoubtedly help in the development of high-quality applications both on the part of the user (the application does not crash, does not slow down, work with it is intuitive) and the developers (excellent architecture of the application, lack of technical debt). At the same time, each team of programmers is unique, and therefore, a special approach to introducing any new practices is usually required. In our case, there was support both from programmers and from the management, which allowed us to successfully integrate code inspection into development processes. The result of this work was:

• increase in the number of defects detected and corrected until testing;
• reducing the time spent on code inspection;
• reducing the time spent on testing the application;
• team interest in code analysis;
• tracking the results of code inspections;
• expanding the domain of developers about project code;
• faster exchange of experience between beginners and advanced developers;
• there is a reduction in the comments made to the code (due to the growth of the general competence of the team);
• reduction of risks of delaying delivery times;
• the appearance of metrics by which one can indirectly judge the status of projects.

Eventually

It should be noted that code inspections are not the only practice that helps with software development. The purpose of this article was to tell exactly about it, so distractions to other ongoing processes were not done. In general, our team is satisfied with the result, but is not going to stop there. We hope our experience will be useful to you.

References

1. Best Kept Secrets of Peer Code Review / J. Cohen, St. Teleki, E. Brown
2. 11 Best Practices for Peer Code Review // smartbear.com/SmartBear/media/pdfs/11_Best_Practices_for_Peer_Code_Review.pdf
3. Atlassian Crucible Overview - www.atlassian.com/software/crucible/overview
4. SonarQube - www.sonarqube.org