只有在用户测试、上线等真刀实枪干的时候才能以严格的要求去审视系统，
不断的提出需求变更、易用性问题，修改工作量的多少也就是考验系统架构的时候了，
架构好，多个需求变更，只需要修改一处就行；架构差，一个需求，要修改多处
这个项目的悲剧的是：一个小小的需求，所有模块都要翻一遍，修改的地方达100处！
并且有多个类似的需求！！！要修改N百处！！！
这是什么系统架构啊！！
系统功能在用户测试阶段被推翻
原文：http://www.cnblogs.com/lishan4002/p/4956791.html
