前言
关于使用Sonar进行静态代码检查（static analysis，SA），本文仅结合自身实践略作小结，并介绍一些小技巧
所谓 名不正则言不顺，言不顺则事不成，在进入正文之前我还是啰嗦下静态代码检查的好处
Δ初级作用
借助工具快速、低成本地发现代码中的问题，尤其是功能性方面的（空指针、内存溢出、死循环、安全性问题、多线程问题，等），协助工程师解决掉这些风险点
Δ进阶作用
协助工程师熟悉和掌握规范化的代码风格以及一些最佳实践，使代码更具有内在美，也提升工程师自身的coding素养
提前消灭明显或者低价值的问题，使工程师的注意力可以集中在创造性的、复杂的点上，也使得代码审查更具效率
使代码逐步摆脱工程师的个人烙印，具备统一风格，成为团队的共同财产
作为一个客观中立的标准来衡量代码质量
流程推荐
静态代码检查的难点，一是在于其 可执行性 稍差，一次全面的静态代码检查（例如：启用Sonar内置的所有PMD、CheckStyle、FindBugs的major以上规则）可能瞬间会出现N多Issue，放眼望去，不知如何下手
如下图所示，Issue数目与代码行数在一个数量级了！
我这边当前使用的流程如下：
开启全部PMD/CheckStyle/FindBugs的major以上规则全面扫一遍，这时候的扫描结果会比较难看，比如说，发现了10000个Issue，属于200个Rule
由专人（建议是Java基础扎实的测试工程师 or 开发工程师）先人工过一遍全部Issue（ 属于同一个Rule的Issue只要看1-2个就行了 ），进行初步筛选，觉得有价值的Issue，就指派给自己；完成初步筛选后，大约会有150个Issue被指派给自己，属于100个Rule
邀请大家一起Review上述指派给自己的Issue， 大家都觉得有必要修改某个Issue，则保留这个Issue所属的Rule ；完成这一步，大概就留下了50-70个Rule
重新制定规则集合，只包含上述50-70个Rule，并投入正式使用
block/critical级别属于第一期修复目标
major级别可以分多期完成
经过一段时间以后，以上规则集下面的Issue基本消灭了，再重复上述过程，补充新规则
