你的项目统计这些数据吗？(2)

前面我们曾经讲过《你的项目统计这些数据吗？》，这里我们在补充一些内容。

1. bug原因分类

    bug产生的原因只有一种，那就是代码编写错误，没有什么设计错误还是需求错误之类的荒谬分析。如果牵强的分类会发生什么情况，程序员为了减轻自己的责任，将问题尽量的归结为：

     设计不充分 —— 设计人员的问题     需求不明确 —— 需求分析人员的问题
     测试用例不足 —— 管理人员的问题——他没给我足够的时间用来测试。

然而这些统统都不是问题的真正原因，bug产生的原因就只有一种：代码书写错误。
     比如那个二分法查找的著名bug：

     mid =  (left + right) / 2;会导致当left + right > Integer.Max的时候产生负数，从而引起数组越界。

     如果让你来分类你会怎么分？
         - 设计错误         - 基础API不熟悉
         - 测试用例不充分
     是三个常见的分类方式。然而这么分类的意义何在？
      设计错误，那以后就能够规避设计上不出错误吗？
      API不熟悉，那以后就能够加深API的理解吗？
      测试不充分，那以后就能够做充分的测试吗？

      答案都是否定的，因为
       引起设计错误的原因是时间不足，所以复查不充分。
       实际上作者可能知道>>>的用法，但是没有考虑到这里的越界情况，如果给他足够多的时间（据说发现这个bug用了12年）
       测试不充分的原因仍然是时间不足。

      所以，代码的Bug就是代码的bug，不应该归结为其他原因，这只是编程人员减轻自己责任的一个借口而已。

2.bug产生阶段分类

     做这个分析的目的是为了从上层来更早的提高质量。然而，只要把软件工程分阶段了，就违背了把质量更早的提高这个目标。这个将在《荒谬过程》一文中详细阐述。

     所以与其做bug产生阶段分类，不如想想如何才能够去掉阶段吧。

     更何况，每次项目统计出来的数据总是差不多，也就是分析了也没有改进，那么分析有什么必要呢？

3.各阶段工时分布

    和上述问题一样，把软件开发分阶段就是违背了早期提高质量这个目标的。所以，也没有必要统计各个阶段的工时分布，况且，统计工时还需要耗费工时——这也是目标和行为背离的一个行为。

4.bug未发现的原因

   bug未发现的原因也只有1个，那就是测试不充分。   统计这个数据的原本目的是为了能够通过bug未发现的原因进行分类分析，从而能够提升质量，减少提交给客户的bug数量。然而，这一统计本身并不能达到这个目的，反而只是浪费工时而已。
   请参照《到底应该测试多少（1）——尽量的全面》和《到底应该测试多少（2）——不要放过细节》这两篇文章来看看测试中到底有多少遗漏。另外，回归测试的时候采用影响性分析——>有选择的测试这种懒人思维也是导致测试不充分的原因。

   所以要想尽量减少遗漏给客户的bug，那就从如下几方面着手吧：

    A.增加测试用例种类
    B.改进测试手段 —— 引入自动测试，以降低回归测试成本
    C.改进测试流程 —— 不论何时提交，都要全面测试

   否则，做bug未发现原因分类这种分析也就是聊以慰藉而已。

5.Review的问题分类

    Review的时候问题可能分为：风格的问题、逻辑的问题、规范的问题、需求吻合度的问题等等若干种。但是做这种分类的意义只在于证明做了很多机器应该做的事情。

    关于这一点将在《走马看花的代码复查》中详细阐述。

   Review的问题应该只有一种：耦合度偏高

   风格的问题、规范的问题属于机器的工作，需求吻合度不应该在Review时才发现。而逻辑的问题通过Review发现的可能性很小。只有耦合度问题可以在Review中最容易发现，也应该在Review中发现。

6.文档页数

   文档该不该写都有一定的疑问，更何况去统计页数。另外，页数是一个很不靠谱的概念。字体的大小，间距的大小，换行的频度都可能会影响文档的页数。更为重要的是，统计文档的页数对于软件质量改进或者过程改进毫无帮助。