今天在新浪微博上又看到有人讨论千行代码缺陷率，还讨论的很细致——怎么计算，怎么统计....
引用郭德纲的一句话：统计那玩意儿没用，一句话解决你心中所有疑惑。（原文是：学那玩意儿没用）
首先我们来看看，千行代码缺陷率是怎么定义的？
缺陷率 = 缺陷数量/ (代码行数/1000)
然后看组织如何关心这个数字
越小越好
那么结论是什么？
没有能力减少缺陷数量，就加大代码行数呗
一些常见的招数
把 {单独占一行
把 }else { 写成
}
else
{
上面这些还只是影响到代码可读性，下面这些就有些奇葩了。
把定长循环分开写，写成顺序方法
把配置文件的行数统计进去
而下面这些就令人发指了
复制、粘贴
重新发明轮子
-----------------
我们不怎么采用这些招数 ，可以用这个数字了吧?
统计“千行代码缺陷率”和“每日生产代码行数”一样，都是没经过大脑思考，而直接打算把优秀员工踢出团队的懒人式管理方式。
因为优秀的程序员是通过减少代码行数来增加功能的。
虽然没有明确鼓励增加代码行数，但是这个计算结果对于优秀的员工来说是相当的不公平。它隐含的推广了“尽量增大代码行数”这个意思。
----------------
我们团队的人能力都差不多，总可以用这个来衡量吧？
这句话的意思是在暗示“我们的团队都很平庸”吗？如果是这样，那就更不要用这个数字了。因为平庸的人无法像优秀的人那样
—— 爷写的太高深你们看不懂 ——来自我安慰。他们经常会在这样的毫无根据的数字面前自信心被打击。
-----------------
公司管理体制要求，我们得统计吧？
不可否认，这么明显的一个错误，还是有很多公司在犯，而且不犯这个错误都不好意思跟人打招呼。（还是以前那句话，SQA/PPQA都是一些不想、不愿、不能写代码的人从事的，别指望他们做什么正确的事。我用一个比较恶毒的词儿形容这些人：Salary Thief）
如果你的公司还在犯这个错误，那么你有若干种选择：
1. 证明这个是错误的，然后从公司统计数据中抹掉它
2. 忍受，然后假装自己很平庸，写很长的代码来稀释缺陷密度
3. 离职，寻找一家不统计这个数字的公司
也许还有更多的选择。
推荐看看 张松著的 《精益软件度量》