一個需求變更的故事

昨天我們的物流部門提了1個需求，希望我能為他們做1張出庫明細報表，以便他們統計和核對數據。嗯嗯，這個很簡單的說，復制1個類似的模板，替換下數據源，按日期分組，20分鐘弄定！

這里簡單插1下，介紹下我們系統中的報表的實現。報表是采取的第3方控件FastReport，通過設計報表模板―>定義報表（選擇模板、分期規則、會計主體、報送對象）―>生成報表（即時、按分期規則自動）。

物流部的同事用即時報表功能看過后提了個新的需求或是BUG，沒有按倉庫分組呀！親！

汗呀，忽視了，趕快加上，5分鐘弄定！然后。。。能不能按客戶類型分1下呀？可以！還沒開動呢，能不能按產品系列分1下呀？嗯？？？可以是可以的，不過，你這是要鬧哪樣呀？這樣分真的好嗎？我知道的業務不需要分這么細的呀。

咳咳。。。我們每天要做1個匯報，你看，我這個。。。。巴拉巴拉。。。

哦哦，明白了，親，你這是需要1個匯總表呀，拜托說明白好不好。我們物流的妹子表示很無辜。。。。然后我又復制了1個模板，替換了數據源，弄定！妹子很高興，表示這個匯總表實在是太棒了，以后她不再需要手工統計數據了。

你看，用戶的需求的提法總是這么地奇葩，要是我完全按物流描寫的需求去做，那末：

1、本來的明細表被各種小計分割地支離破碎，破壞了本來公道的結構。雖然說對信息進行分組有益于瀏覽，但濫用分組必定致使沒法正常瀏覽。

2、缺少真正需要的匯總表，匯總數據需要從明細表中獲得，然后手工做匯總表

3、浪費我的時間，付出了勞動卻沒有產出價值。

這個例子非常有代表性，我們如果不深入理解業務，必定會被需求方的要求各種似是而非的要求牽著鼻子走。最后的產品也就必定變成似是而非的產品，然后改著改著就沒法再改了，再改全部系統都要崩潰了。到那時候，甚么MVC，甚么設計模式，甚么先進的技術架構都沒法在你的系統面臨崩潰深淵的道路上挽救你。

能夠讓你的系統穩健的唯1方法是深入地理解業務，搭建1個正確的業務架構，在需求產生變更的時候進行分析，在正確的業務里面實現正確的功能才能避免這類情況出現。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈