1 定义
先来看下【千行代码缺陷率】是怎么回事？
- 一千行代码产生的缺陷，这个概念在CMMI中有定义；
- 计算公式为：
(bug数/代码行数)*1000‰。
2 目的
- 为了度量产品质量，通过这一数据督促开发提高代码质量，提高产品质量。
3 CMMI定义
| CMMI级 | 千行代码缺陷率 |
|---|
| 1级 | 11.95‰ |
| 2级 | 5.52‰ |
| 3级 | 2.39‰ |
| 4级 | 0.92‰ |
| 5级 | 0.32‰ |
4 指标的缺点
- 从这个指标我们可以看出，分子越小，分母越大，质量越好，表面看似简单的数据呈现，其实这样的衡量太过单一；
- 我们举个例子：某公司的千行代码缺陷率要求,CMMI3级，即
2.39‰ ，以下是三个程序员的对功能M模块的进行实现：
例一：
A程序员用20万行代码实现了功能M，产生了bug20个，千行代码缺陷率为1.0‰；这个指标符合公司的要求。但是A的代码极度复杂，为了修改bug，代码耦合性很高，维护成本极大；
例二：
B程序员用5000行代码实现了功能M，产生了bug20个，千行代码缺陷率为4.0‰，不满足公司的标准要求。但是B的代码非常精练，可读性高，便于维护，移植性好；
例三：
C程序员用5000行代码实现了功能M，产生了bug30个，千行代码缺陷率为6.0‰，不满足公司的标准要求。但是C非常好学，他很努力在向B学习，争取使得自己的代码更具有可读性；
- 然后呢，公司根据以上三个人的千行代码缺陷率，定义三者的绩效为A最好，B不及格，C被淘汰了；
- 过了N年，这个M模块需要重构，A程序员的代码维护起来非常困难，面对庞大的代码，因为可读性差，维护会产生很多bug；B程序员的代码很容易进行修改，感觉很简单；C的代码仅次于B。但是呢最后评绩效的时候，仍然是A最好，B不行，为什么？
大家都认为A很牛逼，代码量庞大；B的代码太简单了。
所以从此刻开始，公司的开发同事就使劲的增加分母，让代码足够大，这样处于分子的缺陷再多，也会绩效很好。而B优秀的代码被抛弃，像B这样的程序员被淘汰。那么可想而知这个公司的最终之路是什么？？
5 改进
- 综上所述，现在的产品质量不能单一的使用千行代码缺陷率来表示，起码我是这样认为的，那我们用哪些指标更好呢？
- 博主通过查阅资料得到以下指标：
5.1 圈复杂度
- 圈复杂度越高的代码会有越多的Bug；
- 圈复杂度反应了代码的耦合度；
- 推荐的圈复杂度不要超过10；
- 测量圈复杂度的工具：
Source Insight、Code Metrics、Cobertura
5.2 平均缺陷修复时间
- 平均缺陷修复时间能够更好地反映代码本身的质量状况，以及团队的成熟程度；
- 平均修复时间较长的代码都是复杂度高，耦合度高的代码；
- 平均修复时间短的代码都是结构相对清晰，命名规范，容易理解，扩展和变更的代码。
6 其他推荐指标
以下这些仅供参考：
- 缺陷修复率；
- 重新打开缺陷占比；
- 严重及以上缺陷占比；
- 缺陷遗留DI值等。