一个需求变更的故事

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

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

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

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

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

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

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

1、本来的明细表被各种小计分割地支离破碎，破坏了本来公道的结构。虽然说对信息进行分组有益于浏览，但滥用分组必定致使没法正常浏览。

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

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

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

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

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠