[代码质量标准定义] Sonar规则、覆盖率与QualityGate

本文档要回答以下问题：

1. 要使用哪些规则进行检查？单元测试覆盖率多少？重复率多少？怎样才算通过？为什么？
2. 实战中怎么使用？

1 Sonar 检查规则

1.1 规则的分类

按照问题严重级别，分为以下4类：

• Bug（可靠性）
• Vulnerability（漏洞）
• Code Smell（可维护性）
• Security Hotspot（安全疑点，可能不需要修复，需要人工检查）

1.2 Sonar 常见的可用规则库对比

Sonar 中，可以用插件的方式，把其他静态检查工具的规则加进来。以下是常见规则库的对比。

用色块标出了强关联的规则库。例如，只要安装了 FindBugs 插件，就会得到 3 个规则库，这三个库就是强关联的。

（版本不同，具体数字可能会有差异）

1.3 最终选择

第一版方案

(SonarAnalyzer（剔除所有SecurityHotspot） + Common Java) + (FindBugs + Find Security Bugs)

理由：覆盖全面，文档齐全，使用方便。经本地测试验证，FindBugs Contrib 很多bug规则没必要，或者已经被 Sonar 涵盖。

后续提升方案

在所有规则中筛选，挑出适合我们的规则集合。

IDEA 侧，自己开发一个插件，确保规则一致。

2 单元测试代码覆盖率标准

2.1 优秀 Java 开源项目的指标

2.2 大厂覆盖率调研

从调研结果可以看出：

1. 国内高速发展的互联网公司中，相当大一部分是不要求单元测试覆盖率的。原因是，业务太多，变化太快，产品不成熟。
2. 华为、腾讯、阿里中，部门之间存在较大差异。拥有成熟产品的部门，应该是严格要求单元测试的（这里是推测，微信、淘宝这种产品，很难想象没有单元测试）。
3. 成熟的外企，如 SAP、爱彼迎，对单元测试覆盖率的要求都比较高。

2.3 标准确定

新增代码的覆盖率 70%。一段时间之后（如半年到1年），逐步增加至 75% ～ 85%。

理由：

可以看出这样一个规律：产品成熟度越高，对单元测试覆盖率的要求也越高。（当一个产品能产生足够大和稳定的现金流之后，可以花更多的精力来打磨质量）

根据我们目前的情况，目标太激进难以上手，太低了没有意义，不妨遵循《阿里巴巴Java开发手册》的建议。

3 Sonar 的 QualityGate

覆盖率改为 70%，安全性评分改为 B，其他与 Sonar 内置的方案一致。

标准详解：

• 覆盖率大于等于 70%。这里的覆盖率是由行覆盖率和分支覆盖率计算出来的；
• 重复代码小于等于 3.0%；
• 技术债评分为 A，即各种 CodeSmell 加在一起的负债时间低于本次开发时间的 5%；
• 可靠性评分为 A，0 bug；
• 安全性评分为 B，没有重要漏洞。

具体定义可以查阅文档：https://docs.sonarqube.org/latest/user-guide/metric-definitions/