七、组合使用模式
我们已经讨论了敏捷架构设计的4种过程模式，在这一章中，我们对这四种过程模式做一个小结，并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述，大家能够对前面的内容有更进一步的了解。
四种模式的着重点
我把源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次，这4种模式能够确定架构设计过程的框架。这里需要对框架的含义进行澄清：架构设计的框架并不是说你要严格的按照文中介绍的内容来进行架构设计，在文章的一开始我们就指出，模式能够激发思考。因此，这一框架是需要结合实际，进行改造的。实际，我们在这一个部分中介绍的，比较偏向于原则，我们花了很大的时间来讨论原则的来龙去脉，而原则的度，则要大家自己去把握。为什么我们不讨论原则的度呢？这里有两个原因，一个是软件开发团队各有特色，很难定义出一个通用的度。第二个原因是我的水平不够，实践经验也不够丰富。
前面提到的四种模式其实是从四个侧面讨论了架构设计中的方法问题。源自需求提供了架构设计的基础。在软件过程中，架构设计是承接于需求分析的，如果没有良好的需求分析活动的支持，再好的架构设计也没有用。因此我们把这一模式放在首位，做为架构设计的目标。
有了确定的目标，还需有组织的保证，这也就是第二种模式――团队设计的由来。敏捷方法提倡优秀的沟通，因此团队设计是必要且有效的。而团队设计的另一个意图，是保证架构设计的下游活动得以顺利的进行，例如详细设计、编码、测试等。由于开发团队中的人大都加入了架构设计，因此最大程度的减小了不同的活动间的信息损耗和沟通效率低下的问题。如果说源自需求模式是起承上的作用，那么团队设计模式则是扮演了启下的角色。
在软件设计的过程中，沟通往往扮演着非常重要的角色。从团队设计开始的几种模式所要解决的都是沟通的问题。团队设计对沟通的贡献在于它能够把设计意图以最小的代价传播到开发团队的每个角落。这样，设计和下游的活动间由于沟通不畅产生的问题就能够得到缓解。一般而言，设计到编码会经历一个信息损失的过程，编码人员无法正确理解设计人员的意图，设计人员却往往无法考虑到一些编码的细节。虽然我们可以通过共通的设计符号来提高沟通的质量，例如UML。但是实践证明，只要能够保证畅通的沟通，即便没有优秀的开发方法，项目成功的概率依然很高。因此对于单个的项目来说，最关键的问题还是在于沟通。只要组织得当，团队设计是一个值得应用的模式。当然，配合以UML为代表的建模语言，更能够提高沟通的效果。
在设计中，我们发现，当设计信息转换为编码信息需要一定的时间，这个时间包括设计的组织时间，设计被理解的时间。如果设计比较复杂，或者说设计的文档比较复杂，编码人员花在理解上的时间就会大大增加。因此，权衡后的结果是，相对于详细的设计说明书而言，简单的设计说明书再配合一定程度的面对面沟通能够起到更好的效果。"简单要比复杂有效"，这就是简单设计模式的基本思路。
同样，简单的思路还会用在软件开发的各个方面，例如文档、设计、流程。坚持简单的原则，并不断的加以改进，是降低软件开发成本的一种很有效的做法。
在有了以上的思路之后，我们还需要面对两个现实的问题。需求的变化将会导致设计的不稳定，而需求的复杂性又会导致简单架构设计的困难。为了解决这个问题，我们引入了迭代的方法，将问题分割为多个子问题（把一个复杂的问题分解为多个较简单的子问题是计算机领域最常见的处理方法）。这样，问题的范围和难度都大大降低了。而更关键的是，由于对用户需求理解不充分或用户表达需求有错导致的设计风险被降到最低点。迭代和前面几个模式都有关系。
需求和迭代
源自需求模式是架构设计中的起手式，没有这一模式的支持，架构设计只能是空中楼阁。其实，源自需求模式严格意义上并不能算是敏捷方法论的特色，而应该算是软件开发的天然特性。不幸的是，就是这么一个基本的原则，却没能够引起开发者足够的重视。
敏捷方法论中把需求摆在一个非常重要的位置，我们把源自需求模式作为架构设计的第一个模式，主要的目的是承接架构设计的上游工作――需求。需求决定架构，因此，我们在经典的瀑布模型中可以看到需求到设计的严格的分界线，但是在实际的开发中，按照瀑布模型的理论往往会遇到很多的问题，所以，我们尝试着把需求和（架构）设计之间的界限打破，形成一个重叠的地带，从而提高软件开发的速度。因此，我们在源自需求模型中指出，架构设计是紧随着需求开始的。
需求对软件开发最具影响就是需求的不稳定性。我们都非常的清楚软件开发的曲线，越到软件开发的后期，修改软件的成本越高。因此，在软件开发上游的需求的变动将会对软件开发的下游产生天翻地覆的影响。为了协调这一矛盾，软工理论提出了螺旋开发模型，这就是我们在迭代开发模式中的讨论的理论基础。把软件开发过程分为多个的迭代周期，每一次的迭代周期最后都将生成一个可交付的软件，用户在每一次的迭代结束后，可以试用软件，提出下一步的需求或是改变原先的需求。通过这样的方式，把客户、开发商的风险降到一个可以接受的水平上。
请注意迭代的前提：需求的易变性。因此，对于那些需求容易发生变化的项目，我们就可以使用迭代式的开发过程，虽然我们会付出一些额外的成本（刚开始这个成本会比较大，但可以用较长的迭代周期来降低这种成本），但是风险减小了。而对于需求比较固定的项目，是不是有必要使用迭代的方法，就要看具体的环境了。因此，我们是根据实际的情况选用开发方法，而不是因为先进或是流行的原因。
实际上，由于现代社会的特性，大部分的项目都是可以采用迭代方法。因此，我们的选择就变成了了迭代周期应该要多长。迭代周期在理论上应该是越短越好，但是并没有一个绝对的数值，时间的跨度一般从几周到几个月。一般来说，迭代周期会受到几个因素的影响：
·各模块的关联程度。在软件开发中，我们有时候很难把一些模块分离开来，要开发模块A，就需要模块B，而模块B又需要模块C。各模块的关联程度越高，迭代周期越长。当然，也相应的解决方法，我们可以在各模块的功能中选取出一些关键点，作为里程碑，以里程碑作为迭代完成点。
·人员技能、经验的平均程度。团队中成员的开发能力、开发经验良莠不齐，这也是造成迭代周期延长的一个原因。能力低、经验少的开发人员会拖后每一次迭代的时间。针对这种情况，做好统筹规划就显得非常的重要，可以通过一两次的迭代，找出队伍中的瓶颈人员，安排相应的对策。
·工具的缺乏。迭代周期越短，就意味着build、发布的次数越多，客户也就有更多的机会来修改需求。这要求有相关的工具来帮助开发人员控制软件。最重要的工具是回归测试工具。每一次迭代都需要增加新的功能，或是对原先的功能进行改动，这就有可能引入新的bug，如果没有回归测试，开发人员就需要花费时间重新测试原先的功能。
·计划、控制的能力。迭代周期越短，所需要的计划、控制的能力就越强。因为短时间内的计划制定和实施需要高度的细分，这就要求开发团队的管理者对开发能力、工作量、任务分配有很强的认识，才能做好这项工作。不过，迭代周期越短，同样开发时间的迭代次数就越多，而团队调整、改进计划控制的机会就越多。因此，后期的迭代一般都能够做到比较精确的控制。而这样的做法，要比问题堆积到软件交付日才爆发出来要好的多。没有突然落后的软件，只有每天都在落后的软件。
简单和迭代
简单和迭代关系是双向的。
在现实设计我们很难界定出简单设计的程度。怎样的架构设计才算是简单？按照我们在简单设计模式中的讨论，刚好满足目前的需求的架构设计就算是简单的设计。但是，从另外一个方面考虑，需求的易变性限制我们做出简单的设计，因为我们不能够肯定目前的需求将来会发生什么样的变化。因此，为了克服对未知的恐惧，我们花了很大的力气设计一些灵活的、能够适应变化的架构。这是源自需求模式对简单设计模式的影响。
源自需求和迭代设计的关系的讨论建议我们把需求分为多个迭代周期来实现。那么，相应的架构设计也被分在多个迭代周期中。这样的方法可以降低架构设计的复杂程度。因为设计人员不需要考虑软件的全部需求，而只需要考虑当前迭代周期的需求。复杂性的降低将会有助于架构设计的简单化，从而达到简单设计的一系列的好处（参见简单设计）。
我们从迭代设计中的最后一个例子可以清楚的看到迭代设计是如何把复杂的需求给简单化的。把握迭代设计有助于我们避免过分设计的毛病。这是个技术人员经常犯的毛病。我所在的团队很多时候也无法避免。例如，在很多的项目中，我们都会花费大量的时间来设计数据库到业务实体的映射。诸如此类的技术问题对开发人员的吸引程度是不言而喻的，但是必须看到，这种的设计会导致开发成本的大幅度上升。更为糟糕的是，除非有丰富的经验，这种类型的设计给开发工作带来的价值往往无法超过其成本。
因此，我们需要学会权衡利弊，是否有必要投入大量的资源来开发其实并没有那么有用的功能。因此，迭代设计和简单设计的结合有助于我们摆脱过度设计的困扰，把精力集中在真正重要的功能之上。
此外，简单的设计并不等同于较少的付出。简单的设计往往需要对现实世界的抽象，回忆我们在简单设计中讨论的测量模式的例子，它看似简单，但实现起来却需要大量的业务知识、很强的设计能力。因此，做到简单是程序员不断追寻的目标之一。
在很多的方法论中，一般并不过分注意代码重复的问题，要么是不关注，要么认为适当的代码重复是允许的。而XP却把代码重复视为良好代码的大敌。"只要存在重复代码，就说明代码仍有Refactoring的可能。"这种观点看起来非常的绝对，这可能也正是其名字中Extreme的来历（英文中的Extreme属于语气非常重的一个单词）。从实践的角度上来看，追求不重复的代码虽然很难做到，但是其过程却可以有效的提高开发团队代码的写作质量，因为它逼迫着你在每次迭代重对代码进行改进，不能有丝毫的怠惰。而这种迭代的特性，促进了简单的实现。
团队和简单
我们在简单设计中提过简单设计需要全面的设计师。除此之外，它还需要团队的配合。简单意味着不同活动间交付工件的简单化。也就是说，类似于需求说明书、设计文档之类的东西都将会比较简单。正因为如此，我们很难想象一个地理上分布在不同地点的开发团队或一个超过50人的大团队能够利用这种简单的文档完成开发任务。
因此，简单的设计是需要团队的组织结构来保证的。简单的设计要求团队的相互沟通能够快速的进行。架构设计完成后，架构的设计思路传达给所有的编码人员的速度要块，同样，编码中发现问题，回馈给设计者，设计者经过改进之后再传达给收到影响的编码人员的速度也要快。象这样高效率的传播我们可以称之为"Hot Channel"。
为了保证"Hot Channel"的高沟通效率，最好的组织单位是开发人员在3到6人之间，并处于同间工作室中。这样的结构可以保证讯息的交互速度达到最高，不需要付出额外的沟通成本，也不需要过于复杂的版本控制工具或权限分配。根据我的经验，一个共享式的小型版本控制工具、网络共享、再加上一个简单的网络数据库就能够解决大部分的问题了。
在理论上，我们说只要分配得当，大型的团队同样可以组织为金字塔式的子团队，以提高大型团队的工作效率。但是实际中，随着团队的人数的增加，任务的正确分配的难度也随之加大，沟通信息上传下达的效率开始下降，子团队间的隔阂开始出现，各种因素的累加导致敏捷方法并不一定适合于大型的团队，因此我们讨论的敏捷方法都将受到团队的特性的限制。
模式的源头
如果你对XP有一定的了解的话，那么你可能会感觉到我们讨论的模式中应用了XP的实践。确实如此，XP中有很多优秀的实践，如果组织得当的话，这些微小的实践将会组合成为一套了不起的开发方法。不过，目前的软件开发混乱的现状阻止了先进的软件方法的应用，对一个身体虚弱的病人施以补药只会适得其反。因此，在前面讨论的模式中，我们应用了一些容易应用、效果明显的实践方法。在实践中适当的应用这些方法，并不需要额外的投入，却能够有很好的效果，同时还会为你的团队打下一个良好的基础。
