这个话题比较有意思，起源是前两天和一个身在外企的程序员的闲聊。当时聊到最近在忙的工作，我随口说最近响应部门的要求，天天在办公室除了做需求分析之外，其余的主要工作就是修改代码中存在的静态检查问题，而且被折磨了好几天。这兄弟一听这个就激动了，他讲修改静态检查这件事情是反人类的，为了这个事情还和领导吵了一架。反不反人类嘛，我不清楚，也没有和项目组的兄弟讨论过；但是和领导吵架，我确实比较羡慕，我所在的公司和部门可没有这样放松的氛围，和领导因为这么点事情吵架，实在是犯不上，我现在可是上有老、下有小的时候，在办公室里讲话可得注意点，小心为上。
先说明一下什么是静态检查问题，免得不了解的兄弟不明所以。所谓静态检查问题，其实就是通过一些经过业界实地检验的代码检查工具，比如PMD、Findbugs之类的，对当前的代码进行检查，输出当前代码中可能存在的问题清单，由于输出这类问题清单时并没有对代码的逻辑正确性做验证，仅仅是从语法结构、语句使用合理性等角度做分析，因而被称为“静态”检查。工具输出的清单中包含的问题，就被称为静态检查问题。
做程序员久了，相信都有加班调试代码、分析Bug、修正Bug的经历。毫无疑问，修正Bug的过程是令人痛苦的，对于世界上最聪明的群体---程序员们来说，Bug真是令人恼火的存在。偏偏有不少Bug还是编码过程中引入的低级错误。为了降低聪明人犯低级错误的机率，聪明人中的一部分就想办法设计出了代码静态检查工具，期望通过扫描代码的方式来消除代码中存在的问题。可惜理想很丰满，现实却很骨感，工具也是由代码组成的，因此也会存在一些小问题，比如误报。
对于项目管理者而言，静态检查工具是个好东东。质量管理大师有云，没有数据就没有度量。对于软件开发这种创造性工作而言，静态检查工具的出现增加了一种新的度量代码质量的维度。对于每天日理万机，处理X封邮件、参与X个会议的管理者们来说，他们是没有兴趣、没有时间或者说没有能力来仔细阅读项目的实现代码，所以问题单数据、特性列表、UT覆盖率等指标成了他们了解项目进展的工作方法。
比如QA会说XXx项目代码中还存在XXX个问题，按照质量要求，需要制定修改计划，限定在X月前完成清零，对于非问题需要给出报告，确认无法修改的原因；
QA还会说，XX项目没有按照预定计划完成静态检查问题清零，需要亲自给XX领导汇报，限期改进等等。
项目经理会说，根据责任模块，各位给出修改计划，同时每天报告修改进度；
项目经理还会说，XX模块本周新引入XX个问题，需要安排XX来处理；XX引入X个问题，需要给出书面报告以及后续改进措施。
。。。。。
对于参与项目开发的程序员来说，修改这类问题相当于增加了自己的工作量，可想而知，当然会有所抵制。修改静态检查问题是个脏活加累活，投入比较大，但对于项目本身来说产出可能并不明显。而对于经验不足、或者代码不熟的成员来说，修改静态检查问题时还有可能引入新的Bug，按下葫芦浮起瓢，得不偿失。但换个角度考虑，静态检查工具发现的问题并不是一无是处，从工具检查的原则分析，可以看出前人在代码开发过程中的经验和总结，假如新手程序员可以从问题本身看到静态检查问题背后，相信这个新手成长的会更快一些。
平心而论，静态检查工具除发现问题外，更重要的作用其实是帮助团队成员养成统一的编码习惯。在我看来，这种统一的编码习惯远比静态检查工具发现的问题更加重要，影响更加深远。
2013年5月7日23:43:11
下午和项目经理讨论了工作的时候提到了UT代码，对静态检查问题这件事情又有点其它的想法。除了抵制修改静态检查外，程序员可能还会对写UT代码有抵触的心理，原因不外乎：
1、进度紧张，挤不出写UT代码的时间；潜台词就是UT代码对当前的需求开发意义不大；
2、条件不具体，没有好用的UT工具，或者是UT的工具用的不熟练，导致写UT代码的代价非常高，比如PowerMock用的不熟，导致写UT的时候花费大量时间在处理桩代码；
3、需求变更频繁，导致已有的UT代码无法在版本中复用，已有UT代码的维护工作量相当大；
4、UT的结果不稳定，经常有失败的现象，需要投入人力分析；
。。。。
假如人不愿意做某件事情，理由可以列出一大堆。所以在项目中做UT、提升UT覆盖率，或者修改静态检查问题、降低问题数目，首要是让参与这个项目的程序员认识到这件事情的重要性，同时创造条件让程序员意识到做这两件事情的好处是什么，不做的话会有什么样的影响；接下来的事情就是为做这些事情创造条件，为程序员创造便利，排除掉外部的干扰。
比如UT代码开发，需要选取合适的打桩工具，如PowerMock和EasyMock，另外还需要有覆盖率工具，借以帮助程序员分析UT的效果，同时也有助于项目经理和程序员制订和管理计划，避免工作量过大、过小。
而对于静态检查问题，则需要讲解每个问题发生的原因和背景，比如问题本身的含义，不修改的话会有什么后果等，在团队内达成一致后，这时项目经理和程序员对静态检查问题修改制订一个双方都可以接受的计划，这时才会得到程序员的支持。
所以，问题的根本在于让程序员识别出一件事情的意义，不能为了做而做。