另外一方面，我们不提倡Over Design，避免Needless Complexity，但是还是要Good Enough & First Right，是在看的到的需求范围内，我们的设计要好，好的设计和不好的设计，差别往往是在维护代码和增加功能的时候才能够看到，稍微花一些时间完成一些精妙的设计，不仅是技术，更是艺术美感的体现，这个只有在未来才能够体会到。

　　要注意的是Refactoring和First Right并没有冲突，只有每次都是Right的比Wrong的更多，逐步的将Wrong的地方进行Refactor，系统才能够越做越好。否则系统的质量始终处于初级阶段了。

　　2）分阶段实现/可持续性

　　好的设计往往是Flexible的，是可以分阶段实现的，很多设计的基本原则，比如面向接口编程，是支撑“分阶段实现”的一个很好的原则。当我们定义的接口层次很清晰的时候，接口的具体实现，是可以根据项目的时间点，进行控制的。项目时间比较紧的时候，可以做一些快速的实现，然后在下一阶段再Refactoring，如果对象之间是接口依赖而不是类依赖的话，下一阶段的Refactoring也对系统已有功能影响也非常的小，这个也是IOC核心价值所在了。

　　举个例子，比如说话单文件格式的灵活设计，假设话单有好几种格式，那么它的设计可以有几个阶段：

　　第一个阶段是能够在类这个层级易于维护，先通过Template的设计模式定义一个话单父类后，不同的话单格式的子类实现父类的模板方法，如formatCDR（格式话话单记录）即可，这种情况下，外部函数写话单的时候，只需要实例化相应对象后，调用父类的接口可以写出相应的话单。而有新话单格式的时候，只要生成一个新的子类并实现相应方法可以了，可以看到这种设计是一个Good Enough的设计。

　　第二个阶段是把类的可维护性提升到配置的可维护性，比如说通过一种XML的方式来配置话单格式，使得系统的可维护性达到运行时而不是编译时。这个时候，还是在原来的基础上，生成一个新的子类，这个子类在formatCDR的时候是从XML配置文件里面读取配置后生成格式化数据的罢了，系统还是支持很多种默认的CDR格式并且对于一些无法通过配置的CDR格式，还是可以通过子类继承的方式来实现。

　　第三个阶段是做一个很好的GUI来配置和管理话单XML配置文件了。

　　所以往往好的设计是可以逐步叠加并且完善的，象Spring的核心IOC是为了设计模式而生的，很好的运用这些技术和理念，是可以让我们的设计具有更好的生命力和持续性，同时也平衡项目中的一些时间点。

　　结语：无论如何，软件的需求分析和设计，都是一种艺术，是要在我们不断的开发过程中去积累和提高的，要做到好，所有的付出，都是值得的。