一个需求变更的故事

昨天我们的物流部门提了一个需求，希望我能为他们做一张出库明细报表，以便他们统计和核对数据。嗯嗯，这个很简单的说，复制一个类似的模板，替换下数据源，按日期分组，20分钟搞定！

这里简单插一下，介绍下我们系统中的报表的实现。报表是采用的第三方控件FastReport，通过设计报表模板—>定义报表（选择模板、分期规则、会计主体、报送对象）—>生成报表（即时、按分期规则自动）。

物流部的同事用即时报表功能看过后提了个新的需求或者是BUG，没有按仓库分组呀！亲！

汗呀，疏忽了，赶紧加上，5分钟搞定！然后。。。能不能按客户类型分一下呀？可以！还没开动呢，能不能按产品系列分一下呀？嗯？？？可以是可以的，不过，你这是要闹哪样呀？这样分真的好吗？我知道的业务不需要分这么细的呀。

咳咳。。。我们每天要做一个汇报，你看，我这个。。。。巴拉巴拉。。。

哦哦，明白了，亲，你这是需要一个汇总表呀，拜托说明白好不好。我们物流的妹子表示很无辜。。。。然后我又复制了一个模板，替换了数据源，搞定！妹子很高兴，表示这个汇总表实在是太棒了，以后她再也不需要手工统计数据了。

你看，用户的需求的提法总是这么地奇葩，要是我完全按物流描述的需求去做，那么：

1、原先的明细表被各种小计分割地支离破碎，破坏了原先合理的结构。虽然说对信息进行分组有利于阅读，但滥用分组必然导致无法正常阅读。

2、缺少真正需要的汇总表，汇总数据需要从明细表中获取，然后手工做汇总表

3、浪费我的时间，付出了劳动却没有产出价值。

这个例子非常有代表性，我们如果不深入理解业务，必然会被需求方的要求各种似是而非的要求牵着鼻子走。最后的产品也就必然变成似是而非的产品，然后改着改着就没法再改了，再改整个系统都要崩溃了。到那时候，什么MVC，什么设计模式，什么先进的技术架构都没法在你的系统面临崩溃深渊的道路上挽救你。

能够让你的系统稳健的唯一方法是深入地理解业务，搭建一个正确的业务架构，在需求发生变更的时候进行分析，在正确的业务里面实现正确的功能才能避免这种情况出现。