Δ显示SCM信息
使用管理员在settings – configuration – general settings – scm activity里面配置后，就可以在代码中看到scm blame了，妈妈再也不用担心找不到是谁写的搓逼代码了！
Δ指定静态代码检查范围
在具体产品（项目）中，可以配置哪些代码须要 or 不要纳入静态代码检查，好处不解释！
Δ横向比较（大杀器）
Sonar允许同一个产品与自己的历史版本比较 or 多个产品之间互相比较，YES！
不怕不识货，就怕货比货！
不比不知道，一比吓一跳！
霸气侧漏，有木有！
Δ单元测试
Issue的修复过程相当于小型重构，重构有风险，须要严密的单元测试保证
好基友，一起上！
结语
静态代码检查的规则集合与单元测试的用例集合在某种程度上是类似的，都须要不停地维护，Review
但是比起单元测试须要选框架、配环境、搞Mock、写用例、日常维护，静态代码检查实在是 简单粗暴 （google:红色帝国 暴力美学），配置成本低得多，见效快，按照上面介绍的流程及小技巧，可执行性也相当高（从零开始修复静态代码检查绝对比从零开始写单元测试更Easy！）
从短期看，静态代码检查可以迅速发现代码中的隐藏问题，减少产品风险；从长期看，又可以逐步使产品代码具备内在美，使技术团队的coding技能更加专业，实在是长短结合的优质股，潜力股
相关文章：
