前言
　　关于使用Sonar进行静态代码检查（static analysis，SA），本文仅结合自身实践略作小结，并介绍一些小技巧
　　所谓 名不正则言不顺，言不顺则事不成，在进入正文之前我还是?嗦下静态代码检查的好处
　　Δ初级作用
　　借助工具快速、低成本地发现代码中的问题，尤其是功能性方面的（空指针、内存溢出、死循环、安全性问题、多线程问题，等），协助工程师解决掉这些风险点
　　Δ进阶作用
　　协助工程师熟悉和掌握规范化的代码风格以及一些佳实践，使代码更具有内在美，也提升工程师自身的coding素养
　　提前消灭明显或者低价值的问题，使工程师的注意力可以集中在创造性的、复杂的点上，也使得代码审查更具效率
　　使代码逐步摆脱工程师的个人烙印，具备统一风格，成为团队的共同财产
　　作为一个客观中立的标准来衡量代码质量
　　流程推荐
　　静态代码检查的难点，一是在于其 可执行性 稍差，一次全面的静态代码检查（例如：启用Sonar内置的所有PMD、CheckStyle、FindBugs的major以上规则）可能瞬间会出现N多Issue，放眼望去，不知如何下手
　　如下图所示，Issue数目与代码行数在一个数量级了！

　　二是在于不同的项目之间，静态代码检查规则（Rule）集合的 复用性 不强，而且规则会不停调整，须要像测试用例一样持续维护
　　我这边当前使用的流程如下：

　　开启全部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基本消灭了，再重复上述过程，补充新规则