You have a mistake here ... or about the practice of code inspections in mobile development

The practice of code review or, if translated into Russian, code inspections appeared long ago and has already been successfully integrated into the development processes in many companies. Teams of programmers from 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 used at all, or is applied occasionally.

The process of implementing code inspections in our team was started several years ago. Before coming to the current state, various approaches, methods 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 be prepared for the emerging difficulties. Now, I think, it is time to share our experience in implementing and using code inspections when developing applications.

Why are code inspections important?

Anyone associated with software development will, without thinking, tell you that the cost of fixing defects in a product depends on the time they are detected. 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 reducing the number of errors in a product is of interest to all interested parties: programmers, managers, customers.

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

Programmers, reading the code that was written by their colleagues, inevitably become acquainted with him, and with the tasks that he must solve. As a result, the command level of the code increases. Developers are beginning to understand how application modules written by other people work. The probability of duplication of the existing functionality (not the code!) Is reduced. Reduced risks associated with leaving or temporary absence of a team member. 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 necessarily reviewed, they start to write it more responsibly: they carefully think over 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 greatest attention in code inspections is represented by advantages that are of a long-term nature. After all, they must be interested in the management team or the customer (in the case of customized development).

First, if the code is not inspected, 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 wonder: why does it take so much time to add a little functionality? The answer is quite simple - no one watched the quality of the application architecture, its code and the changes made to them.

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

Why code inspections are still not conducted?

Programmers, because of the specifics of their profession, are very smart people and know how to count. In particular, they very well consider their time and monitor their productivity. According to their opinion, code inspection distracts from current tasks and reduces productivity. Defects found during the code inspection are also of no particular interest to them, because they mainly represent a list of minor errors made by younger developers. Moreover, this list is consistently repeated, and its discussion is a rather boring process for experienced developers. Conducting an inspection code assumes that all defects found will be corrected. However, there is a great unwillingness of programmers to make changes to the working code. Also, if code inspections are rarely carried out, then the programmer to whom it was entrusted is simply lost in a huge amount of new code. And for him it looks like a punishment. These moments do not motivate the team to systematically conduct code inspections. Programmers believe that the result obtained during the inspection code is not worth the effort. This is a consequence of shortcomings in the approach to the inspection code and the unwillingness to correct them.

It was previously mentioned that the customer should also be interested in conducting code inspections. But, as practice shows, the application is primarily assessed for the declared functionality and test results. Almost no one imposes requirements on the source code and, accordingly, no one checks it. The issue of low quality code appears in two cases:

upon receipt of a project from another team;
with a constant postponement of deadlines due to a large number of errors.

Unfortunately, it is already too late to change something in these cases, but there are several options for getting out of this situation. The first, obvious, is to succumb to the programmers' persuasion to "rewrite everything". However, there is a chance to confide in a weak team with unresolved processes and, at the exit, again to get another confusion of code. The second is to analyze (inspect) the existing code and prepare a strategy for its reanimation. This option is longer and requires tremendous efforts from designers and developers.

Types of code inspections

There are several types of code inspections [1]:

formal inspections (formal inspections);
inspection over the shoulder (over-the-shoulder review);
code inspection via 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 its list of comments. An integral part is a meeting at which there is a discussion of the found defects. The result of the meeting should be a list of further actions of the team regarding the errors found.

With pair programming, two developers solve together one problem behind one computer. In the case of a shoulder inspection, the developer simply shows the code to his colleague.

When inspecting with the help of e-mail, the changed code is automatically sent for analysis to another programmer.

Code inspection with the help of special tools assumes the availability of utilities to assist in the analysis.
They facilitate:

collection of changes made to the code;
comparison of the current and previous code states;
dialogue concerning a specific code;
statistics collection;
forcing the inspection code and the correction of defects found;
etc.

Our experience with code inspections

Mobile development began active development after the presentation of the first iPhone. Due to the fact that this is quite a young area, programmers working in it are important to cooperate, adapt existing approaches from the 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 type of actions in the analysis of the code is automated, which allowed to seamlessly integrate this practice into the software development process.

First of all, in addition to the formal code inspections, the verification of projects with static code analyzers was integrated. For Android development, Pmd, Findbug, Checkstyle, Lint were used. This allowed in automatic mode to find all the problems of the code associated with non-compliance with the coding style, incorrect use of the system API, errors in building the user interface, etc. At first, the integration of data analyzers on the 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 set up separately, and when deciding to use a new analyzer, adding it 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 possibility to ignore false positives without changing the code;
it was impossible to somehow interact with the comments (for example, postpone their correction, comment, etc.);
comments generated by different analyzers could not be combined into one report.

Results of project analysis using PMD (Jenkins plugin)

Details of the defect found using PMD (Jenkins Plugin)

Soon we realized that it could not go on like this - the team grew, and each new programmer had to learn a fairly large amount of information about the existing development processes and utilized utilities. Then it was decided to try the SonarQube platform [3], which is designed to continuously 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 the status of the project can be monitored. The management of the rules has become centralized, it has become possible to draw up plans for the correction of defects found, etc.

Results of the project analysis in SonarQube

Details of a defect found in SonarQube

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

Conducting formal code inspections, even with the help of static analyzers, is too time consuming. Therefore, on the one hand, if it is done frequently, the productivity of programmers will really decrease, on the other, if it is done rarely, the amount of code that needs to be inspected will increase. According to the studies conducted, 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 did not take so much time, we came to the use of Atlassian Crucible [4]. In fact, this tool took over all the work on:

preparing code changes for verification;
code navigation;
dialogue on specific lines of code;
inviting developers for inspection;
tracking patches, according to 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 you to conduct code inspections for a specific task. As a result, the comments of fellow programmers are more substantive in nature and really help to find and correct nontrivial errors.

An example of a user screen when conducting an inspection code using Atlassian Crucible

An example of an inspection code creation screen in Atlassian Crucible

Thus, in our team every commit made by the developer is checked on the build server with static analyzers. All collected statistics are accumulated in SonarQube and used by all interested parties: programmers for self-checking and identifying problem areas, management for understanding the state of the project. When the programmer finishes the task, he starts inspecting the code. With Crucible, the changes associated with the completed task are highlighted and team members are invited. When the code will arrange all the inspection code is completed. As a result, each line of code is analyzed, and the entire team is now responsible for it.

Although we proceeded to code inspections through special means, there was no complete rejection of formal inspections. They are still held, but are more global in nature, because They discuss issues related to the architecture of the application. Formal inspections are conducted on a mandatory basis for all new projects that come to us.
')

What we have?

Code inspections undoubtedly help in the development of high-quality applications both from the user’s side (the application does not fall, does not slow down, work with it is intuitive) and from the developers (excellent application architecture, no technical debt). At the same time, each team of programmers is unique, and therefore usually requires a special approach to the introduction of any new practices. In our case, there was support from both programmers and management, which made it possible to successfully integrate code inspection into development processes. The result of this work was:

an increase in the number of defects detected and corrected prior to testing;
reducing the time spent on the inspection code;
reducing the time spent on testing the application;
team interest in conducting code analysis;
tracking the results of code inspections;
Expansion of developers' knowledge of project code;
faster exchange of experience between beginners and advanced developers;
there is a reduction in comments placed on the code (due to the growth of the overall competence of the team);
reducing the risk of delaying delivery;
the emergence 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 her, therefore no distractions to other ongoing processes were made. 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.