本周讨论会上，针对“千行代码缺陷率”讨论了很久：
千行代码缺陷率 = 缺陷数量 / 每千行代码
按照上述的公式来看，缺陷的数量越少表示质量越高。而提交的的代码越多，可以容忍的缺陷数量也就越多。乍一看，这个公式应该是可以很好地检测代码质量的。然而，事情并不是这么简单，在实际落地时大家会面临两个选择：
1、增大分母——提高代码行数——简单；
2、减小分子——减少缺陷数量——难。
如果我们对它进行刻意度量甚至考核，大家会选择相对容易的方案，这个虽然说通过其他的手段（codereview）可以补偿，但本质上就会让它变成一个目标和方法背道而驰的指标。
而选择稀释代码就是个最简单的策略，那么稀释代码的最佳策略是什么？复制粘贴，复制粘贴的最大问题是什么？引入更多的bug。这个结果显然不是我们想要的。为什么会出现这样的情况呢？这背后的最重要的原因就是：功能的多少和代码行数不成正比关系，也不呈现正相关关系。
那该如何解决这个问题呢？其实我们只需要跳出来重新定义一下问题：我们追求的是产品最终的交付质量以及缺陷发生后的恢复速度，所以可以从以下3个指标去来展开质量度量：
1、CC，圈复杂度
圈复杂度越高的代码越容易引入缺陷，这个是业已被证明了的，圈复杂度反应了代码的耦合度，所以大家要写低耦合高内聚的代码。
2、DDP，缺陷探测率
缺陷探测率越高，也就是QA发现的缺陷越多，发布后线上用户发现的错误就越少，可获得较高的测试投资回报率。
3、MTTR，平均缺陷恢复时间
发生缺陷并不可怕，可怕的是修复的时间过长。平均缺陷修复时间能够更好地反映代码本身的质量状况，以及团队的成熟程度。往往平均修复时间较长的代码都是复杂度高，耦合度高的代码。而平均修复时间短的代码都是结构相对清晰，命名规范，容易理解，扩展和变更的代码。
网友评论