以往的重用，往往是基于代码的，例如算法的重用、界面组件的重用，却往往没有将重用提升到设计的层次上。MDA为我们建立可重用的框架提供了一个很好的指导。注意上面的这副图，最外面的两层就表达了MDA可以用于设计重用的基本理念。倒数第二层的含义是利用MDA来进行通用软件（例如事务、目录服务）的模型设计，倒数第一层则表示MDA可以用于特定业务领域的设计建模。可以想象，今后软件公司中的最有价值的资产，就是这些设计模型。

    本文并不打算详细讨论MDA，除了简单的介绍MDA的思路之外，更重要的一点是企业可重用框架的建立。软件企业的核心在于知识，如何有效的将人脑中的知识存储起来，并不断的使用和发展，是软件企业成功的关键。本文提到的可重用框架，指的就是将软件开发相关知识存储起来的框架。这个思路是本文的一个核心思路。在本文看来，可重用框架不但包括了设计模型，还包括了过程和方法。软件开发是在这个框架之内运作的，同时反过来影响着框架的完善和改进。

    过程塑造模式语言

    下述的模式都是从软件开发过程中，围绕着可重用框架的建立整理出来的一些经验，之所以整理为模式的形式，是因为这种方式有利于类似情况的鉴别和对其进行必要的扩展。在软件开发中会遇到各种各样的问题，以上模式中讨论到的问题都是我们在实践中，或是和其他开发团队沟通中反复遇到的。因此坚定了我们将之整理为模式的信心。目前我们得到的模式并不多，但是随着经验的增加，我们会得到更多的积累。

    本文介绍的模式都比较注重权衡的艺术。我们认为这是敏捷思维的必然结果。世界上并没有什么绝对的事情，尤其是目前多变的社会中，昨天的标准并不适合于今天的环境。因此，我们的平衡点也在不断的变化。

    传统、经典、学术的瀑布模型为我们建立了软件开发的基本过程，虽然有各种新的生命周期模型的提出，但是基本的过程并没有太大的变化。例如，增强性的瀑布过程是在瀑布模型的基础上增加了回溯到上一个阶段的能力；迭代式过程的每一次迭代都是一次微小的瀑布生命周期。在这个生命周期模型中，信息在初始需求收集阶段生成，并通过分析、设计、编码、部署等阶段转化为用户最终需要的软件。在这样一个延续性极强的周期中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？这些问题正是知识接力模式所重点关注的。

    我不只一次的见过为过程而关注过程的情况。产生这种结果的一种原因是“过程麻痹症”。过程一旦定型，就不再改变，即便当初制定过程的环境已经发生了变化也是如此。过程的制定一定是针对特定的目标的，这个目标就是开发出成功的软件，如果不能够服务于这个目标，遵循过程又有什么意义呢？另一种原因是过程被分割为彼此独立的片断，每个开发人员只关注自己的职责，而忽略了最终的软件。过程的代码是最终目的，开发过程中的所有活动都围绕着这一目的而展开。如果没有最后的用于交付的代码，软件就无法成为软件。因此，必须保证过程能够产出代码，而且是优秀的代码。

    一致性原则是软件开发中重要原则，也是最令人困惑的原则。做到完全的一致性将会导致高昂的成本，而不一致又会导致项目出现各种各样的问题。可以想到，这又是一个需要权衡的问题。软件项目中的一致性大致可以分为两种，一种是不同工件之间的一致性（例如设计模型中的类名称和实际代码中的类名称的一致性），一种是工件和软件过程的一致性（类名称需要满足命名标准）。我们如何考虑这两种情况下的一致性呢？

    人们说管理既是科学也是艺术，这句话用来形容软件工程再适合不过了。如果说这里有什么不够恰当的地方的话，我倒觉得是"软件工程"的这个提法有些许的欠妥。软件工程的思路源自于人们渴望软件开发能够象土木工程那样成熟。但是几十年的经验下来，大家可以肯定，软件开发和土木工程有着太多的不同：开发人员和建筑工人也有着截然不同的差异，知识的组装和钢筋混凝土更是天差万别。（但为了保证延续性，我们在本文中仍然延续软件工程的提法。）因此，软件工程需要在科学和艺术之间求得权衡，科学的一面包括了软件开发规范、准则、实践、过程、方法；而艺术的一面则囊括了人员的激励、协调，组织的设计等因素。因此我们需要审视我们的规则、过程、方法，它们是否能够发挥出人的创新性？或是它是否足以约束人的行为？这就是活跃和混乱、严谨和死板模式所要告诉我们的。

    应该说，本文中所讨论的模式更适合于使用面向对象技术的开发团队。尤其是短期利益和长期利益的权衡模式。和大多数人一样，我们最早也是过程式编程阵营的一员。在经过长时间的学习和不断的犯错之后，我们终于转向了面向对象。面向对象最大的好处包括了以下几个方面：

    将实现和接口分离，即把如何做隐藏起来，而把做什么展示给客户。

    继承和多态使得我们能够在一个抽象的层次上（基类和接口）思考问题，并能够根据现实的需求进行灵活的调整（子类和实现）。

    通过设计模式和设计技巧的应用，可以有效的降低系统的不同部分之间的耦合度。尤其是简化客户端的代码。
　

    在使用和比较过几种开发语言和开发环境之后，我们发现，其实最关键的并不是使用什么样的面向对象语言（或环境），关键的是你运用面向对象思维的能力，或者说对现实世界的理解、抽象、映射的能力。这种能力决定了你的开发水平的高低，而语言和环境只是一种重要的实现手段和工具而已。而这种思维能力，虽然可以通过例子和讨论来进行介绍，但更关键的还是在实践中进行练习。在本文讨论的模式中，我们会夹带的对这些内容进行讨论。因为我们认为，开发思想和开发过程是无法区分的，否则，你的开发过程就没有灵魂。这也是我们的主题所要强调的：从方法到编码，铸造起一个敏捷的、流畅的过程，才能够保证开发过程的成功，开发软件的成功。

    此外，本篇是总论性文章，在撰写此文时，该篇其实是最后完工的，因此，建议大家在看过全文之后，如果还有耐心，可以重看此篇，相信会有另外一番收获。