当架构模型进行迭代的过程中，必然伴随着对模型进行修改和改进。我们如何防止对模型的修改，又如何保证对模型进行正确的改进？
Context
架构模型通过精化、合并等活动之后，将会直接用于指导代码。而这个时候，往往就会暴露出一些问题出来，通常在实际编码中，发现架构存在或大或小的问题和错误，导致编码活动无法继续。这时候我们就需要对架构模型进行修改了。而架构设计的过程本身是一个迭代的过程，这就意味着在每一次的迭代周期中，都需要对架构进行改进。
Problem
我们如何避免对架构模型进行修改？又如何保证架构进行正确的改进？
Solution
我们从XP中借用了一个词来形容架构模型的修改过程――Refactoring，中文可以译作重构。这个词原本是形容对代码进行修改的。它指的是在不改变代码外部行为（可观察行为）的情况下对代码进行修改。我们把这个词用在架构模型上，因为经过精化和合并之后的架构模型往往由很多个粗粒度组件构成。这些组件之间存在一定的耦合度（虽然我们可以令耦合度尽可能的低，但是耦合度一定是存在的），任何一个组件的重构行为都会使变化扩散到系统中的其它组件。这取决于被重构的组件和其它组件之间的相对关系。如果被重构的组件属于层次较低的工具层上，那么这次的修改就可以引起模型很大的变动。
在精化和合并模式中，我们提到了改变和改进的区别，因此，我们的对策主要分为两种：如何防止改变的发生，以及，使用重构来改进软件架构。
防止改变的发生
在任何时候，需求的变更总是对架构及软件有着最大的伤害。而需求变更中最大问题是需求蔓延。很多人都有这样的感觉，项目完成之后，发现初期的计划显得那么陌生。在项目早期对需求进行控制是重要的，但并不是该模式谈论的重点。我们更关注在项目中期的需求蔓延问题和晚期的需求控制问题。关于这方面的详细讨论，请参见稳定化模式。在项目中期，尤其是编码工作已经开始之后，要尽可能避免出现需求蔓延的情况。需求蔓延是经常发生的，可能是因为用户希望加入额外的功能，或是随着用户对软件了解的加深，发现原有的需求存在一定的不足。完全防止需求蔓延是无法做到的，但是需要对其进行必要的控制。例如，有效的估计变更对开发、测试、文档、管理、组织等各个方面带来的影响。
避免发生改变的另一个有效的办法是从软件过程着手。迭代法或渐进交付法都是可用的方法。一个软件的架构设计往往是相对复杂的，其中涉及到整体结构、具体技术等问题。一次性考虑全部的要素，就很容易发生考虑不周详的情况。人的脑容量并没有我们想象的那么大。将架构设计分为多个迭代周期来进展，可以减少单次迭代周期中需要建模的架构数量，因此可以减少错误的发生。另一方面，迭代次数的增多的直接结果是时间的延长，此外还有一个潜在的问题，如果由于设计师的失误，在后期的迭代中出现问题，必然会导致大量的返工。因为之前的模型已经实现了。在得与失之间，我们如何找到适当的平衡点呢？
迭代次数应该根据不同软件组织的特点来制定，对于初期的迭代周期而言，它的主要任务应该是制定总原则（使用架构愿景模式）、定义层结构和各层的职责（使用分层模式）、解决主要的技术问题上。在这个过程中，可以列出设计中可能会遇到的风险，并根据风险发生的可能性和危害性来排定优先级，指定专人按次序解决这些问题。除此之外，在初期参考前一个项目的经验，让团队进行设计（参见团队设计模式），这些组织保证也是很重要。初期的迭代过程是防止改变的最重要的活动。
请注意需求中的非功能需求。如果说功能需求定义了架构设计的目标的话，非功能需求就对如何到达这个目标做出了限制。例如，对于实现一个报表有着多种的操作方法，但是如果用户希望新系统和旧系统进行有效的融合，那么实现的方式就需要好好的规划了。请从初期的迭代过程就开始注意非功能需求，因为如果忽略它们，在后期需要花费很大的精力来调整架构模型。试想一下，如果在项目晚期的压力测试中，发现现有的数据库访问方法无法满足用户基本的速度要求，那对项目进行将会造成多么大的影响。
注意架构的稳定性。在精化和合并模式中，我们提到了一些模式，能够降低不同组件之间的耦合度。并向调用者隐藏具体的实现。接口和实现分离是设计模式最大的特点，请善用这一点。
尽可能的推延正式文档的编写。在设计的初期，修饰模型和编写文档通常都没有太大的意义。因为此时的模型还不稳定，需要不断的修改。如果这时候开始投入精力开发文档，这就意味着后续的迭代周期中将会增加一项维护文档一致性的工作了。而这时候的文档却无法发挥出它真正的作用。但是，延迟文档的编写并不等于什么都不做，无论什么时候进行设计，都需要随手记录设计的思路。这样在需要的时候，我们就能够有充分的资料对设计进行文档化的工作。
对软件架构进行重构
Martin Fowler的Refactoring一书为我们列举了一系列的对代码进行重构方法。架构也是类似的。
重构到模式
Joshua Kerievsky在《Refactoring to Patterns》一书中这样描述重构和模式的关系：
Patterns are a cornerstone of object-oriented design, while test-first programming and merciless refactoring are cornerstones of evolutionary design
（模式是面向对象设计的基石，而测试优先编程和无情的重构则是设计演进的基石）。作者在文中着重强调了保持适度设计的重要性。
在作者看来，模式常常扮演着过度设计的角色。而在解决这个问题的同时又利用模式的优点的解决方法是避免在一开始使用模式，而是在设计演进中重构到模式。这种做法非常的有效，因为在初始设计中使用模式的话，你的注意力将会集中到如何使用模式上，而不是集中在如何满足需求上。这样就会导致不恰当的设计（过度设计或是设计不充分）。因此，在初始设计中，除非非常有把握（之前有类似的经验），否则我们应当把精力放在如何满足需求上。在初始模型完成后（参见精化和合并模式中的例子），我们会对架构进行重构，而随着迭代的演进，需求的演进，架构也需要演进，这时候也需要重构行为。在这些过程中，如果发现某些部分的设计需要额外的灵活性来满足需求，那么这时候就需要引入模式了。
在软件开发过程中，我们更常的是遇见设计不充分的情况，例如组件之间耦合度过高，业务层向客户端暴露了过多的方法等等。很多的时候，产生这种现象是由于不切实际的计划而导致的。开发人员不得不为了最终期限而赶工，所有的时间都花费在新功能上，而完成的软件则被仍在一边。这样产出的软件是无法保证其质量的。对于这种情况，我们也需要对设计进行重构，当然，合理的计划是大前提所在。团队的领导者必须向高层的管理者说明，现在的这种做法只会导致未来的返工，目前的高速开发是以牺牲未来的速度为代价的。因为低劣的设计需要的高成本的维护，这将抵消前期节省的成本。如果软件团队需要可持续的发展，那么请避免这种杀鸡取卵的行为。
因此，使用模式来帮助重构行为，以实现恰当的设计。
测试行为
重构的前提是测试优先，测试优先是XP中很重要的一项实践。对于编码来说，测试优先的过程是先写测试用例，再编写代码来完成通过测试用例（过程细节不只如此，请参看XP的相关书籍）。但是对于架构设计来说，测试行为是发生在设计之后的，即在设计模型完成后，产出相应的测试用例，然后再编码实现。这时候，测试用例就成为联系架构设计和编码活动的纽带。
另一方面，在设计进行重构时，相应的测试用例也由很大的可能性发生改变。此时往往会发生需要改变的测试代码超出普通代码的情况。避免这种情况一种做法是令你的设计模型的接口和实现相分离，并使测试用例针对接口，而不是实现。在精化和合并模式中，我们提到了一些模式，能够有助于稳定设计和测试用例。Martin Fowler在他的Application Facade一文中，提到使用Facade模式来分离不同的设计部分，而测试则应当针对facade来进行，其思路也是如此。
考虑一个用户转帐的用例。银行需要先对用户进行权限的审核，在审核通过之后才允许进行转帐（处于简便起见，图中忽略了对象的创建过程和调用参数）：
需要分别针对三个类编写测试用例，设计模型一旦发生变化，测试用例也将需要重新编写。再考虑下面的一种情况： 
现在的设计引入了TransferFacade对象，这样我们的测试用例就可以针对TransferFacade来编写了，而转帐的业务逻辑是相对比较稳定的。使用这种测试思路的时候，要注意两点：首先，这并不是说其它的类就不需要测试用例了，这种测试思路仅仅是把测试的重点放在外观类上，因为任何时候充分的测试都是不可能的。但其它类的测试也是必要的，对于外观类来说，任何一个业务方法的错误都会导致最终的测试失败。其次，当外观类的测试无法达到稳定测试用例的效果时，就没有必要使用外观类了。
只针对有需要的设计进行重构。
任何时候，请确保重构行为仅仅对那些有重构需要的设计。重构需要花费时间和精力，而无用的重构除了增大设计者的虚荣心之外，并不能够为软件增加价值。重构的需要来源于两点：一是需求的变更。目前的设计可能无法满足新的需求，因此需要重构。二是对设计进行改进，以得到优秀简洁的设计。除了这两种情况，我们不应该对设计模型进行重构。
使用文档记录重构的模式。
应该承认，模式为设计提供了充分的灵活性。而这些设计部分往往都是模型的关键之处和难点所在，因此需要对模式进行文档化的工作，甚至在必要的时候，对这部分的设计进行培训和指导。确保你的团队能够正确的使用文档来设计、理解、扩展模式。我们在解决方案的前一个部分提到了尽可能延迟文档的创建。而在设计重构为模式的时候，我们就需要进行文档化的工作了。因为模式具有灵活性，能够抵抗一定的变更风险。
重构并保持模式的一致性
正如上一节所说的那样，模式并不是一个很容易理解的东西，虽然它保持了设计的灵活性和稳定性。对于面向对象的新手而言，模式简直就像是飞碟一样，由于缺少面向对象的设计经验，他们无法理解模式的处理思路，在实践中，我们不只一次的碰到这种情况。我们不得不重头开始教授关于模式的课程。因此，最后我们在软件设计采用一定数量的模式，并确保在处理相同问题的时候使用相同的模式。这样，应用的模式就成为解决某一类的问题的标准做法，从而在一定程度上降低了学习的曲线。
保持模式的一致性的另一个方面的含义是将模式作为沟通的桥梁。软件开发是一种团队的行为。因此沟通在软件开发中扮演着很重要的角色。试想一下，开发人员在讨论软件设计的时候，只需要说"使用工厂模式"，大家就都能够明白，而不是费劲口舌的说明几个类之间的关系。这将大大提高沟通的效率。此外，模式的使用和设计的重构对于提高团队的编程水平，培养后备的设计人员等方面都是很有意义的。
十二、稳定化
敏捷方法的兴起对设计提出了新的要求，其最核心的一点是针对无法在项目一开始就固化的需求进行演进型的设计。在项目一开始就进行细致、准确的架构设计变得越来越难，因此，架构设计在项目的进展中被不断的改进，这相应导致了编码、测试等活动的不稳定。但是，软件最终必须是以稳定的代码形式交付的。因此，架构设计必须要经历从不稳定到稳定的过程。而架构设计能够稳定的前提就是需求的稳定。
需求冻结
敏捷方法和传统方法的区别在于对待变化的态度。传统的做法是在编码活动开始之前进行充分、细致的需求调研和设计工作，并签署合同。确保所有的前期工作都已经完成之后，才开始编码、测试等工作。如果发生需求变化的情况，则需要进行严格的控制。而在现实中，这种方法往往会由于对开发人员和客户双方需求理解的不一致，需求本身的变化性等问题而导致项目前期就完全固化需求变得不现实。结果要么是拒绝需求的改变而令客户的利益受损，要么是屈从于需求的改变而导致项目失控。敏捷方法则不同，它强调拥抱变化。对于易变的需求，它使用了一系列实践，来驯服这只烈马。其核心则是迭代式开发。应该承认，做到掌握需求并不是一件容易的事，而迭代开发也很容易给开发团队带来额外的高昂成本。要做到这一点，需要有其它实践的配合（下文会提到）。因此，我们在迭代开发进入到一定的阶段的时候，需要进行需求冻结。这时候的需求冻结和上面提到的一开始就固化需求是不一样的。首先，用户经历过一次或几次的迭代之后，对软件开发已经有了形象的认识，对需求不再是雾里看花。其次，通过利用原型法等实践，用户甚至可能对软件的最终形式已经有了一定的经验。这样，用户提出的需求基本上可以代表他们的真实需求。即便还有修改，也不会对软件的架构产生恶劣的影响。最后，需求冻结的时点往往处于项目的中期，这时候需求如果仍然不稳定，项目的最后成功就难以得到保证。
在需求冻结之前，不要过分的把精力投入到文档的制作上，正确的做法是保留应有的信息，以便在稍后的过程中完成文档，而不是在需求未确定的时候就要求格式精美的文档。在格式化文档上很容易就会花费大量的时间，如果需求发生改变，所有的投入都浪费了。文档的投入量应该随着项目的进行而增大。但这决不是说文档不重要，因为你必须要保留足够的信息，来保证文档能够顺利的创建。
确保有专人来接受对变更需求的请求，这样可以确保需求的变化能够得以控制。这项工作可以由项目经理（或同类角色）负责，也可以由下文所说的变更委员会负责。小的、零散的需求很容易对开发人员产生影响，而他们有更重要的任务――把项目往前推进。此时项目经理就像是一个缓冲区，由他来决定需求的分类、优先级、工作量、对现有软件的影响程度等因素，从而安排需求变更的计划――是在本次迭代中完成，还是在下一次迭代中完成。
建立需求变更委员会是一种很好的实践，它由项目的不同类型的涉众组成，可能包括管理、开发、客户、文档、质量保证等方面的人员。他们对需求变更做出评估及决定，评估需求对费用、进度、及各方面的影响，并做出是否以及如何接受需求的决定。由于委员会往往涉及到整个项目团队，因此效率可能会成为它的主要缺点。在这种情况下，一方面可以加强委员会的管理，一方面可以保证委员会只处理较大的需求变更。
在项目的不同时候都需要对需求进行不同程度的约束，这听起来和我们提倡的拥抱变化有些矛盾。其实不然。对需求进行约束的主要目的是防止需求的膨胀和蔓延，避免不切实际的功能列表。我们常常能够提到诸如 "这项功能很酷，我们的软件也要包含它"以及"我们的对手已经开发出这项功能了，最终的软件必须要包含这项功能"之类的话语。这就是典型的需求蔓延的征兆。在项目开始时正确的估计功能进度，在项目中期时控制需求，在项目晚期是杜绝新增需求，甚至剪切现有需求。通过三种方法来保证软件能够保时保质的推出。
稳定架构
即便是需求已经成功的冻结了，我们仍然面对一个不够稳定的架构。这是必然的，而不稳定的程度则和团队的能力，以及对目标领域的理解程度成反比。因此，架构也需要改进。前一个模式中，我们讨论了对架构的重构，其实这就是令架构稳定的一种方法。经验数据表明，一系列小的变化要比一次大变化容易实现，也更容易控制。因此在迭代中对架构进行不断重构的做法乍看起来会托慢进度，但是它为软件架构的稳定奠定了基础。重构讲究两顶帽子的思维方式，即这一个时段进行功能上的增加，下一个时段则进行结构的调整，两个时段决不重复，在对增加功能时不考虑结构的改进，在改进结构时也同样不考虑功能的增加。而在架构进行到稳定化这样一个阶段之后，其主要的职责也将变为对结构的改进了。从自身的经验来看，这个阶段是非常重要的，对软件质量的提高，对加深项目成员对目标领域的认识都有莫大的帮助。而这个阶段，也是很容易提炼出通用架构，以便软件组织进行知识积累的。
在这个阶段中，让有经验的架构师或是高级程序员介入开发过程是非常好的做法。这种做法来自于软件评审的实践。无论是对于改进软件质量，还是提高项目成员素质，它都是很有帮助的。
架构稳定的实践中暗含了一个开发方法的稳定。程序员往往喜欢新的技术、新的工具。这一点无可厚非。但是在项目中，采用新技术和新工具总是有风险的。可能厂商推出的工具存在一些问题没有解决，或者该项技术对原有版本的支持并不十分好。这些都会对项目产生不良的影响。因此，如果必须在项目中采用新技术和新工具的话，有必要在项目初期就安排对新事物进行熟悉的时间。而在架构进入稳定之前，工具的用法、技术的方法都必须已经完成试验，已经向所有成员推广完毕。否则必须要在延长时间和放弃使用新事物之间做一个权衡。
保证架构稳定的优秀实践
在文章的开头，我们就谈到说在项目起始阶段就制定出准确、详细的架构设计是不太现实的。因此，敏捷方法中有很多的实践来令最初的架构设计稳定化。实际上，这些实践并非完全是敏捷方法提出的新概念。敏捷方法只是把这些比较优秀的实践组织起来，为稳定的架构设计提供了保证。以下我们就详细讨论这些实践。
在不稳定的环境中寻求稳定因素。什么是稳定的，什么是不稳定的。RUP推荐使用业务实体（Business Entity）法进行架构设计。这种方法的好处之一是通过识别业务实体从而建立起来的架构是相对稳定的。因为业务实体在不稳定的业务逻辑中属于稳定的元素。大家可以想象，公司、雇员、部门这些概念，几十年来并没有太大的变化。对于特定的业务也是一样的。例如对于会计总帐系统来说，科目、余额、分户账、原始凭证，这些概念从来就没有太大的变化，其对应的行为也相差不大。但是某些业务逻辑就完全相反了。不同的系统业务逻辑不同，不同的时点业务逻辑也有可能发生变化。例如，对于不同的制造业来说，其成本核算的逻辑大部分都是不一样的。即便行业相同，该业务逻辑也没有什么共性。因此，稳定的架构设计应该依赖于稳定的基础，对于不稳定的因素，较好的做法是对其进行抽象，抽象出稳定的东西，并且把不稳定的因素封装在单独的位置，避免其对其它模块的影响。而这种思路的直接成果，就是下一段提到的针对接口编程的做法。例如对于上面提到的成本核算来说，虽然它们是易变的、不稳定的，但是它们仍然存在稳定的东西，就是大部分制造业企业都需要成本核算。这一点就非常的重要，因此着意味着接口方法是相对固定的。
保持架构稳定性的另一种方法是坚持面向接口编程的设计方法。我们在分层模式中就提到了面向接口编程的设计方法，鼓励抽象思维、概念思维。从分层模式中提到的示例中（详见分层模式下篇的面向接口编程一节），我们可以看出，接口的一大作用是能够有效的对类功能进行分组，从而避免客户程序员了解和他不相关的知识。设计模式中非常强调接口和实现分离，其主要的表现形式也正是如此，客户程序员不需要知道具体的实现，对他们来说，只需要清楚接口发布出的方法就可以了。
从另一个方面来看，之所以要把接口和实现相分离，是因为接口是需求中比较稳定的部分，而实现则是和具体的环境相关联的。下图为Java中Collection接口公布出的方法。可以看到，在这个层次上，Collection接口只是根据容器的特性定义了一些稳定的方法。例如增加、删除、比较运算等。所以这个接口是相对比较稳定的，但是对于具体的实现类来说，这些方法的实现细节都有所差别。例如，对于一个List和一个Array，它们对于增加、删除的实现都是不一样的。但是对于客户程序员来说，除非有了解底层实现的需要，否则他们不用了解List的add方法和Array的add方法有什么不同。另一方面，将这些方法实现为固定的、通用的接口，也有利于接口的开发者。他们可以将实现和接口相分离，此外，只要满足这些公布的接口，其它软件开发团队同样能够开发出合用的应用来。在当前这样一个讲求合作、讲求效率的大环境中。这种开发方法是非常重要的。
| java.util Interface Collection |
|
| boolean | add(Object o) |
| boolean | addAll(Collection c) |
| void | clear() |
| boolean | contains(Object o) |
| boolean | containsAll(Collection c) |
| boolean | equals(Object o) |
| int | hashCode() |
| boolean | isEmpty() |
| Iterator | iterator() |
| boolean | remove(Object o) |
| boolean | removeAll(Collection c) |
| boolean | retainAll(Collection c) |
| int | size() |
| Object[] | toArray() |
| Object[] | toArray(Object[] a) |
重构。代码重构是令架构趋于稳定的另一项方法。准确而言，重构应该是程序员的一种个人素质。但是在实际中，我们发现，重构这种行为更加适合作为开发团队的共同行为。为什么这么说呢？最早接触重构概念的时候，我对面向对象的认识并不深入。因此对重构的概念并不感冒。但随着经验的积累，面向对象思维的深入。我渐渐发现，重构是一种非常优秀的代码改进方式，它通过把原子性的操作，逐步的改进代码质量，从而达到改进软件架构的效果。当程序员逐渐熟练运用重构的时候，他已经不再拘泥于这些原子操作，而是自然而然的写出优秀的软件。这是重构方法对各人行为的改进。另一方面，对于一个团队来说，每个人的编程水平和经验都不一而足，因此软件的各个模块质量也都是参差不齐的。这种情况下，软件质量的改进就已经不是个人的问题了，而该问题的难度要比前一个问题大的多。此时重构方法更能够发挥其威力。在团队中提倡使用、甚至半强制性使用重构，有助于分享优秀的软件设计思路，提高软件的整体架构。而此时的重构也不仅仅局限在代码的改进上（指的是Martin Fowler在重构一书中提到的各种方法），还涉及到分析模式、设计模式、优秀实践的应用上。同时，我们还应该看到，重构还需要其它优秀实践的配合。例如代码复审和测试优先。
总结
令架构趋于稳定的因素包括令需求冻结和架构改进两个方面。需求冻结是前提，架构改进是必然的步骤。在面向对象领域，我们可以通过一些实践技巧来保持一个稳定的架构。这些实践技巧体现在从需求分析到编码的过程中。稳定化模式和下一篇的代码验证模式有很多的关联，细节问题我们会在下一篇中讨论。