转发同事总结：一个BUG引发的血案（起因篇）

序：

博文《公司的一个“新记录”：项目初验不成功》记录了项目P初验不通过的事情，项目经理P在而后的一个星期顺利通过初验后，将以往的经验总结成文，在部门内部进行相互学习。应Stud_100等读者的要求，现在将同事P的总结共享如下，由于篇幅原因，分起因篇、经过篇、结果与总结，本期刊登他的起因篇。

 

原文如下：

上周五，项目P的验收因为一个我们看来小小的bug被业主C部门用户在初验会上拒绝了。虽然这个问题看起来是由于种种偶然造成的，但从某种程度上说,这也是偶然中的必然。

而后的一个星期里，几经波折，项目涉及到的8个各个单位干系人最终都在验收报告上签了名。现在到了需要总结问题的时候，下面我将代表项目组具体阐述一下这个问题的产生过程，以及我们认为可以有所改善的地方。

1. 起因

EVENT1：字段的倒置   TIME：初验会前4个月

财务报表是一种很复杂的东西，每个字段的名称都很长很拗口。于是开发人员在开发过程中把“在建工程科目年初金额”（CONS_PRJ_SUBJECT_YR_BEGIN_AMT）和“工程物资科目年初金额”（MAT_SUBJECT_YR_BEGIN_AMT）弄反了。

数据库设计人员其实是采用了直译的方法，字段名和中文名是一一对应的，只是问题出在由于名字太长，采用了缩写，比如CONS是construction，MAT是material。而开发人员在看不太懂的情况下，发挥了博闻强记的功力，一个个手工对应，于是乎出错也就在所难免了。

SOLUTION1：统一语言

设计人员应对开发人员阐明缩写规则，开发人员在明白缩写含义的情况下出错的概率会小很多。同时开发人员在不明白的情况下，也应该主动沟通了解字段名的具体意义，而不是强行记忆天书，苦了自己也更容易出错。

 

EVENT2：越智能越好吗  TIME：初验会前4个月

单纯来看，XX信息的编辑其实是比较容易实现的，但是我们想达到智能一点的目的，在一个月未填报的情况下，把未填报的XX也列出来。这样就不仅仅是临时表的增删改查了，必须要关联到正式表，再做一些decode的判断。于是SQL就变得很复杂了。

项目组派出数据库专家作为设计角色来协助开发人员编写这个SQL。设计人员觉得光是这样还不够智能，如果一个XX在关帐后没填写的情况下，自动把XX的各个填报金额汇总上来不是更好了吗？于是指导开发人员按照这种思路写完了SQL。

可惜的是，这个新增功能被客户否定了。原因很简单，用户导出的数据和他当初导入的不一样，作为严谨的会计，这点会导致他无法审核数据。否定是理所当然的。

另外一点，这个问题本来只存在于总部.但是系统对于用户来说是黑箱，总部发生问题了，他自然会质疑是不是所有下属机构的数据都被计算错了。恰巧下属机构公司用户导入的数据刚好是有问题的，所以用户对系统的信心严重降低。我们扛了另一个不属于我们的黑锅。在同用户解释时多费了很多口舌。这个算是此问题的副作用。

SOLUTION2：需求导向和质量意识

设计人员在设计一项关键功能时应征询需求人员意见（需求人员如仍无法确定应询问用户），而不是盲目实施一项新功能。同时开发人员也应站在用户的角度提出自己的质疑（一般任何系统的导出都应该要和导入一致，否则用户无法核对数据），而不是设计人员说什么就是什么，不光要know how，还应该要know why。

这个问题也告诉我们，应该提升对系统质量的重视程度。很多情况下的bug都是我们开发中的一个小小的失误，但由于用户对系统内部运转的不了解，常常会存在放大问题的倾向。这和需求变更时，用户存在低估变更工作量的倾向是同一个道理。并不是用户刻意难为我们，而是立场不同，认知程度不同导致的结果。所以，只有端正对系统质量重要性的认识，充分了解到所谓“小bug”造成的严重后果，才能尽量避免这种情况，建立客户对我们系统的信任。因为真正等到问题发生，用于解决问题、重建客户信心比避免bug产生所花费的功夫要大得多得多。

——未完待续