再说千行代码缺陷率

本文转载至:http://www.cnblogs.com/stephen-wang/archive/2013/07/04/3171381.html


今天在新浪微博上又看到有人讨论千行代码缺陷率,还讨论的很细致——怎么计算,怎么统计....

引用郭德纲的一句话:统计那玩意儿没用,一句话解决你心中所有疑惑。(原文是:学那玩意儿没用)

 

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

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

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

    越小越好

那么结论是什么?

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

一些常见的招数

        把 {单独占一行

       把 }else { 写成 

            } 

            else

           {

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

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

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

   而下面这些就令人发指了

        复制、粘贴

        重新发明轮子  

 

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

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

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

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

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

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

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

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

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

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

      公司管理体制要求,我们得统计吧?

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

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

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

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

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

           也许还有更多的选择。

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值