场景

某年某月某日，产品环境的2000多封自动发出的Email让我们项目组许多人的邮箱爆了。追查下来根源是一个很不起眼的缺陷。我们的程序对一个布尔值做了if(XXX = true)的判断，可来自上游系统的这个值不光是有true和false，还有空。也就是说上游系统中使用的是一个大布尔，是有true, false,null三态的，  而我们程序使用的是小布尔，只有true和false两态。

掉在大小布尔这个坑里也不是头一回了。记忆中前两年我们也掉进来过。有执著的QA一枚，翻箱倒柜地找，终于找到了当时的email，上面赫然写着“待改进事项：在PMD（我们采用的代码静态检查工具之一）中加入对大小布尔的提醒”。显然，这个事情后来没有被执行下去。。。既然代码静态检查是能够帮助我们解决这个问题的。但为什么后来没有做呢？执著的QA开始找人了解情况，积极反思。。。

场景分析

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

有的程序员说：“静态测试是有利于遵循编程规范啊，可我手上的代码大部分是别人留下来的，惨不忍睹啊！你是要我先把功能做出来，还是先把前面留下来的不规范代码都重新整理一遍？等我有空再说吧！”有的程序员说：“等我有空了我也不想做。我觉得还不如研究一下新技术呢，代码能跑就行了，代码规范那体力活我可没有兴趣。”

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

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

有的团队能够意识到静态测试的价值，但尝试了一段时间发现难以坚持。主要原因是他们的静态测试太依赖于人来保障其执行。

虽然静态测试中有些问题必须通过人的代码走读来发现，但我们认为最佳的可行方式是工具与人结合来进行静态测试。即静态测试中对于编码规范这块主要借由工具检查来进行最基本的保障。而人的精力集中关注一些更深层次的工具无法识别出来的问题，如设计不合理、逻辑错误等。由工具来检查的编码规范可以在项目组内作为统一的要求，在程序员每次checkin 代码的时候都自动进行检查，帮助程序员在尽可能早的时候发现违反的情况，及时修复。

无论是人还是工具进行静态测试，都需要及时经常地进行。如果积累了大量的问题一次检查出来需要修复则会有点积重难返。例如，实际工作中最难处理的就是遗留系统中的代码不符合规范的问题。如果项目的开发时间很紧迫，可以先要求新代码严格遵守规范，而对老代码网开一面，然后及时寻找时机，分批处理老代码的问题。如果因为维护遗留系统要花费更多的代价整理代码而不去做静态测试，那么就很容易陷入破窗效应，后果也将是惨痛的。

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

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