。其实接到这个任务的时候，我内心是拒绝的，因为据我了解，各种静态代码扫描工具出来已经很长时间了，然而在各大公司推行的情况，相信各位略有耳闻，效果甚微。前阵子我看到 google 上有篇论文，叫《Why Don’t Software Developers Use Static Analysis Tools to Find Bugs?》，我深以为然！结合目前手头推进的经历，以及业务方的各种反馈来看，现实很残酷。但是既然决定做这事了，还是希望能改变这种现状，和 testerhome 的一些牛人讨论过这个话题，非常感谢给我建议的那几位大牛，给了我继续推进这件事的勇气 。
-- 感谢何正老师为我们打下的基础
关注互联网的人也许看到过下面这段代码，当时引起了轩然大波。
事情原由我就不赘述了，我们最初的目的就是从根本上避免这种事在我们这里发生，于是在公司大老板和技术委员会的推动下，出现了一个叫安卓代码红线的工具，也就是火线的前身。
安卓代码红线出现的目的就是杜绝一些明显违反公司规定，或者违反安全类规范的代码内容，希望通过静态代码分析来解决这个问题。前期定下的规则已经大部分实现了（实际上也没几条规则），随着工作的推进，我们发现其实我们可以做更多的事情，于是在安卓代码红线的基础上做了不少扩展，演变成了如今的 “火线” 平台。
我们针对市面上用的比较多的几个工具进行了分析，大概情况如下（不正确的地方还请指出，谢谢）：
（原谅我用图片代替，markdown 表格内换行实在是不会。。。）
上面几种工具的侧重点分别是不同的，从开发的反馈来看，他们用的比较多的是findbugs这个工具，这几款工具的比较相信表格里面已经写的很清楚了，在此不一一讲解。
经过一段时间的调研，我们总结了一些客户的痛点和需求反馈如下：
结合上面调研的几种工具，以及火线项目在扫描实际代码的时候总结的一些反馈，我们做了如下实验，新建一个安卓工程，在代码中预留了一些待检测问题，然后分别用不同的工具来扫描，查看结果的命中率，结果大概是这样的：
每个工具的检测结果是不一样的，实际上这个实验也不够严谨，因为 findbugs 和 lint 分别有各自的侧重点和优势，每个工具的特征也比较明显。其中 Findbugs 报了不少"*** doesn't start with an upper case letter"这样的错误，而 PMD 似乎对 R.java 很感兴趣，一下子报了 7000 多个问题（大部分是 R.java 报错），当然规则是可以删减的，我们扫描的时候为了确保完整性没有对规则进行精简。
现在比较流行的 SonarQube 平台就将几种工具集成到一个平台上统一管理和输出，但是在定制化方面较为复杂，规则扩展性和跨平台也不方便，有需求的同学可以去看看这个平台。
相信通过上面的图片比较，各位应该能看出来我们大致做了哪些事情，我们结合前面提到的痛点和需求来具体看看：
| 数据指标 | 本周数据 |
|---|---|
| 累计运行天数 | 115 天 |
| 累计扫描次数 | 5158 次 |
| 覆盖项目及任务 | 260 个 |
| 扫描代码总行数 | 81,214,988 行 |
| 扫描文件总数 | 215173 个 |
| 平均项目扫描时间 | 38.95 秒 |
| 千行扫描时间 | 0.469 秒 |
此为 4 月 1 日为止的累计数据，覆盖项目及任务可能存在一个项目多个版本代码的情况
相信大家在公司内部推广工具或者平台的时候，都会遇到各种困难和阻力，我们也不例外。下面是我们遇到的一部分问题（实际上与人打交道是很困难的）
火线之所以能够获取如此多的珍贵数据样本，其实还是取决于公司流程的保障，正如开头所提到的，有大老板和技术委员会引荐，推动起来会相对容易一些，但是好的产品上是真心能帮人解决问题的，而不是借助于 “尚方宝剑” 来强行推动，站在用户的角度上去帮他们解决问题，才是我们的动力。不过光靠自觉也是干不成事情的，还需要借助公司流程来推行。
公司大流程给我们提供了巨大的帮助：
目前流程还有待磨合及完善，相信会逐渐产生积极的影响。
虽然火线借助于公司的流程做了一些工作，但是还远远没有成熟，并且存在的问题也很多，互联网公司的快速迭代开发，让很多细节不再去追溯，很多问题都被忽略，还有一些特殊需求被加入，让代码检测不确定因素越积越多，代码可测性要低于可用性。但是本文并不是讨论如何编写优质的代码，或者如何推动编码规范的，因此在这里就不多吐槽了。
火线目前已经拿到了数百万的缺陷代码样本，能做的事情还很多，目前也存在比较显著的缺点，是我们后面想解决的：
由于产品现在还不成熟，等足够完善的时候，可以开源出来给各位同行使用，也能帮助产品加速完善和成型。所以目前暂时还不能开源，抱歉哈。。。
