你还在度量「千行代码Bug率」吗？

作者：常柱，现58到家技术平台负责人，负责到家技术体系的规划和团队建设。58同城会员体系创建者和技术负责人，搭建了58同城核心商业产品网邻通的业务和技术架构。有十年以上的技术研发和团队管理，对后端技术，敏捷团队等十分关注。也可以关注他的订阅号「 架构未来 」获取更多干货。

管理学大师德鲁克说：你如果你无法度量它，就无法管理它。要想做有效的管理，就很难绕开度量的问题。

软件开发的过程或者技术团队的管理也存在着如何去合理的度量效率的问题。而度量是把双刃剑，度量具有极强的引导性。度量指标会激励团队重视并改善能够度量元素，也会导致你忽视无法度量的元素，并使得问题进一步恶化。所以，选择合适的度量指标考核技术团队成员，需要慎重考虑。例如，代码行数和千行代码Bug率指标就值得商榷。

什么是千行代码Bug率

首先我们来看一下，千行代码Bug率是怎么定义的：

千行代码Bug率 = Bug数量/ (代码行数/1000)

度量的标准 ：千行代码Bug率数值越小质量越好。

关于CMMI级别中和BUG率相关的信息如下：

考核千行代码Bug率的问题

从考核千行代码Bug率来看，主要存在两个方面的问题：
首先，从考核标准上来说，Bug率数值越小就说明越好，基于这个结果，会引导团队成员做出一些对长远和整体效率无益的行为，例如：
1. 增大基数，增加无意义代码
2. 把定长循环分开写，写成顺序方法
3. 把可配置信息写死到代码中
4. 大量的复制、粘贴代码
5. 重新发明各种轮子

统计“千行代码Bug率”和“每日生产代码行数”一样，都是没经过大脑思考，而直接打算把优秀员工踢出团队的懒人式管理方式。特别是对从事智力型工作工程师来说，是很不合适的考量指标。

因为优秀的程序员是通过减少代码行数来增加功能的。

千行代码Bug率，虽然没有明确鼓励增加代码行数，但是这个计算结果对于优秀的员工来说是相当的不公平。它隐含的推广了“尽量增大代码行数”这个意思。

其次，从考核阶段看，Bug率的数据主要产出在研发阶段的后期，及提交测试后产出bug数。从项目的研发阶段和效率价值金字塔来看，其对项目的整体质量方面更多的聚焦在微观层面问题，整体的质量的影响范围会较小。而前面几个阶段的缺陷，会影响整个项目的进度，甚至导致项目失败，管理者和团队更应该将风险控制和度量指标向前移。

研发阶段和效率价值金字塔

如何更合理的度量质量

如果考核千行代码Bug率不能很好的解决质量核心问题，那我们还有那些方法和方案来提高项目的整体质量呢？
个人觉得，我们还是从项目的研发阶段和效率价值金字塔出发，重整体上去把控质量，上下游一体，从源头开始：

1. 需求 的评审
2. 架构设计方案评审
3. 代码模块设计， 包的依赖的规划 ， 接口的设计的review
4. 代码的review的机制
5. 测试用例评审
6. 使用代码检测工具， 自动发现问题

过程评审是最有效也是成本最低的质量和效率保证和提升的手段。另外，过程评审还是迅速提高新人能力及其成果物的规范性的一个有效手段。
但是过程评审，也存在一些问题：
1. 前期过度依赖于团队的人员素质
2. 规则的定义也比较难，产出不好量化
3. 评审耗时多
4. 团队的意识不一致

对于过程评审的实施，最核心的统一团队意识，团队意识不一致时，效果一定不好。 意识意识不一致，在资源的投入上就会缩手缩脚；只有把过程评审做到位，才能体会到评审活动的高效，避免那种走马观花式的“评审”，是浪费时间，不是真正的评审。到位地完成评审后，会有那种对系统质量“踏实了”的感觉，过程中辅以严密的变更管理和风险控制手段，系统质量出大问题可行性会很小或者近乎为零。

系统质量是要靠上游工程做出来的，而且上游的工作质量会更为重要，上游的问题的影响范围将更广，对效率和价值的影响更大，应该是我们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关，是十分低效，而且代价是非常昂贵的。