持续集成回顾暨点滴分享[4] – 静态代码检查，单元测试好基友！
前言
关于使用Sonar进行静态代码检查（static analysis，SA），我的同事霞如女士在《易测试》2013年8月刊已有十分全面而精彩的论述，建议读者先阅读之 
本文仅结合自身实践略作小结，并介绍一些小技巧
所谓 名不正则言不顺，言不顺则事不成 在进入正文之前我还是啰嗦下静态代码检查的好处
Δ初级作用
- 借助工具快速、低成本地发现代码中的问题，尤其是功能性方面的（空指针、内存溢出、死循环、安全性问题、多线程问题，等），协助工程师解决掉这些风险点
Δ进阶作用
- 协助工程师熟悉和掌握规范化的代码风格以及一些最佳实践，使代码更具有内在美，也提升工程师自身的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基本消灭了，再重复上述过程，补充新规则
小技巧合集
Δ规则集合制定，调整，使用
以管理员登陆后，可以在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技能更加专业，实在是长短结合的优质股，潜力股
持续集成回顾暨点滴分享[4] – 静态代码检查，单元测试好基友！相关推荐
- 持续集成回顾暨点滴分享[1] – 举目向前，摸石过河
大概会涉及以下内容: UI自动化 单元测试 接口测试 静态代码检查 Code Review Jenkins及Sonar的配置与使用 代码覆盖率 沟通技巧 与开发团队的协作与沟通 SVN / Git / ...
- Docker+Jenkins持续集成环境（3）集成PMD、FindBugs、Checkstyle静态代码检查工具并邮件发送检查结果...
为了规范代码,我们一般会集成静态代码检测工具,比如PMD.FindBugs.Checkstyle,那么Jenkins如何集成这些检查工具,并把检查结果放到构建邮件里呢? 今天做了调研和实现,过程如下 ...
- DevOps系列之 —— 持续开发与集成（六）静态代码检查
DevOps系列之 -- DevOps概览(一)软件产业和交付模式发展趋势 DevOps系列之 -- DevOps概览(二)新型软件技术及交付模式 DevOps系列之 -- DevOps概览(三)De ...
- Gitlab CI集成sonarqube实现静态代码检查
其他博文连接 Ubuntu Server 16.04LTS 搭建GitLab服务器 ubuntu server 16.04 使用docker搭建jenkins和sonarqube Gitlab配置Gi ...
- jenkins+findbugs+checkstyle+PMD静态代码检查（二）
可以根据自己的需求选中对应的插件进行配置(不一定非要同时配置三个插件) jenkins:持续集成的工具 fundbugs:检测代码静态错误的插件 例如:定义了没有用到的对象,string类型的比较使 ...
- 静态代码检查工具简介
静态代码检查工具简介 在 Java 软件开发过程中,开发团队往往要花费大量的时间和精力发现并修改代码缺陷.传统的代码复审.同行评审,通过人工方式来检查缺陷仍然是一件耗时耗力的事情.Java 静态代码分 ...
- 静态代码检查完成代码分析和SonarQuber的初探
静态代码检查完成代码分析和SonarQuber的初探 静态代码检查就是静态测试的一种,因此我们先说说静态测试和动态测试都是什么,然后我们再来聊一聊静态代码检查. 先搞清动静的区别 静态测试是指不运行被 ...
- 静态代码检查工具 cppcheck 的使用
CppCheck是一个C/C++代码缺陷静态检查工具.不同于C/C++编译器及其它分析工具,CppCheck只检查编译器检查不出来的bug,不检查语法错误.所谓静态代码检查就是使用一个工具检查我们写的 ...
- 静态代码检查工具-PMD
静态代码检查工具-PMD 分类: 网络安全/ 工具使用/ 文章 提高代码的质量,除了要提高逻辑上的控制以及业务流程的理解外,代码本身也存在提高的空间,例如一些潜在的问题可以很早的就避免.类似于编码规范 ...
最新文章
- 22.加密与安全相关,证书申请CA（gpg，openssl)
- php tp框架分页源代码,ThinkPHP3.2框架自带分页功能实现方法示例
- OpenLayer学习之矢量地图
- qt与js html进行数据传递,QT与javascript交互数据的实现
- PyTorch 1.0 中文文档：torch.nn.functional
- ubuntu12.04 Struts2 配置过程中出现的错误
- 问题-[致命错误] Project1.dpr(1): Unit not found: 'System.pas' or binary equivalents (DCU,DPU)
- 拓端tecdat|python虎扑社区论坛数据爬虫分析报告
- 使用C++进行SVG开发
- 分布式事务 - 两阶段提交与三阶段提交
- .wav音乐文件转换为.fft.npy频谱格式文件
- 康师傅红烧牛肉面：守护平凡英雄，成就烟火人生
- java 逃逸分析_JVM之逃逸分析
- 一文搞懂 | Linux 同步管理（上）
- 7-1 jmu-python-汇率兑换
- 国内首部创业纪实电影《燃点》进校园：如何靠近成功的2%
- 离散数学及其应用复盘 | 第3版第4章——谓词逻辑思维导图梳理（复习专用）
- 英文版权声明_想避免版权问题，这些网站你一定需要
- Altium designer实践总结
- mysql重迭算法_MySQL – 如何选择’DISTINCT’重叠时段(日期或数字范围)