下来再谈谈设计的问题

    在Head First Object-Oriented Design的书中，定义Good Design就是Flexible Design。而The Art of Agile Software Development一书中，定义Good Design为“A good software design minimizes the time required to create, modify and maintain the software while achieving acceptable runtime performance.”就是软件的可维护性。所以Agile Design强调的功能，基本上都是从如何不断改进软件的可维护性和可扩展性而努力的，只有软件具备了良好的可维护性和可扩展性，那么软件能够很好的不断叠加功能，软件才具有旺盛的生命力。

    我们实际中面向的问题呢?其实还是很简单，就是好的设计和项目时间的冲突，好的设计是需要时间考虑的，也是需要时间来实现的(虽然不是绝对，有时候好的设计会节省更多的工作量)。

    对于第一个问题，于项目时间的冲突，这个可以回到前面开始谈的内部质量和外部质量的问题，前面对于功能(外部质量)的问题，我们已经谈了取舍的方法，那么，内部质量(设计)，是不是也可以取舍呢?在“Scrum and XP from the Trenches”书里面，作者自己是这么认为的：

    Internal quality, however, is not up for discussion. It is the team’s responsibility to maintain the system’s quality under all circumstances and this is simply not negotiable. Ever.

    在这上面我是持一样的观点的。

    然而我们的问题依然存在。和项目时间的冲突如何平衡呢?我想可以考虑两个原则：

    <!--[if !supportLists]-->1) <!--[endif]-->足够好(First Right)

    <!--[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就是为了设计模式而生的，很好的运用这些技术和理念，是可以让我们的设计具有更好的生命力和持续性，同时也平衡项目中的一些时间点。

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