我的论断是：统计 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 度，我要被烤化了。’，能够把它扩写成：
a = ('今天天气'
'居然有 40'
'度，我要'
'被烤化了。'
)甚至再进一步，扩写成：
a = '今天天气'
b = '居然有 40'
c = '度，我要'
d = '被烤化了。'
e = (a
+ b
+ c
+ d
)
a = e这三种写法的成果齐全一样。
还有些性能，本来就一行原生代码搞定。然而为了减少行数，成心应用第三方库。这样第三方库的代码行数也就统计进去了。代码总行数减少，相当于分母增大，千行代码 Bug 率就降下来了。
要缩写也简略，在 Python 外面，如果应用 lambda 表达式，通过十分炫技反人类的写法，你能够把惯例要 40 行的代码缩成 1 行。然而这样的一行代码基本没法保护。
为什么 Bug 率是有意义的？
对于一个有理论用途的我的项目代码来说，Bug 数是一个系统误差，只能设法缩小，然而没有方法变成 0。
同样实现一个性能，好的程序员能提前预判到他人会怎么应用，提前解决好非法逻辑和不合理的数据流程，从而升高 Bug 数。而差的程序员，写进去的代码，他人一用就出问题。因而，用 Bug 率来评判程序员程度，我感觉是正当的。然而从 Bug 数到 Bug 率，这个计算方法应该要精心设计。
开发阶段
如果公司有 QA 的话，在软件开发阶段，个别产品经理会先提出需要，而后拉上开发和 QA 一起评测需要。QA 会在需要评审会后，设计测试案例。这些测试案例是公开的，每个开发都会看到。
这些公开的测试案例，我感觉能够用来作为分母。程序员写好了代码，却无奈通过其中的局部测试案例。那就是程序员的程度不行。失败的测试案例数 / 所有公开的测试案例数。能够作为掂量程序员程度的参考指标之一。好的程序员应该尽量让这个比值为 0.
但有时候，在测试的过程中，QA 可能会长期减少测试案例，这些案例是程序员提前不晓得的。那么这些案例如果测试失败了，也能够作为一个评判指标，用来评判程序员是否有提前预防的能力。但偏心起见，能够给他乘以一个小于 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 指数：
程序员 Bug 指数 = 开发阶段 Bug 率 * 开发阶段系数 + 程序员线上 Bug 率 * 线上阶段系数这个指数越高，阐明程序员能力越差。
最初还是强调一下，以上公式是我拍脑袋想进去的，仅做参考。但我认为它的价值应该比千行代码 Bug 率高得多。
最近整顿了几百 G 的 Python 学习材料，蕴含新手入门电子书、教程、源码等等，收费分享给大家！想要的返回“Python 编程学习圈”，发送“J”即可收费取得