千行代码缺陷率

首先我们来看看，千行代码缺陷率是怎么定义的？

    缺陷率 = 缺陷数量/ (代码行数/1000)

然后看组织如何关心这个数字

    越小越好

那么结论是什么？

    没有能力减少缺陷数量，就加大代码行数呗

一些常见的招数

        把 {单独占一行

       把 }else { 写成 

            } 

            else

           {

   上面这些还只是影响到代码可读性，下面这些就有些奇葩了。

         把定长循环分开写，写成顺序方法

         把配置文件的行数统计进去

   而下面这些就令人发指了

        复制、粘贴

        重新发明轮子  

-----------------

      我们不怎么采用这些招数  ，可以用这个数字了吧? 

      统计“千行代码缺陷率”和“每日生产代码行数”一样，都是没经过大脑思考，而直接打算把优秀员工踢出团队的懒人式管理方式。

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

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

----------------

      我们团队的人能力都差不多，总可以用这个来衡量吧？

      这句话的意思是在暗示“我们的团队都很平庸”吗？如果是这样，那就更不要用这个数字了。因为平庸的人无法像优秀的人那样

          —— 爷写的太高深你们看不懂  ——来自我安慰。他们经常会在这样的毫无根据的数字面前自信心被打击。

-----------------

      公司管理体制要求，我们得统计吧？

       不可否认，这么明显的一个错误，还是有很多公司在犯，而且不犯这个错误都不好意思跟人打招呼。（还是以前那句话，SQA/PPQA都是一些不想、不愿、不能写代码的人从事的，别指望他们做什么正确的事。我用一个比较恶毒的词儿形容这些人：Salary Thief）

       如果你的公司还在犯这个错误，那么你有若干种选择：

                  1. 证明这个是错误的，然后从公司统计数据中抹掉它

                  2. 忍受，然后假装自己很平庸，写很长的代码来稀释缺陷密度

                  3. 离职，寻找一家不统计这个数字的公司

           也许还有更多的选择。

       推荐看看 张松著的 《精益软件度量》