Why do programmers hate modifying static checks?

This topic is interesting. It originated from chatting with a programmer in a foreign company two days ago. At that time, I talked about my recent busy work. I casually said that in response to the requirements of the Department recently, in addition to Requirement Analysis in the office every day, the other main task is to modify the static check problems in the code, it has been suffering for several days. This brother was excited when he heard of it. He told me that modifying static checks is against humanity and he had a quarrel with the leaders for this purpose. I do not know whether it is anti-human. I have never discussed it with the project team's brother. However, I do envy myself when quarreling with the leaders, my company and department do not have such a relaxed atmosphere. It is really hard to quarrel with the leaders because of such a thing. Now, when I am old or small, be careful when speaking in the office.

First, explain what is a static check problem, so that the unknown brothers do not know. The so-called static check problem is actually to check the current Code through some code check tools that have passed the field test, such as PMD and findbugs, output the list of possible problems in the current Code. Because the logic correctness of the Code is not verified when the list of such problems is output, it is only analyzed from the perspective of syntax structure and statement rationality, therefore, it is called a "static" check. The problems in the list output by the tool are called static checks.

I have been a programmer for a long time. I believe all of them have worked overtime to debug code, analyze bugs, and correct bugs. There is no doubt that the bug fixing process is painful. For the smartest group in the world-programmers, bugs are really annoying. There are many bugs or low-level errors introduced in the coding process. To reduce the chance of a smart person making a low-level error, some of the smart person will try to design a static code check tool, hoping to eliminate the problems in the Code by scanning the code. Unfortunately, the ideal is very plump, but the reality is very skinny. The tool is also composed of code, so there will be some small problems, such as false positives.

Static check tools are good for project managers. Quality Management masters have clouds, and there is no measurement without data. For the creative work of software development, the emergence of static check tools adds a new dimension to measure the quality of code. Managers who process x emails and participate in X meetings every day are not interested, have no time or ability to carefully read the project implementation code, therefore, indicators such as the problem sheet data, feature list, and UT coverage rate have become a way for them to understand the progress of the project.

For example, QA will say that there are still XXX problems in the XXX project code. According to the quality requirements, a change plan should be prepared, which should be cleared by X months ago. A report should be provided for non-problems, confirm the cause of the failure;

QA also said that the XX Project did not complete static check and the problem was fixed according to the schedule. The XX Project should be reported to the XX leadership in person and improved within a time limit.

The project manager will say that, based on the Responsibility module, you will give a change plan and report the change progress on a daily basis;

The Project Manager also said that xx needs to be arranged to handle the new XX Problems introduced by the XX module this week. XX needs to provide written reports and follow-up improvement measures for introducing X problems.

.....

For programmers involved in project development, modifying such problems is equivalent to increasing their own workload. it is conceivable that, of course, there will be resistance. The problem of modifying the static check is that it is a dirty job with a large investment, but the output may not be obvious for the project itself. For experienced or unfamiliar code members, a new bug may be introduced when modifying static check problems. If you press the hoist to float the issue, the loss is worth the candle. However, from another perspective, the problems found by the static check tool are not useless. From the analysis of the principle of the tool check, we can see the previous experiences and conclusions in the code development process, if a novice programmer can see the problem behind the static check itself, I believe this newbie will grow faster.

In all fairness, in addition to identifying problems, static checking tools play a more important role in helping Team members develop a unified coding habit. In my opinion, this unified coding habit is far more important than the problems found by static checking tools and has a more profound impact.

May 7, 2013 23:43:11

In the afternoon, I discussed the UT code at work with the project manager, and I had some other thoughts on static checks. In addition to resisting modification to static checks, programmers may also be resistant to writing ut code for the following reasons:

1. The progress is tight and the UT Code cannot be written. The sub-line is that UT code is of little significance to the development of the current demand;

2. The conditions are not specific, there is no ut tool for use, or the UT tool is not skilled. As a result, the UT code writing cost is very high, such as not familiar with powermock, as a result, writing ut takes a lot of time to process the pile of code;

3. Frequent changes in requirements make existing ut code unable to be reused in versions, and the maintenance workload of existing ut code is quite large;

4. The ut results are unstable and often fail. Human analysis is required;

....

If you are unwilling to do something, you can list a lot of reasons. So to do ut in the project, improve ut coverage, or modify static check problems and reduce the number of problems, the first thing is to let the programmers involved in this project realize the importance of this matter, at the same time, the creation of conditions makes programmers realize what are the benefits of doing these two things, and what will be the impact of doing nothing. The next thing is to create conditions for doing these things and create convenience for programmers, eliminate external interference.

For example, ut code development requires selecting appropriate piling tools, such as powermock and easymock, and coverage tools to help programmers analyze ut results, at the same time, it also helps project managers and programmers to develop and manage plans to avoid excessive or too small workload.

For static check problems, you need to explain the cause and background of each problem, such as the meaning of the problem itself, and what will happen if you do not modify it. After reaching an agreement within the team, at this time, the project manager and the programmer will formulate a plan that both parties can accept for the modification of the static check problem, then they will get the support of the programmer.

Therefore, the root cause of the problem is to let the programmer identify the meaning of one thing and cannot do it for the sake of doing it.