持续集成回顾暨点滴分享[4] – 静态代码检查，单元测试好基友！

前言

关于使用Sonar进行静态代码检查（static analysis，SA），我的同事霞如女士在《易测试》2013年8月刊已有十分全面而精彩的论述，建议读者先阅读之  本文仅结合自身实践略作小结，并介绍一些小技巧

所谓 名不正则言不顺，言不顺则事不成 在进入正文之前我还是啰嗦下静态代码检查的好处

Δ初级作用

• 借助工具快速、低成本地发现代码中的问题，尤其是功能性方面的（空指针、内存溢出、死循环、安全性问题、多线程问题，等），协助工程师解决掉这些风险点

Δ进阶作用

• 协助工程师熟悉和掌握规范化的代码风格以及一些最佳实践，使代码更具有内在美，也提升工程师自身的coding素养
• 提前消灭明显或者低价值的问题，使工程师的注意力可以集中在创造性的、复杂的点上，也使得代码审查更具效率
• 使代码逐步摆脱工程师的个人烙印，具备统一风格，成为团队的共同财产
• 作为一个客观中立的标准来衡量代码质量

流程推荐

静态代码检查的难点，一是在于其 可执行性 稍差，一次全面的静态代码检查（例如：启用Sonar内置的所有PMD、CheckStyle、FindBugs的major以上规则）可能瞬间会出现N多Issue，放眼望去，不知如何下手

如下图所示，Issue数目与代码行数在一个数量级了！  

 

 

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

我这边当前使用的流程如下：

1. 开启全部PMD/CheckStyle/FindBugs的major以上规则全面扫一遍，这时候的扫描结果会比较难看，比如说，发现了10000个Issue，属于200个Rule
2. 由专人（建议是Java基础扎实的测试工程师 or 开发工程师）先人工过一遍全部Issue（ 属于同一个Rule的Issue只要看1-2个就行了 ），进行初步筛选，觉得有价值的Issue，就指派给自己；完成初步筛选后，大约会有150个Issue被指派给自己，属于100个Rule
3. 邀请大家一起Review上述指派给自己的Issue， 大家都觉得有必要修改某个Issue，则保留这个Issue所属的Rule ；完成这一步，大概就留下了50-70个Rule
4. 重新制定规则集合，只包含上述50-70个Rule，并投入正式使用
5. block/critical级别属于第一期修复目标
6. major级别可以分多期完成
7. 经过一段时间以后，以上规则集下面的Issue基本消灭了，再重复上述过程，补充新规则

小技巧合集

Δ规则集合制定，调整，使用

以管理员登陆后，可以在settings里面配置规则集合，这里建议不要直接修改已有的规则集合，而是copy一份，重命名，命名中加上版本号

Rule的严重级别(Severity)是允许调整的，方便灵活应对实际情况

每个项目可以自己选择规则集合；不设置，就使用管理员设定的默认规则集合

 

Δ指派功能

Issue浏览过程中可以进行指派，评论，确认等，方便事后集中查看、处理

据小道消息，Sonar还可以和JIRA等项目管理工具联接，这样指派功能就更加niubility了！

Δ显示SCM信息

使用管理员在settings – configuration – general settings – scm activity里面配置后，就可以在代码中看到scm blame了，妈妈再也不用担心找不到是谁写的搓逼代码了！

Δ指定静态代码检查范围

在具体产品（项目）中，可以配置哪些代码须要 or 不要纳入静态代码检查

好处不解释！

Δ横向比较（大杀器）

Sonar允许同一个产品与自己的历史版本比较 or 多个产品之间互相比较，YES！

不怕不识货，就怕货比货！

不比不知道，一比吓一跳！

霸气侧漏，有木有！

Δ单元测试

Issue的修复过程相当于小型重构，重构有风险，须要严密的单元测试保证

好基友，一起上！

结语

静态代码检查的规则集合与单元测试的用例集合在某种程度上是类似的，都须要不停地维护，Review

但是比起单元测试须要选框架、配环境、搞Mock、写用例、日常维护，静态代码检查实在是 简单粗暴 （google:红色帝国 暴力美学），配置成本低得多，见效快，按照上面介绍的流程及小技巧，可执行性也相当高（从零开始修复静态代码检查绝对比从零开始写单元测试更Easy！）

从短期看，静态代码检查可以迅速发现代码中的隐藏问题，减少产品风险；从长期看，又可以逐步使产品代码具备内在美，使技术团队的coding技能更加专业，实在是长短结合的优质股，潜力股