<!--[if !supportLists]-->2) <!--[endif]-->分阶段实现/可持续性
1)足够好(First Right & Good Enough)
所谓First Right & Good Enough是让我们看看我们所作的设计是不是足够清晰的架构我们的系统，而不是太过的复杂导致项目时间不足，往往好的设计并不是要花更多的时间实现的，通常只有Over Design才让我们感到力不从心。所以我们发现设计导致实现的时间过长的时候，我们需要看看，是不是我们想的太复杂了?
另外一方面，我们不提倡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就是为了设计模式而生的，很好的运用这些技术和理念，是可以让我们的设计具有更好的生命力和持续性，同时也平衡项目中的一些时间点。
结语：无论如何，软件的需求分析和设计，都是一种艺术，是要在我们不断的开发过程中去积累和提高的，要做到最好，所有的付出，都是值得的。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
