ECMBoss企业内容解决方案项目系列之（十）Bug那些事儿

    如今，项目已经进入尾声，各个功能模块基本已经开发完毕，我们的主要工作基本上都是修Bug。由于我负责的模块完成的比别人早一些，因此除了处理自己的Bug之外，有时候还要处理别人的Bug。因为修复的Bug次数多了，见的种类多了，就对这些Bug出现的情形进行了一下分类，反正闲着也是闲着嘛！

 

 

    Bug通常分为三类：一般、严重、非常严重。非常严重级别的Bug非常罕见，都是致命的错误，一旦出现，通常都会造成项目延期。这种级别的Bug又分为两种，一种是需求错误，另一种是界面展示很差。非常严重级别的Bug我见的不多，总共两次。都是需求人员把需求弄错了，从而造成开发人员开发出的功能与客户需求不一致（需求一致才怪呢）。界面展示很差的我没遇到过，只是听朋友说起过。

    一般和严重级别的Bug很常见，通常是根据界面展示和功能实现难易来判断的。如果由需求人员提出的Bug，都是按照界面展示效果判断严重和一般的。如果界面展示丑陋，即使功能再强大易用，需求人员也可能给你开一个严重的Bug。因为需求人员是站在客户（不懂技术）的角度来看问题的。如果由开发人员内部提出的Bug，通常都是按照功能实现的难易度来判断Bug的级别，因为这样，可以确定开发人员每天可完成的Bug数量。

    我最近几乎每天都在修Bug（偶尔有新功能提出），基本上数量在10个左右，Bug的严重程度都是一般和严重。原来听一同事说，每天修几十个Bug，我感到很好奇，这么多的Bug，那Bug的粒度该有多细，我能想到这么多数量的Bug只能是没有做数据验证，初次之外，我实在想不到在哪些地方能够产生出如此多数量的Bug。

    目前来说，我所修的Bug主要来自于两个地方。一是因为系统架构重构引起的功能不可用，二是模块功能点迁移造成的功能不可用。由系统架构重构引起的功能不可用通常是由于原来所提供的接口已经不再对外支持，或者接口的实现已经被重写。由模块功能点迁移造成的功能不可用，通常是结构不严谨所造成，比如我最近处理的searchResult，就是由于没有对输入的数据进行有效性验证，从而造成读入脏数据，产生异常。

    另外，在处理Bug时，有时候会修改基类。我的建议是不在迫不得已的情况下不要去修改基类，即使这个基类的严谨性不是很好。

    附言：ECM项目快要结束了，该系列的文章也快终止了，真心感谢一直关注我的博文的博友们，你们的关注，是我分享的动力，谢谢你们！