统计千行代码Bug率,有没有意义?

我的结论是:统计Bug率有意义。但是统计千行代码Bug率没有意义。

为什么千行代码Bug率是没有意义的?
某公司最近出了一个方案,用来量化程序员的工作绩效。叫做千行代码Bug率。在一个统计周期内,程序员每增加或者修改的代码行数与QA发现的Bug数,根据如下规则计算Bug率:

1000行代码,1个bug,那么Bug率是100%;
2000行代码,4个bug,那么Bug率是200%;
5000行代码,3个Bug,那么Bug率是60%
n行代码,m个Bug,那么Bug率是m / n * 1000
先不考虑这个规则本身是否有问题。我觉得,所有和代码行数挂钩的绩效统计,都是没什么意义的。因为代码行数是可以刷的。如果某个绩效需要代码行数越少越好,那么可以使用行数少的写法;某个绩效需要代码行数越多越好,那么可以使用行数多的写法。

例如,对于字符串赋值:a = ‘今天天气竟然有40度,我要被烤化了。’,可以把它扩写成:

  1. a = (今天天气
  2. 竟然有40
  3. 度,我要
  4. 被烤化了。
  5. )

甚至再进一步,扩写成:

  1. a = 今天天气
  2. b = 竟然有40
  3. c = 度,我要
  4. d = 被烤化了。
  5. e = (a
  6. + b
  7. + c
  8. + d
  9. )
  10. a = e

这三种写法的效果完全一样。

还有些功能,原本就一行原生代码搞定。但是为了增加行数,故意使用第三方库。这样第三方库的代码行数也就统计进去了。代码总行数增加,相当于分母增大,千行代码Bug率就降下来了。

要缩写也简单,在Python里面,如果使用lambda表达式,通过非常炫技反人类的写法,你可以把常规要40行的代码缩成1行。但是这样的一行代码根本没法维护。

为什么Bug率是有意义的?
对于一个有实际用处的项目代码来说,Bug数是一个系统误差,只能设法减少,但是没有办法变成0。

同样实现一个功能,好的程序员能提前预判到别人会怎么使用,提前处理好非法逻辑和不合理的数据流程,从而降低Bug数。而差的程序员,写出来的代码,别人一用就出问题。因此,用Bug率来评判程序员水平,我觉得是合理的。但是从Bug数到Bug率,这个计算方法应该要精心设计。

开发阶段
如果公司有QA的话,在软件开发阶段,一般产品经理会先提出需求,然后拉上开发和QA一起评测需求。QA会在需求评审会后,设计测试案例。这些测试案例是公开的,每个开发都会看到。

这些公开的测试案例,我觉得可以用来作为分母。程序员写好了代码,却无法通过其中的部分测试案例。那就是程序员的水平不行。失败的测试案例数/所有公开的测试案例数。可以作为衡量程序员水平的参考指标之一。好的程序员应该尽量让这个比值为0.

但有时候,在测试的过程中,QA可能会临时增加测试案例,这些案例是程序员提前不知道的。那么这些案例如果测试失败了,也可以作为一个评判指标,用来评判程序员是否有提前预防的能力。但公平起见,可以给他乘以一个小于1的系数,降低它的权重:

  1. 开发阶段Bug = (已经公开的测试案例数 + 系数 × 临时增加的测试案例数) / 总测试案例数

说个题外话,今天我们不考虑单元测试数、单元测试覆盖率这种问题。因为据我所知,国内互联网公司会主动写单元测试的程序员太少了。有时候,一个原本要写单元测试的优秀程序员,进了某些大厂以后,迫于业务和工期压力,也逐渐放弃了。所以我们今天只考虑QA的测试案例。

线上阶段
如果只看QA的测试案例,可能会出现面向QA编程的问题。因为人是很聪明的,上有政策,下有对策。QA的一个测试API接口的案例,输入5,输出10.程序员直接在代码里面判断,如果输入是5,直接返回10,跳过中间的所有逻辑。这样就能100%通过QA的所有测试案例。但是这样做对产品本身是没有价值的。

市场是检验代码质量的重要标准。程序质量好不好,上线以后,让用户来评测。

用户反馈的Bug,也可以用来评价代码的好坏,进而反映出程序员的能力高低。但需要考虑下面两个情况:

同一个功能,两个程序员实现:

  • A程序员写出的功能一上线,用户一用就报Bug
  • B程序员写出的功能上线很久了。几十万个用户都正常使用,有个沙雕用户乱操作,偶然暴露出了一个Bug。

大家凭主观判断都知道,B程序员应该比A程序员好。

我们再来考虑第二种情况,A程序员实现X功能,B程序员实现Y功能:

X功能每天会被使用几百万次,一周就发现了二十多个Bug
Y功能一个月总共就被用了3次。没有发现Bug
这种情况下,我们没有办法根据Bug数来判断AB两个程序员谁更好。也许B程序员去写X功能,一天就会被发现上百个Bug也说不定。

因此,根据这两种情况,我拍脑袋总结了一个经验公式:

某功能线上Bug率 = Bug数 / (log(功能使用次数 + 1) + 1)

其中的log是以10为底的对数。因为一个功能很轻松就能使用上百上千次,而Bug数一般来说就是个位数或者两位数。因此对使用次数求个对数,避免Bug率太小。公式中的两次+1。一次是因为不能对0求对数,另一次是分母不能为0.

对程序员开发的多个线上功能的Bug率统计,我们可以这样计算:

程序员线上Bug率 = A功能线上Bug率

功能重要性系数 + B功能线上Bug率

功能重要性系数 + ……
其中,相同重要性的功能,他们的功能重要性系数应该是相同的。不同重要性的功能,功能越重要,这个系数就越大。

这里,这个系数应该用功能重要性系数还是功能复杂性系数,我们可以讨论一下。我个人是觉得用重要性比较好。一方面是代码复杂性不好量化。第二是因为程序员的代码质量和业务是不能分开看的。对于重要的功能,应该优先做,应该更用心。在更用心的情况下bug还那么多,不就说明能力差吗。对于不重要的功能,最后做,可能后面时间来不及了,赶工完成有一些Bug。但是因为这个功能没什么人用,对业务影响不大,有一些Bug也没什么。

拍脑袋综合公式
综合开发阶段与线上阶段,我们可以得出一个综合公式。由于一般来说,某某率的值范围应该是0-100%,这两个公式合在一起以后,结果很可能大于1.因此我们改个名字,叫做程序员Bug指数:

  1. 程序员Bug指数 = 开发阶段Bug * 开发阶段系数 + 程序员线上Bug * 线上阶段系数

这个指数越高,说明程序员能力越差。

最后还是强调一下,以上公式是我拍脑袋想出来的,仅做参考。但我认为它的价值应该比千行代码Bug率高得多。

以上就是本次分享的所有内容,如果你觉得文章还不错,欢迎关注公众号:Python编程学习圈,每日干货分享,内容覆盖Python电子书、教程、数据库编程、Django,爬虫,云计算等等。或是前往编程学习网,了解更多编程技术知识。


文章标签:

原文连接:https://juejin.cn/post/7122697794053210120

相关推荐

Flask框架——消息闪现

34个图片压缩工具集合,包含在线压缩和CLI工具

入门即享受!coolbpf 硬核提升 BPF 开发效率 | 龙蜥技术

基于 OPLG 从 0 到 1 构建统一可观测平台实践

全链路灰度在数据库上我们是怎么做的?

冴羽答读者问:过程比结果重要吗?如果是,怎么理解?如果不是,又怎么解?

接口文档管理工具,选yapi 还是 Apifox? 这里列出了两款软件的深度分析,看完再下载不迟。

基于 Docker 来部署 Vue 或 React 前端项目及 Node 后端服务

三十岁的我,自由了!

如何实现带timeout的input?

统计千行代码Bug率,有没有意义?

814. 二叉树剪枝 : 简单递归运用题

【综合笔试题】难度 3.5\u002F5,多解法热门二叉树笔试题

为什么设计的软件不好用?那是因为不熟悉软件开发模型!一文熟悉软件开发模型

作为前端,我是这样从零实现CI\u002FCD二(node服务部署及前后端联调)

极智开发 | 讲解 Nginx 特性之一:反向代理

Netty 案例之 IM 方案设计

从 Google 离职,前Go 语言负责人跳槽小公司

最终一致性性分布式事务 TCC

不谈源码,聊聊位运算的实际应用