软件开发之大忌：想当然

写这篇文章源于前几天与同事关于一个需求的讨论，大致的场景是这样的：

有一个商品有多种品类供交易，业务部门想注销掉其中的一个品类(数据库中更改一个标志位的值)。数据库中的这张品类表，由我们的系统每天从数据库中导出成文件，文件提供给其它系统使用，我们的系统在导出这张表的时候是全量导出的，并没有区分品类是否被注销。这时，一个使用这个文件的系统提出说，如果文件中存在已经注销的品类，会对他的系统造成影响，认为这个文件中应该只包含未注销的品类。需求一听觉得这个说法很合理呀，于是提出让我们修改这个文件的导出方式：过滤掉已经注销的品类。组里的其他同事接到这个需求的时候也觉得很合理呀：“已经注销的品类还导出干嘛呢？”，于是来找我讨论具体怎么改以及上线时间什么的……我仔细想了想，却认为这个文件的导出方式不能这么简简单单、自己“想当然”地说改就改了。

首先，这个文件的使用方并非只有提出问题的那一个系统，还有其它的系统也在使用这个文件，而且我们也不知道其它系统使用这个文件的方式是怎样的，我们就这样自己“想当然”地把这个文件的导出方式、也就是文件的内容给改了，是否会对其它那些系统造成影响呢？

再者，由于我是后来加入这个项目的，所以并不确定这个文件在设计之初，其内容究竟是“未注销的品类”，还是“全量的品类”数据？因此就存在一种可能，其实是那个提出说有影响的系统，一直在“想当然”地认为这个文件的内容是“未注销的品类”(数据库原来一直没有注销过品类)。

此外，我们的系统在导出这个品类表的时候，实际是将注销标志一起导出的，也就是说即使导出的文件包含了“全量的品类”，使用这个文件的系统实际是可以自行判断某个品类是否已被注销的。

最后，我们给需求部门反馈的评估意见是：由于该数据使用方不止一个系统，应由使用该文件的所有系统共同评估是否可以修改文件的导出方式，即文件的内容。

当然，这只是我们项目中的一个小场景，但由此我想到的其实是我们程序员在日常的软件开发过程中，经常会犯的一个错误，就是自己“想当然”地认为系统的某个行为应该是怎样怎样的，这经常会造成的一个结果就是如上面描述的场景，最后可能会导致多个系统间的协作出现问题；还有一个可能的结果就是，最后程序员们辛辛苦苦开发出来的软件功能，并不是需求方或业务部门真正需要的——这也正是这些年敏捷开发模式备受推崇的一个原因。

所以说，“想当然”是程序员软件开发的一个大忌，我们在设计系统的某个行为逻辑的时候，一定要多方考虑、审慎评估，而不能只是盯着自己负责的那一块。

个人拙见，欢迎讨论指导。