场景

某年某月某日。产品环境的2000多封自己主动发出的Email让我们项目组很多人的邮箱爆了。追查下来根源是一个非常不起眼的缺陷。我们的程序对一个布尔值做了if(XXX = true)的推断，可来自上游系统的这个值不光是有true和false，还有空。

也就是说上游系统中使用的是一个大布尔，是有true, false,null三态的。  而我们程序使用的是小布尔，仅仅有true和false两态。

掉在大小布尔这个坑里也不是头一回了。记忆中前两年我们也掉进来过。

有执著的QA一枚，翻箱倒柜地找。最终找到了当时的email，上面赫然写着“待改进事项：在PMD（我们採用的代码静态检查工具之中的一个）中增加对大小布尔的提醒”。显然，这个事情后来没有被运行下去。。。既然代码静态检查是可以帮助我们解决问题的。

但为什么后来没有做呢？执著的QA開始找人了解情况，积极反思。

。。

场景分析

（1）       对静态測试的重要性和必要性认识不够

有的程序猿说：“静态測试是有利于遵循编程规范啊，可我手上的代码大部分是别人留下来的。慘不忍睹啊！

你是要我先把功能做出来。还是先把前面留下来的不规范代码都又一次整理一遍？等我有空再说吧！”有的程序猿说：“等我有空了我也不想做。

我认为还不如研究一下新技术呢，代码能跑即可了。代码规范那体力活我可没有兴趣。”

因为静态測试发现的往往不是那种很严重的缺陷，而仅仅是特定情况下潜在的缺陷，或者仅仅是维护时代码的可读性等问题。所以比起动态測试报告的对用户产生影响的缺陷，静态測试往往成为在面临压力下开发团队和个人比較easy先放弃的一个活动。但大家可曾意识到大量动态測试暴露的缺陷。经常会归结于代码的可读性、可维护性、可測试性差、圈复杂度高、反复代码多等等。因此更改代码时easy引起一些副作用，所以越改越错、越错越多。依据有关统计。在实际使用中代码检查比动态測试更有效率。能高速找到缺陷，发现30%～70%的逻辑设计和编码缺陷。与动态測试相比，静态測试具有发现缺陷早、减少返工成本、覆盖重点和发现缺陷的概率高的长处。

（2）       主要靠人来进行，难以坚持

有的团队可以意识到静态測试的价值，但尝试了一段时间发现难以坚持。

主要原因是他们的静态測试太依赖于人来保障其运行。

尽管静态測试中有些问题必须通过人的代码走读来发现，但我们觉得最佳的可行方式是工具与人结合来进行静态測试。

即静态測试中对于编码规范这块主要借由工具检查来进行最主要的保障。而人的精力集中关注一些更深层次的工具无法识别出来的问题，如设计不合理、逻辑错误等。由工具来检查的编码规范能够在项目组内作为统一的要求。在程序猿每次checkin 代码的时候都自己主动进行检查。帮助程序猿在尽可能早的时候发现违反的情况。及时修复。

不管是人还是工具进行静态測试，都须要及时常常地进行。假设积累了大量的问题一次检查出来须要修复则会有点积重难返。比如，实际工作中最难处理的就是遗留系统中的代码不符合规范的问题。

假设项目的开发时间非常紧迫。能够先要求新代码严格遵守规范，而对老代码网开一面。然后及时寻找时机，分批处理老代码的问题。假设由于维护遗留系统要花费很多其它的代价整理代码而不去做静态測试，那么就非常easy陷入破窗效应，后果也将是慘痛的。

（3）       静态測试工具定义的规则不适用

如今有非常多工具。如PMD,CheckStyle。不但提供了大量的编码规范能够自己主动扫描代码对其遵循情况。还能够让使用者开发和定制自己的规范。如前面提到的大小布尔的检查点就能够自己编成实现这种规则校验。然后纳入PMD,CheckStyle的检查中去。而对于那些团队觉得无伤大雅的规则，也能够去掉，让开发者集中精力解决最典型和潜在危害最大的问题。