敏捷思维-架构设计中的方法学

敏捷思维一架构设计中的方法学

作者：林星

1.敏捷思维一架构设计中的方法学(1)--从方法论看架构设计..............1

2.敏捷思维一架构设计中的方法学(2)-架构设计的敏捷视图.............12

3.敏捷思维一架构设计中的方法学(3)-源自需求.......................24

4.敏捷思维一架构设计中的方法学(4)—团队设计.......................35

5.敏捷思维一架构设计中的方法学(5)—简单设计.......................46

6.敏捷思维一架构设计中的方法学(6)-迭代设计.......................58

7.敏捷思维一架构设计中的方法学(7)-组合使用模式...................71

8.敏捷思维一架构设计中的方法学(8)—架构愿景.......................81

9.敏捷思维一架构设计中的方法学(9)—分层(上).......................91

10.敏捷思维一架构设计中的方法学(10)—分层(下)....................104

11.敏捷思维一架构设计中的方法学(11)-精化和合并...................117

12.敏捷思维一架构设计中的方法学(12)—Refactoring.......................................127

13.敏捷思维一架构设计中的方法学(13)-稳定化......................137

14.敏捷思维一架构设计中的方法学(14)—代码验证...................145

15.敏捷思维一架构设计中的方法学(15)-进一步阅读..................156

在这个关于软件工程的专栏里,作者将应用敏施入疝斗方法学对软件

开发过程中架构设计进行研究。

1.敏捷思维一架构设计中的方法学(1)-从方法论看架构

设计

方法论对软件开发而言意味着什么？我们如何看待软件开发中的方

法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些

疑惑就会得到解答。

在第一篇文章中，我们来了解标题中的一些词的含义。

方法学是什么?

敏捷是什么?

为什么讨论架构?

方法论

方法论的英文为Methodology,词典中的解释为"Aseriesofrelated

methodsortechniques"我们可以把它定义为软件开发(针对软件开发)

的一整套方法、过程、规则、实践、技术。关于方法论的出现的问题,

我很赞同AlistairCockburn的一句话，”方法论源于恐惧。"出于对项

目的超期、成本失控等等因素的恐惧，项目经理们从以前的经验出发,

制定出了一些控制、监测项目的方法、技巧。这就是方法论产生的原

因。

在SoftwareDevelopment一书中，作者提到了方法论的十三个要

素，基本能够函盖方法论的各个方面：

角色(Roles)

个性(Personality)

技能(Skills)

团队(Teams)

技术(Techniques)

活动(Activities)

过程(Process)

工件(Workproducts)

里程碑(Milestones)

标准(Standards)

质量(Quality)

工具(Tools)

团队价值(TeamValues)

它们之间的关系可以用一幅图来表示:

//Process-Milestones

wingTeamValues

Wnminp—

Qiality]-----Activities-----Teams

RfcvircssiontestsPrcjeclmanager

(AjectmodelDorii'neit?r

Usecase

FojeclplanDesigner

LKC加h

.ccasesProductsTester

TechniquesRule、

Vl\!O5oftFVDJC;'nvy'DevcIcpciN^J.\Dfitlilalior

Sironb^increnienaSITxapro^innm

Microsofti

IW.0义nePersonality

StandardsToolsSkills

图1.方法论的十三个要素

很多的方法论，都涉及了上面列举的十三要素中的部分要素，因此，

我们可以把方法论看作是一个抽象的、无穷的超集，而现实中的方法

论都是指超集的一个有限的子集而已。它们之间的关系就好像有理数

和1至I」100之间的整数的关系一样。不论是XP,还是UI设计经验之

类，都属于方法论的一个子集，只是这两个子集之间有大小的差别而

已。我们还应该看到，讨论一个完备的方法论是没有意义的，因此这

种方法论铁定不存在，就好像你视图穷举出所有的有理数一样荒唐。

因此，我们关于一个通用的方法论的说法也是无意义的。好的方法论,

比如说XP、水晶系列，它们都有一个适合的范围，因为它们了解一

点，自己并不是一个无所不能的方法论。

在现实中，我们其实不断的在接触方法论。比如说，为了控制项目的

进度，项目经理要求所有的开发人员每周递交一份详细的进度报告，

这就是一种方法、一种技巧。如果把开发过程中的这些技巧系统的组

织起来，就能够成为一种方法论。你可能会说，那一种方法论的产生

也太容易了吧。不，这样产生的方法论并没有太大的实用价值，没有

实用价值的方法论根本就没有存在的必要。因此，一个成功的方法论

是要能够为多个的项目所接受，并且能够成功实现软件的交付的方法

论。

我和我的同事在实践中做了一些试验，希望能够把一些好的方法论应

用于开发团队。试验的结果很无奈，方法论实施的效果并不理想，一

开始我们认为是方法本身的原因，到后来，我们发现事情并不是这么

简单。在试验的过程中，开发人员一致认同方法论的优势所在，但是

在实施过程中，鲜有坚持的下来的。在AgileSoftwareDevelopment

中，我发现作者遇到了和我们一样的问题。

AlistairCockburn在和大量的项目团队的访谈之后，写成了Agile

SoftwareDevelopment一书。在访谈之前，他笃定自己将会发现高度

精确的过程控制是成功的关键所在，结果他发现事实并非如此，他把

他的发现归结为7条定律。而我在实际中的发现也包含在这七条定律

中，总结起来就只有两点：沟通和反馈。

只要能够保证良好的沟通和即时的反馈，那么开发团队即使并没有采

用先进的方法论，一样可以成功。相反，那些“高质量”的团队却往往

由于缺乏这两个因素而导致失败（我们这里指的失败是用户拒绝使用

最终的软件）。最有效，而成本也最低的沟通方法就是面对面（facet。

face）的沟通，而随着项目团队的变大，或是另外一些影响因素的加

入（比如地理位置的隔绝），面对面的沟通越来越难实现，这导致沟

通的的成本逐渐加大，质量也慢慢下降。但这并不是说非面对面的沟

通不可，重要的是我们需要知道不同的沟通方式的成本和质量并不相

同。XP方法尤为强调面对面的沟通，通过现场客户、站立会议、结

对编程等方式来保证沟通的有效。在我的经验中，一个开发团队其实

是需要多种沟通方式的结合的。完全的面对面的沟通对某些团队来说

是很难实现的，那么问题的关键就在于你如何应用沟通的方式来达到

你希望的效果。在前不久结束的欧莱雅创业计划大赛上，有一支团队

特别引人注目，他们彼此间素未谋面，仅仅凭借Internet和电话完成

了高效的合作。他们虽然没有使用面对面的沟通方式，但是仍然达成

了既定的目标。软件开发也是一样的，面对面的沟通是非常有必要的,

但其它的沟通方式也是需要的。

再看反馈，不论是控制进度，还是保证客户的满意度，这些活动都需

要管理成本。软件开发中的管理成本的一个通性就是伴随有中间产出

物（intermediatedelivery）o比如说我们的需求规约、分析文档、设计

文档、测试计划，这些都属于中间产出物。中间产出物的增加将会带

来效率下降的问题，因为开发人员的时间都花在了完成中间产出物的

工作上，花在给软件新功能上的时间就减少了。而中间产出物的主要

目的是两个，一个是为了保证软件如客户所愿，例如需求规约；另一

个是为了作为团队中的其他成员工作的输入，例如开发计划、测试计

划等。因此，我们也可以针对这两点来商讨对策，一种是采用迭代的

思想，提高软件发布的频率，以保证客户的需求被确实的满足，另一

种就是缩小团队的沟通范围，保证成员能够从其他人那里得到新的思

路，而不是撰写规范的内部文档（内部文档指那些仅为内部开发人员

之间的沟通所需要的文档）。

因此，一个软件项目的成功和你采用的开发方法论并没有直接的关

系。

重量

我们根据把拥有大量artifact（RUP官方翻译为工件，意思是软件开

发过程中的中间产物，如需求规约、设计模型等）和复杂控制的软件

开发方法称为重型(HeavyWeight)方法，相对的，我们称artifact

较少的方法为轻型(LightWeight)方法。在传统的观念中，我们认

为重型方法要比轻型安全许多。因为我们之所以想出重型方法，就是

由于在中大型的项目中，项目经理往往远离代码，他无法有效的了解

目前的工程的进度、质量、成本等因素。为了克服未知的恐惧感，项

目经理制定了大量的中间管理方法，希望能够控制整个项目，最典型

的莫过于要求开发人员频繁的递交各种表示项目目前状态的报告。

在PlanningXP一书中有一段讨论轻重型方法论的精辟论述，它把重

型方法论归结为一种防御性的姿态(defensiveposture),而把轻型方

法论归结为一种渴望成功(Plantowin)的心态。如果你是采用了防

御性姿态，那么你的工作就集中在防止和跟踪错误上，大量的工作流

程的制定，是为了保证项目不犯错误，而不是项目成功。而这种方法

也不可谓不好，但前提是如果整个团队能够满足前面所提到的两个条

件的话，项目也肯定会成功，但是重型方法论的一个弊端就在于，大

家都在防止错误，都在惧怕错误，因此人和人之间的关系是很微妙的,

要达到充分的沟通也是很难的。最终，连对人的评价也变成是以避免

错误的多寡作为考评的依据，而不是成就。我们在做试验的时候，一

位项目经理开玩笑说，"方法论源自项目经理的恐惧，这没错。但最

糟糕的是整个团队只有项目经理一个人恐惧，如果能够做到人人的恐

惧，那大家也就没有什么好恐惧的了。"这句话提醒了我们，如果一

个团队的精神就是力求成功，那么这支团队的心态就和其它的团队不

同了，尤其是对待错误的心态上。根本就没有必要花费大量的精力来

预防错误，错误犯了就犯了，即时改正就可以了。这其实就是渴望成

功的心态。

方法论的艺术

管理，被称为科学和艺术的融合体，而管理的艺术性部分很大程度的

体现为人的管理上。我说，方法学，一样是科学和艺术的融合体。这

是有依据的，其实方法论和管理学是近亲关系，管理学中有一门分支

是项目管理，而在软件组织中，项目管理是非常重要的，方法学就是

一种针对软件开发的一种特定的项目管理（或是项目管理的一个子

集）。

重型方法最大的一个问题就在于他不清楚或忽略了艺术这个层次，忽

视了人的因素，把人做为一个计量单位，一种资源，一种线性元素。

而人的要素在软件开发中是非常重要的，软件开发实际上是一种知

识、智力的转移过程，最终形成的产品是一种知识产品，它的成本取

决于开发者的知识价值，因此，人是最重要的因素。而人这个要素是

很难衡量的，每个人都有不同的个性、想法、经验、经历，这么多复

杂的因素加在一起，就导致了人的不可预见性。因此，我们强调管人

的艺术。

最简单的例子是，在重型方法中，我们的基本假设是对人的不信任。

项目经理要控制项目。但不信任就会产生很多的问题，比如士气不高,

计划赶不上变化，创新能力低下，跳槽率升高等等。人都是希望被尊

重的，技术人员更看重这一点，而很多公司也口口声声说自己多么多

么以人为本，可是采用的却是以不信任人为前提的开发方法，言行不

一。我们说敏捷方法的出发点是相互信任，做到这一点是很难的，但

是一旦做到了，那这个团队就是非常具有竞争力的。因此，这就产生

了一个问题，在没有做到完全的相互信任之前，我们到底相不相信他

人呢，这就是我提到的艺术性的问题，什么时候你要相信人？什么时

候你不相信人，这些都是需要权衡的问题，也都是表现你艺术性的问

题。

敏捷

敏捷代表着有效和灵活。我们称那些轻型的、有效的方法为敏捷方法。

在重型方法中，我们在一些不必要、重复的中间环节上浪费了太多的

精力，而敏捷则避免了这种浪费。我们的文章将会重点的讨论敏捷

(Agile)方法论的思想，敏捷这个名字的前身就是轻型。目前已经

有了一个敏捷联盟，他们制定了敏捷宣言：

Individualsandinteractionsoverprocessesandtools.

Workingsoftwareovercomprehensivedocumentation.

Customercollaborationovercontractnegotiation.

Respondingtochangeoverfollowingaplan.

而我对敏捷的理解包括了儿个方面:

较低的管理成本和高质量的产出。软件开发存在两个极端：一个是没

有任何的管理成本，所有的工作都是为了软件的产出，但是这种方式

却往往导致软件开发过程的混沌，产品的低质量，团队士气的低落。

另一个是大量管理活动的加入，评审、变更管理，缺陷跟踪，虽然管

理活动的加入能够在一定程度上提高开发过程的有序性，但是成本却

因此提高，更糟糕的是，很容易导致团队的低效率，降低创新能力。

因此，敏捷方法视图寻找一个平衡点，用低成本的管理活动带来最大

的产出，即软件的高质量。

尊重人性。敏捷方法尊重人性，强调效率。软件开发可以说是一种脑

力的投入，如果不能保证开发人员的自愿投入，产品就肯定要打折扣。

事实多次的证明，一个愿意投入的开发人员和一个不愿意投入的开发

人员效率相差在三倍以上，对组织的贡献更是在十倍以上。

沟通和反馈是一切的基础。我们已经讨论过沟通的重要程度，而即时

的反馈是拥抱变化的前提条件。

客户是上帝。没有客户就没有一切，客户的重要性可以用一句话来形

容，就是以合理的成本建造合适的软件(buildtherightsystematthe

rightcost)o

敏捷其实也有轻重之分，关键在于是否能够做到有效和灵活。因此，

敏捷方法论提倡的一个思想是"刚好够(barelysufficient)"o不过这

个"刚好够"可不是那么容易判断的。一支8个人的团队采用XP方法,

随着方法的熟练使用，团队的能力在不断的增强，能够处理的问题越

越来越复杂，也许他们能够处理采用重型方法的20个人团队能够处

理的问题。可是如果团队的人数突然增加到12人，这支团队肯定就

会出问题，他的表现可能还不如那支20个人的团队了。人数增加了

的时候，原先的方法肯定还做适当的调整，比如说，在原先的敏捷方

法上增加一些重型方法的技巧。我们不能够要求一支6个人的团队和

一支20个人的团队用同样的方法，前者可能采用轻一些的敏捷方法,

后者可能采用重一些的敏捷方法，关键的问题在于，两支团队都把重

点放在沟通、反馈、频繁交付软件这些关键的因素上，也就是做到有

效和灵活。

架构设计

架构(Architecture)(也有被称为体系结构的)是软件设计中非常重

要的一个环节。软件开发的过程中只要需求和架构确定之后，这个软

件就基本上可以定型了。这就好比骨骼确定了，这个人的体形就不会

有很大的变化。因此我选择了架构设计来讨论敏捷软件开发(需求我

已经写过了)。我们在前面讨论过超集和子集的概念，因此我们接下

去要讨论的架构设计也是一个很小的子集。方法论如果没有经历过多

个项目的检验是不能称为成功的方法论的，我也并不认为我的架构设

计就是一个好的方法论，但引玉还需抛砖，他的主要目的是为了传播

一种思想。因此，我采用了模式语言(PLOP)做为写作架构设计的

形式，主要的原因就是模式是一种很好的组织思想的方法。

因此，在我们接下去的历程中，我们集中讨论的东西就围绕着架构、

方法学、敏捷这三个要素展开。这篇文章并不是讨论如何编码实现软

件架构的，也不要单纯的把它看作架构设计的指南，其实文中的很多

思想来自于方法论，因此提到的很多架构设计的思想也适用于其它工

作，如果能够了解这一点，看这篇文章的收获可能会更多一些。

2.敏捷思维一架构设计中的方法学(2)-架构设计的敏捷

视图

通过上一章的介绍，我们对敏捷和方法有了一个大致的了解，从这一

章起，我们开始对软件开发过程中架构设计的研究。记住一点，我们

并不是为了架构设计而研究架构设计，我们的目的在于敏捷方法学的

应用。

架构设计是一种权衡(trade-off)。一个问题总是有多种的解决方案。

而我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的

矛盾体之间做出一个权衡。我们在设计的过程总是可以看到很多的矛

盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一

对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件

稳定运行的要求，就必然会影响我们对软件易于扩展的期望。我们希

望软件简单明了，却增加了我们设计的复杂度。没有一个软件能够满

足所有的要求，因为这些要求之间带有天生的互斥性。而我们评价架

构设计的好坏的依据，就只能是根据不同要求的轻重缓急，在其间做

出权衡的合理性。

目标

我们希望一个好的架构能够：

重用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的

代码、之前的设计。重用是我们不断追求的目标之一，但事实上，做

到这一点可没有那么容易。在现实中，人们已经在架构重用上做了很

多的工作，工作的成果称为框架(Framework),比如说Windows的

窗口机制、J2EE平台等。但是在企业商业建模方面，有效的框架还

非常的少。

透明：有些时候，我们为了提高效率，把实现的细节隐藏起来，仅把

客户需求的接口呈现给客户。这样，具体的实现对客户来说就是透明

的。一个具体的例子是我们使用JSP的tag技术来代替JSP的嵌入代

码，因为我们的HTML界面人员更熟悉tag的方式。

延展：我们对延展的渴求源于需求的易变。因此我们需要架构具有一

定的延展性，以适应未来可能的变化。可是，如上所说，延展性和稳

定性，延展性和简单性都是矛盾的。因此我们需要权衡我们的投入/

产出比。以设计出具有适当和延展性的架构。

简明：一个复杂的架构不论是测试还是维护都是困难的。我们希望架

构能够在满足目的的情况下尽可能的简单明了。但是简单明了的含义

究竟是什么好像并没有一个明确的定义。使用模式能够使设计变得简

单，但这是建立在我熟悉设计模式的基础上。对于一个并不懂设计模

式的人，他会认为这个架构很复杂。对于这种情况，我只能对他说，

去看看设计模式。

高效：不论是什么系统，我们都希望架构是高效的。这一点对于一些

特定的系统来说尤其重要。例如实时系统、高访问量的网站。这些值

的是技术上的高效，有时候我们指的高效是效益上的高效。例如，一

个只有儿十到一百访问量的信息系统，是不是有必要使用EJB技术，

这就需要我们综合的评估效益了。

安全：安全并不是我们文章讨论的重点，却是架构的一个很重要的方

面。

规则

为了达到上述的目的，我们通常需要对架构设计制定一些简单的规

则：

功能分解

顾名思义，就是把功能分解开来。为什么呢？我们之所以很难达到重

用目标就是因为我们编写的程序经常处于一种好像是重复的功能，但

又有轻微差别的状态中。我们很多时候就会经不住诱惑，用拷贝粘贴

再做少量修改的方式完成一个功能。这种行为在XP中是坚决不被允

许的。XP提倡"Onceandonlyonce",目的就是为了杜绝这种拷贝修

改的现象。为了做到这一点，我们通常要把功能分解到细粒度。很多

的设计思想都提倡小类，为的就是这个目的。

所以，我们的程序中的类和方法的数目就会大大增长，而每个类和方

法的平均代码却会大大的下降。可是，我们怎么知道这个度应该要如

何把握呢，关于这个疑问，并没有明确的答案，要看个人的功力和具

体的要求，但是一般来说，我们可以用一个简单的动词短语来命名类

或方法的，那就会是比较好的分类方法。

我们使用功能分解的规则，有助于提高重用性，因为我们每个类和方

法的精度都提高了。这是符合大自然的原则的，我们研究自然的主要

的一个方向就是将物质分解。我们的思路同样可以应用在软件开发

上。除了重用性，功能分解还能实现透明的目标，因为我们使用了功

能分解的规则之后，每个类都有自己的单独功能，这样，我们对一个

类的研究就可以集中在这个类本身，而不用牵涉到过多的类。

根据实际情况决定不同类间的耦合度

虽然我们总是希望类间的耦合度比较低，但是我们必须客观的评价耦

合度。系统之间不可能总是松耦合的，那样肯定什么也做不了。而我

们决定耦合的程度的依据何在呢？简单的说，就是根据需求的稳定

性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的需

求，我们完全可以把各类设计成紧耦合的（我们虽然讨论类之间的耦

合度，但其实功能块、模块、包之间的耦合度也是一样的），因为这

样可以提高效率，而且我们还可以使用一些更好的技术来提高效率或

简化代码，例如Java中的内部类技术。可是，如果需求极有可能变

化，我们就需要充分的考虑类之间的耦合问题，我们可以想出各种各

样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来

隔离不同的类，这个抽象层次可以是具体的类，也可以是接口，或是

一组的类（例如Beans）。我们可以借用Java中的一句话来概括降低

耦合度的思想：”针对接口编程，而不是针对实现编程。”

设计不同的耦合度有利于实现透明和延展。对于类的客户（调用者）

来说，他不需要知道过多的细节（实现），他只关心他感兴趣的（接

口）。这样，目标类对客户来说就是一个黑盒子。如果接口是稳定的,

那么，实现再怎么扩展，对客户来说也不会有很大的影响。以前那种

牵一发而动全身的问题完全可以缓解甚至避免。

其实，我们仔细的观察GOF的23种设计模式，没有一种模式的思路

不是从增加抽象层次入手来解决问题的。同样，我们去观察Java源

码的时候，我们也可以发现，Java源码中存在着大量的抽象层次，初

看之下，它们什么都不干，但是它们对系统的设计起着重大的作用。

够用就好

我们在上一章中就谈过敏捷方法很看重刚好够用的问题，现在我们结

合架构设计来看：在同样都能够满足需要的情况下，一项复杂的设计

和一项简单的设计，哪一个更好。从敏捷的观点来看，一定是后者。

因为目前的需求只有10项，而你的设计能够满足100项的需求，只

能说这是种浪费。你在设计时完全没有考虑成本问题，不考虑成本问

题，你就是对开发组织的不负责，对客户的不负责。

应用模式

这篇文章的写作思路很多来源于对模式的研究。因此，文章中到处都

可以看到模式思想的影子。模式是一种整理、传播思想的非常优秀的

途径，我们可以通过模式的方式学习他人的经验。一个好的模式代表

了某个问题研究的成果，因此我们把模式应用在架构设计上，能够大

大增强架构的稳定性。

抽象

架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术

抽象。架构是现实世界的一个模型，所以我们首先需要对现实世界有

一个很深的了解，然后我们还要能够熟练的应用技术来实现现实世界

到模型的映射。因此，我们在对业务或技术理解不够深入的情况下，

就很难设计出好的架构。当然，这时候我们发现一个问题：怎样才能

算是理解足够深入呢。我认为这没有一个绝对的准则。

一次，一位朋友问我：他现在做的系统有很大的变化，原先设计的工

作流架构不能满足现在的要求。他很希望能够设计出足够好的工作流

架构，以适应不同的变化。但是他发现这样做无异于重新开发一个

lotusnotes。我听了他的疑问之后觉得有两点问题：

首先，他的开发团队中并没有工作流领域的专家。他的客户虽然了解

自己的工作流程，但是缺乏足够的理论知识把工作流提到抽象的地

步。显然，他本身虽然有技术方面的才能，但就工作流业务本身，他

也没有足够的经验。所以，设计出象notes那样的系统的前提条件并

不存在。

其次，开发一个工作流系统的目的是什么。原先的工作流系统运作的

不好，其原因是有变化发生。因此才有改进工作流系统的动机出现。

可是，毕竟notes是为了满足世界上所有的工作流系统而开发的，他

目前的应用肯定达不到这个层次。

因此，虽然做不到最优的业务抽象，但是我们完全可以在特定目的下，

特定范围内做到最优的业务抽象。比如说，我们工作流可能的变化是

工组流路径的变化。我们就完全可以把工作流的路径做一个抽象，设

计一个可以动态改变路径的工作流架构。

有些时候，我们虽然在技术上和业务上都有所欠缺，没有办法设计出

好的架构。但是我们完全可以借鉴他人的经验，看看类似的问题别人

是如何解决的。这就是我们前面提到的模式。我们不要把模式看成是

一个硬性的解决方法，它只是一种解决问题的思路。MartinFowler

曾说："模式和业务组件的区别就在于模式会引发你的思考。"

在《分析模式》一书中，MartinFowler提到了分析和设计的区别。分

析并不仅仅只是用用例列出所有的需求，分析还应该深入到表面需求

的的背后，以得到关于问题本质的MentalModel。然后，他引出了概

念模型的概念。概念模型就类似于我们在讨论的抽象。MartinFowler

提到了一个有趣的例子，如果要开发一套软件来模拟桌球游戏，那么，

用用例来描述各种的需求，可能会导致大量的运动轨迹的出现。如果

你没有了解表面现象之后隐藏的运动定律的本质，你可能永远无法开

发出这样一个系统。

关于架构和抽象的问题，在后面的文章中有一个测量模式的案例可以

很形象的说明这个问题。

架构的一些误解

我们花了一些篇幅来介绍架构的一些知识。现在回到我们的另一个主

题上来。对于一个敏捷开发过程，架构意味着什么，我们该如何面对

架构。这里我们首先要澄清一些误解：

误解1:架构设计需要很强的技术能力。从某种程度来说，这句话并

没有很大的错误。毕竟，你的能力越强，设计出优秀架构的儿率也会

上升。但是能力和架构设计之间并没有一个很强的联系。即使是普通

的编程人员，他一样有能力设计出能实现目标的架构。

误解2：架构由专门的设计师来设计，设计出的蓝图交由程序员来实

现。我们之所以会认为架构是设计师的工作，是因为我们喜欢把软件

开发和建筑工程做类比。但是，这两者实际上是有着很大的区别的。

关键之处在于，建筑设计已经有很长的历史，已经发展出完善的理论,

可以通过某些理论（如力学原理）来验证设计蓝图。可是，对软件开

发而言，验证架构设计的正确性，只能够通过写代码来验证。因此,

很多看似完美的架构，往往在实现时会出现问题。

误解3：在一开始就要设计出完善的架构。这种方式是最传统的前期

设计方式。这也是为XP所摒弃的一种设计方式。主要的原因是，在

一开始设计出完美的架构根本就是在自欺欺人。因为这样做的基本假

设就是需求的不变性。但需求是没有不变的（关于需求的细节讨论，

请参看拙作『需求的实践』）。这样做的坏处是，我们一开始就限制了

整个的软件的形状。而到实现时，我们虽然发现原来的设计有失误之

处，但却不愿意面对现实。这使得软件畸形的生长。原本一些简单的

问题，却因为别扭的架构，变得非常的复杂。这种例子我们经常可以

看到，例如为兼容前个版本而导致的软件复杂性。而2000年问题，

TCP/IP网络的安全性问题也从一个侧面反映了这个问题的严重性。

误解4：架构蓝图交给程序员之后，架构设计师的任务就完成了。和

误解2一样，我们借鉴了建筑工程的经验。我们看到建筑设计师把设

计好的蓝图交给施工人员，施工人员就会按照图纸建造出和图纸一模

一样的大厦。于是，我们也企图在软件开发中使用这种模式。这是非

常要命的。软件开发中缺乏一种通用的语言，能够充分的消除设计师

和程序员的沟通隔阂。有人说，UML不可以吗？UML的设计理念是

好的，可以减轻沟通障碍问题。可是要想完全解决这个问题，UML

还做不到。首先，程序员都具有个性化的思维，他会以自己的思维方

式去理解设计，因为从设计到实现并不是一项机械的劳动，还是属于

一项知识性的劳动(这和施工人员的工作是不同的)。此外，对于程

序员来说，他还极有可能按照自己的想法对设计图进行一定的修改，

这是非常正常的一项举动。更糟的是，程序员往往都比较自负，他们

会潜意识的排斥那些未经过自己认同的设计。

架构设计的过程模式

通常我们认为模式都是用在软件开发、架构设计上的。其实，这只是

模式的一个方面。模式的定义告诉我们，模式描述了一个特定环境的

解决方法，这个特定环境往往重复出现，制定出一个较好的解决方法

有利于我们在未来能有效的解决类似的问题。其实，在管理学上，也

存在这种类似的这种思维。称为结构性问题的程序化解决方法。所以

呢，我们完全可以把模式的思想用在其它的方面，而目前最佳的运用

就是过程模式和组织模式。在我们的文章中，我们仅限于讨论过程模

式。

我们讨论的过程仅限于面向对象的软件开发过程。我们称之为OOSP

(object-orientedsoftwareprocess)。因为我们的过程需要面向对象特

性的支持。当然，我们的很多做法一样可以用在非OO的开发过程中，

但是为了达到最佳的效果，我建议您使用OO技术。

那么，我们应该如何避开这些误区呢，或者，换句话说，敏捷软件开

发是如何做架构设计的。这里有儿种过程模式:

在接下去的篇幅中，我们会逐一对各种过程模式进行介绍。然后再站

在全局的角度分析各个模式之间的关系，并将之归纳为架构设计的模

式。

敏捷型架构设计

我们说我们这里列出的过程模式是敏捷型的，关于这一点我们会在接

下去的各个章节中验证这一点。我们列出的各个过程模式并不是完全

照搬敏捷型方法，因为在各种敏捷型方法中，某些技巧适合架构设计,

某些方法则不适合架构设计。因此，我们在采用一种方法和技术前，

我们会问自己几个简单的问题：

该方法/技巧有什么价值？

该方法/技巧需要多大的投入？从创建、维护、培训等多方面估计。

比较该方法/技巧的投入和价值，它还值得我们采用吗？

是否还有其它价值/投入比更高的方法/技巧呢？

在我们的文章中，每一种方法/技巧的讨论都回答了前三个问题，至

于第四个问题，希望有同行能够告诉我。

3.敏捷思维一架构设计中的方法学(3)-源自需求

我们说，和重型方法偏重于计划、过程和中间产物不同，敏捷方法更

加看重人和沟通。人和沟通永远是第一位的，而计划、过程和中间产

物，那只是保证沟通、实现目标的手段。这并不是说计划、过程、中

间产物不重要，只是不能够本末倒置

注：我们把中间产物定义为为了实现跨边界的沟通而制定的文档、模

型、代码。例如设计文档、数据模型等。参考RUP的Artifact。

评判软件成功的标准有很多，对于敏捷方法论来说，成功的标准首先

在于交付可用的软件。为了保证软件的可用性，最重要的就是做好需

求。做好需求的方法有很多（参见拙作需求的实践），但这并不是我

们讨论的主题。对于我们要开始的架构设计的工作来说，从需求出发

来设计架构，这就是保证软件可用性的一个基本的保证。

Context

我们如何开始我们的架构设计工作?

Problem

我们在进行架构设计的时候，往往主要考虑的都是平台、语言、开发

环境、数据库等一些基本问题，可是对于和客户的具体情况密切相关

的一些问题却很少系统的考虑。甚至还存在一种误区，认为架构设计

无非就是写一些空话，套话。这样子做出来架构设计，如何用于指导

软件的实现呢？

IT界的技术层出不穷，面对着如此之多的技术、平台、框架、函数

库，我们如何选择一组适合软件的技术？

每一个客户的软件都有自身的特点，如何才能够设计出符合客户利益

的架构？

软件中往往都充斥着众多的问题，在一开始就把所有的问题都想清楚

往往很难做到，但是如果不解决问题，风险又居高不下。

Solution

针对需求设计架构。

例1：城市中自来水管的架设是一项非常的复杂的工程。为了需要满足每家每户

的需要,自来水管组成了一个庞大的网络。在这样一个复杂的网络中,如何完成

铺设的任务呢。一般的做法是,先找出问题的根源,也就是水的源头。从水源铺

设一条管道通至城市,然后根据城市的区域划分,设计出主管道,剩下的就是使

用的问题了,每家每户的管道最终都是连到主管道上的。因此,虽然自来水网络

庞大复杂。但是真正的主管道的非常简单的。

架构设计就是铺设软件的主管道（例1）。我们根据什么来制定主管

道的粗细、路径等因素呢？很明显，是根据城市的人口、地理位置、

水源等因素来决定的。对应到软件设计也是一样的。城市的各因素就

是软件中的各种需求：功能需求、非功能需求、变化案例等等。

一般来说，功能需求决定业务架构、非功能需求决定技术架构，变化

案例决定架构的范围。需求方面的知识告诉我们，功能需求定义了软

件能够做些什么。我们需要根据业务上的需求来设计业务架构，以使

得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效

率上的一些约束、规则。而我们的技术架构要能够满足这些约束和规

则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和

非功能需求，我们就可以确定一个需求的范围，进而确定一个架构的

范围。

例2：我们打算开发一个字处理软件,功能需求可以简单概括为格式化用户输入

的文字,非功能需求可能是格式化大小为1000K的一段文字的处理速度不能低

于10S,变化案例可能是推出多种语言版本。那么我们在设计业务架构的时候,

我们会集中于如何表示文字、图象、媒体等要素,我们该需要有另外的技术架构

来处理速度问题,比如缓冲技术,对于变化案例,我们也要考虑相应的架构,比

如把字体独立于程序包的设计。

从例2中，我们看到自已字处理软件的儿种需求的范例。真正的字处

理软件要复杂的多。而我们最主要的就是必须认识到，架构是来自于

需求的。有什么样的需求就有什么样的架构。试想一下，如果我们没

有对速度的要求，我们还需要考虑这方面的设计吗？我们上面提到了

几种类型的需求对架构的影响，其实还有一个很重要的需求，就是环

境的需求。这并不是一个很重要的需求，但是对于部署（d印10yment）

架构设计来说就特别重要。毕竟，我们开发出的软件是要上"战场”的,

充分的考虑部署问题是非常有必要的。

从需求到架构。

在需求阶段，我们可以得到一些代表需求调研成果的中间产物。比如

说，CRC卡片、基本用例模型、用户素材、界面原型、界面原型流

程图、非功能需求、变化案例等。我们在架构设计阶段的主要工作就

是要把这些需求阶段的中间产物转换为架构设计阶段的中间产物。

图3.需求阶段的中间产物

其实，架构设计就是要完成两项工作，一是分析，二是设计。分析是

分析需求，设计则是设计软件的大致结构。很多的方法论把分析和设

计两种活动分开来，但其实这两者是很难区分的，做分析的时候会想

到如何设计，而思考如何设计反过来又会影响分析的效果。可以说，

他们两者之间是相互联系和不断迭代的。这种形态我们将会在后面的

迭代设计模式中详细的讨论。

在敏捷方法论中,需求最好是迭代进行的,也就是说一点一点的作

需求。这种做法在那些需求变化快的项目中尤其适用。由于我们采用

的流程是一种迭代式的流程，这里我们将会面临着如何对待上一次迭

代的中间产物的问题。如果我们每一次迭代都需要修改已存在的中间

产物，那么这种维护的成本未免过大。因此，敏捷方法论的基本做法

是，扔掉那些已经没有用处的中间产物。还记得在第一章的时候，我

们强调说软件要比文档重要。我们生成中间产物的目的都是为了生成

最终的程序，对于这些已经完成作用的模型，没有必要付出额外的维

护成本。

不要断章取义的采用抛弃模型的做法。因为，抛弃模型的做法需要一

个适合环境的支持。后面会针对这个话题开展大范围的讨论。这里我

们简单的做一个了解：

简单化：简单的模型和简单的程序。模型和程序越复杂，就需要更多

的精力来处理它们。因此，我们尽可能的简化它们，为的是更容易的

处理它们。

高效的沟通渠道：通过增强沟通的效果来减少对中间产物的需要。试

想一下，如果我随时能够从客户那里得到需求的细节资料，那前期的

需求调研就没有必要做的太细致。

角色的交叉轮换：开发人员之间建立起交换角色的机制，这样，能够

尽量的避免各子系统诸侯割据的局面。

清晰的流程：或者我们可以称之为明确的过程。过程在方法论中向来

都是一个重点，敏捷方法论也不例外。开发人员能够清楚的知道，今

天做什么，明天做什么。过程不是给别人看的，而是给自己用的。

工具：好用的工具能够节省大量的时间，这里的工具并不仅仅指

CASE工具，还包括了版本控制工具、自动化测试工具、画图工具、

文档制作和管理工具。使用工具要注意成本和效益的问题。

标准和风格：语言不通是沟通的一个很大的障碍。语言从某个角度来

看属于一种标准、一种风格。因此，一个团队如果采用同样的编码标

准、文档标准、注释风格、制图风格，那么这个团队的沟通效率一定

非常的高。

如果上述的环境你都不具备，或是欠缺好儿项，那你的文档的模型还

是留着的好。

仅针对需求设计架构

仅针对需求设计架构的含义就是说不要做未来才有用的事情。有时

候，我们会把架构考虑的非常复杂，主要的原因就是我们把很多未来

的因素放入到现在来考虑。或者，我们在开发第一个产品的时候就视

图把它做成一个完美的框架。以上的这两种思路有没有错呢？没有

错，这只是如何看待投入的问题，有人希望开始的时候多投入一些，

这样后续的投入就会节省下来。但在现实中，由于需求的不确定性，

希望通过增加开始阶段的投入来将降低未来的投入往往是难以做到

的，框架的设计也绝对不是能够一蹴而就的，此这种做法并不是一个

好的做法。所以我们在后头会着重论述架构设计的简单性和迭代过

程，也就是因为这个理由。

模式

模式将可以帮助我们抓住重点。设计模式在书的一开始（第二章）就

讨论了一个设计一个文档编辑器的问题。为了解决设计文档编辑器引

出的七个问题，一共使用了8种不同的模式。这8种模式的组合其实

就是架构，因为它们解决的，都是系统中最高层的问题。

在实践中，人们发现架构也是存在模式的。比如，对于系统结构设计,

我们使用层模式；对于分布式系统，我们使用代理模式；对于交互系

统，我们使用MVC（模型-视图-控制器）模式。模式本来就是针对

特定问题的解，因此，针对需求的特点，我们也可以采用相应的模式

来设计架构。

在sun网站上提供的宠物商店的范例中，就把MVC模式的思想扩展

成为架构的思想，用于提供不同的界面视图：

MVC架构图，这里提供原图的概览，查看其出处请点击这里。

我们可以了解到在图的背后隐藏着的需求：系统需要支持多种用户界

面，包括为普通用户提供的HTML界面，为无线用户提供的WML

界面，为管理员提供的Swing界面，以及为B2B业务设计的

WebService界面。这是系统最重要的需求，因此，系统的设计者就需

要确定一个稳定的架构，以解决多界面的问题。相对于多界面的问题，

后端的业务处理逻辑都是一致的。比如HTML界面和WML界面的

功能并没有太大的差别。把处理逻辑和界面分离开来还有额外的好

处，可以在添加功能的同时，不涉及界面的改动，反之亦然。这就是

我们在第二篇中提到的耦合度的问题。

MVC模式正可以适用于解决该问题。系统使用控制器来为业务逻辑

选择不同的界面，这就完成了MVC架构的设计思路。在架构设计的

工作中，我们手头上有模式这样一张好牌，有什么理由不去使用它

呢？

例3：信贷系统

在一个银行的信贷帐务处理系统中,我们应该如何把握最初的架构思路呢?从需

求上来看,这个信贷帐务处理系统有几个特点:

它不是一个单独的系统,它需要和外部的其它系统交互,例如信贷业务系统、网

上银行、数据仓库系统等。

在所有的需求中,最复杂的就是它的利息计算的需求,它要求能够支持多种的利

息算法。

因此,我们的架构设计首先是从系统的全局环境开始考虑。其它系统和该系统的

关系如何,应该如何设计系统间的接口。通过需求的调研,系统的接口分为4

和企业外部系统的接口。信贷系统需要连接到人民银行的系统。

和企业内部系统的接口。信贷系统需要能够为数据仓库系统和网上银行系统提供

数据。

和平级系统的接口。信贷系统需要从平级的帐户、资金、财务系统中取数据,并

向帐户、押汇系统发送数据。

具体的实现策略并不在我们的讨论范围之内,但是可以看到,架构策略的制定是

以需求为基础的。我们可以把这部分的需求归纳为技术架构或平台架构。

然后是利息算法的问题,我们经过统计,目前的利息计算方式有四种,可预见到

的还有两种。在一开始的阶段,我们并不需要考虑具体算法的实现,但是我们需

要考虑算法的实现框架,因此我们很自然的想到Strategy模式可以胜任这一工作,

把不同的利息算法封装起来。而我们的工作重点也就转到定义利息算法的接口问

题。通过分析、比较多种利息算法,我们定义了一个最初始的算法接口,然后由

不同的利息算法来实现算法接口。虽然,这个接口目前还不是很完整,但是它会

在接下去的开发过程中慢慢的完善起来。这部分的需求属于业务架构的一部分。

考虑到系统的结构非常的复杂,因此在系统结构的处理上,我们采用了层模式做

为系统的基本结构。此外,在每个层,我们还定义了几个子模块来处理特定的问

题。这样,我们就可以将复杂的功能有序的组织起来。

经过上述的分析,我们对系统的架构有了一个简单的认识,但是还没有结束,-

个架构应该包括系统的各个基本部分,因此,我们还要考虑票据处理、报表、帐

务处理等环节,但是一开始就考虑周详,这要花费大量的时间,因此我们只是简

单的定义了一个原始的架构,然后在后续的开发过程中把这个架构完善起来。

抓住重点

在架构设计一开始，我们就说架构是一种抽象，那就是说，架构设计

摒弃了具体的细节，仅仅抓住软件最高层的概念，也就是最上层、优

先级最高、风险最大的那部分需求。

我们考虑、分析、解决一个问题，一定有一个渐进的过程。架构设计

就是解决问题其中比较早期的一个阶段，我们不会在架构设计这个阶

段投入过多的时间（具体的原因在下文会有讨论），因此关键点在于

我们要能够在架构设计中把握住需求的重点。比如，我们在模式一节

中提到了分布式系统和交互系统，分布和交互就是这两个系统的重

点。那么，如果说我们面对的是一个分布式的交互系统，那么，我们

就需要把这两种特性做为重点来考虑，并以此为基础，设计架构。而

我们提到的宠物商店的范例也是类似的，除了MVC的架构，还有很

多的设计问题需要解决，例如用于数据库访问的数据对象，用于视图

管理的前端控制器，等等（具体使用到的架构模式可以访问sun的网

站）。但是这些相对于MVC模式来说，属于局部的，优先级较低的

部分，可以在架构确定后再来设计。

架构设计和领域专家

一个架构要设计的好，和对需求的理解是分不开的。因此在现实中，

我们发现业务领域专家凭借着他对业务领域的了解，能够帮助开发人

员设计出优秀的架构来。架构是需要抽象的，它是现实社会活动的一

个基本模型，而业务领域的模型仅仅凭开发人员是很难设计出来的。

在ERP的发展史上，我们看到MRP发展为MRPIL在发展到闭环

MRP,直到发展成为现在的ERP,主要的因素是管理思想的演化，

也就是说，对业务领域的理解进步了，架构才有可能进步。

因此，敏捷型架构设计的过程中，我们也非常强调领域专家的作用。

4.敏捷思维一架构设计中的方法学(4)--团队设计

团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指

的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想

成为团队，有很多的工作要做。

我们之所以考虑以团队为单位来考虑架构设计，是因为软件开发本身

就不是一件个人的事情，架构设计更是如此。单个人的思维不免有考

虑欠妥之处，单个人的学识也不可能覆盖所有的学科。而组织有效的

团队却能够弥补这些缺憾。

Context

谁来负责架构的设计?

Problem

在我们的印象中，总认为架构设计是那些所谓架构设计师的专属工

作，他们往往拥有丰富的设计经验和相关的技能，他们不用编写代码,

就能够设计出理论上尽善尽美的架构，配有精美的图例。

问题1:理论上设计近乎完美的架构缺乏程序的证明，在实际应用中

往往会出这样那样的问题。

问题2：设计师设计架构带有很大的主观性，往往会忽视客户的需求,

导致架构无法满足需求。

问题3：实现的程序员对这种架构有抵触的情绪，或是因为不理解架

构而导致架构实现的失败。

问题4：架构师设计架构主要是依据自己的大量经验，设计出的架构

不能真实的反映目前的软件需要。

Solution

团队设计的理论依据是群体决策。和个人决策相比，群体决策的最大

好处就是其结论要更加的完整。而群体决策虽然有其优点，但其缺点

也是很明显的：需要额外付出沟通成本、决策效率低、责任不明确、

等等。但是群体决策如果能够组织得当的话，是能够在架构设计中发

挥很大的优势的。

避免象牙塔式的架构设计

对软件来说，架构设计是一项至关重要的工作。这样的工作交给某个

人是非常危险的。即便这个人再怎么聪明，他也可能会遗漏部分的细

节。组织有效的团队的力量是大大超过个人的力量的，因此团队的成

果较之个人的成果，在稳定性和思考的周密程度上，都要更胜一筹。

ScottW.Ambler在其著作中给出了象牙塔式架构(ivorytower

architecture)的概念：

Anivorytowerarchitectureisonethatisoftendevelopedbyanarchitect

orarchitecturalteaminrelativeisolationtotheday-to-daydevelopment

activitiesofyourprojectteam(s).

例1：在XP中,我们基本上看不到架构设计的影子。并不是说采用XP技术的

团队就不需要架构设计。XP不存在专门的设计时期,它提倡使用一些简单的图

例、比喻的方式来表达软件的架构,而这种的架构设计是无时无刻不在进行的。

其实,XP中的设计采用的就是团队设计的方式,结队编程(PairProgramming)

和代码的集体所有制(CollectiveOwnership)是团队设计的基础,也就是基于口

述的沟通方式。通过采用这样的方式,XP几乎不需要文档来表达架构的设计。

中国现在的软件开发行业中也逐渐出现了象牙塔式的架构设计师。这

些架构师并不参与实际的程序编写，他的工作就是为项目制作出精美

的架构模型，这种架构模型在理论上是相当完美的。

优秀的架构师能够充分的利用现有框架，减少软件的投入，增强软件

的稳定性。这些都没有错，但是问题在于“过犹不及”。象牙塔式架

构师往往会出现文章开始指出的那些问题。架构设计其实并不是非常

复杂的工作，但它要求开发人员具备相关的技能、经验以及对问题域

有一定的了解。开发人员往往都具有相关的技术技能（编程、数据库

设计、建模），而对问题域的理解可以从用户和行业专家那里获得帮

助。因此，在理论上，我们要实现架构设计的团队化是完全可能的。

在上面的象牙塔式架构定义中，我们看到架构师和日常的开发工作是

隔绝的。这样的设计出的架构有很大的局限性。在现实中，我们还会

发现另外一种角色，他来自于开发团队外部，为开发人员提供相关的

技术或业务的培训。这种角色称为教练，在软件开发中是非常重要的

角色，不能够和象牙塔式架构设计师之间画等号。

选择你的设计团队。

软件的架构在软件的生命周期的全过程中都很重要，也就是说，软件

开发团队中的所有人员都需要和架构打交道。因此，最好的团队组织

方式是所有开发人员都参与架构的设计，我们称这种方式为全员参

与。全员参与的方式保证了所有开发人员都能够对架构设计提出自己

的见解，综合多方面的意见，在全体开发人员中达成一致。这种方式

尤其适合于一些小的团队。

还是会有很多的团队由于种种的原因不适合采用全员参与的方式。那

么，组织优秀的开发人员组成设计组也是比较好的方式。一般，我们

选择那些在项目中比较重要的，有较多开发经验，或是理论扎实的那

些人来组成设计组。当然，如果你考虑到为组织培养后续力量，你也

可以让一些新手加入设计组，或是你觉得自己的开发力量不足，邀请

外部的咨询力量介入，这完全取决于具体的情况。

设计组不同于我们之前提到的象牙塔式架构设计师。设计组设计出来

的架构只能称为原始架构，它是需要不断的反馈和改进的。因此，在

架构实现中，设计组的成员将会分布到开发团队的各个领域，把架构

的思想带给所有开发人员，编写代码来检验架构，并获得具体的反馈,

然后所有的成员再集中到设计组中讨论架构的演进。

团队设计中存在的问题

在团队设计的过程，我们会遇到各种各样的问题，首当其冲的就是沟

通成本的问题。架构设计时，需求尚未被充分理解，软件的设计思路

还处于萌发的状态。这样的情况下，团队的每位成员对软件都有独特

的见解，这些可能有些是相同的，有些是互斥的。就好比盲人摸象一

样，他们的观点都代表了软件的一部分或是一方面，但是没有办法代

表软件的全部。

在敏捷方法论中，我们的每一个流程都是迅速进行、不断改进的。架

构设计也是一样，我们不可能在一次架构设计上花费更多的时间。而

团队决策总是倾向于较长的讨论和权衡。

例2：敏捷方法非常注重的就是团队的沟通。沟通是一个很有意思的话题,讲起

来会花费大量的时间,我们这里只是针对架构设计中可能存在的沟通问题做一个

简单的讨论。我们这里假设一个讨论情境,这个情境来源于真实的生活:

项目主管徐辉、设计师李浩、设计师罗亦明正在讨论一个新的软件架构。

"李浩你认为这个软件数据库连接部分应该如何考虑?"徐辉问。

李浩想了想，"我觉得方案A不错…"”方案A肯定有问题!这个软件和上一次的

又不同。"罗亦明打断了李浩的发言。

"你懂什么!你到公司才多久,方案A是经过很长时间的证明的！"发言被打断,

李浩有点恼火,罗亦明进入公司没有多久,但在一些事情上老是和他唱反调。

"我进公司多久和方案A的错误有什么关系！"

在这样一种氛围中,会议的结果可想而知。

例2中的问题在架构设计中时有发生，纯技术的讨论很容易上升称为

争吵。这种情况几乎没有办法完全避免。团队型的决策必然会发生观

念的冲突。控制一定程度内的观念的冲突对团队的决策是有益，但是

如果超出了这个程度就意味着失控了，需要团队领导者的调节。而更

重要的，我们需要注意沟通的技巧：

团队沟通

团队进行架构设计的时候沟通是一个非常需要注意的问题，上述的情

境在软件组织中是经常发生的，因为技术人员很自然认为自己的技术

比别人的好，如果自己的技术受到质疑，那怕对方是抱着讨论的态度,

也无异于自身的权威受到了挑战，面子是无论如何都需要捍卫的。而

沟通如果带上了这样一层主观色彩，那么沟通信息的受众就会潜意识

的拒绝接受信息。相反，他会找出对方话语中的漏洞，准备进行反击。

因此，我们要注意培养一种良好的沟通氛围。

在实际的观察中，我发现团队沟通中存在两种角色，一种是建议者，

他们经常能够提出建议。一种是质疑者，他们对建议提出否定性的看

法。这两种角色是可能互换的，现在的建议者可能就是刚才的质疑者。

质疑者的发言是很能打击建议者的积极性的，而在一个脑力激荡的会

议中，最好是大家都能够扮演建议者的角色，这就要求沟通会议的主

持者能够掌握好这一点，对建议给予肯定的评价，并鼓励大家提出新

的建议。

良好的沟通有助于架构设计工作的开展。一个成员的能力平平的团

队，可以藉由良好的沟通，设计出优秀的架构，而一个拥有一个优秀

成员的团队，如果缺乏沟通，最后可能连设计都出不来。这种例子现

实中可以找到很多。

标准和风格

我们总是在不知不觉之中使用各种各样的标准和风格。在团队设计

中，我们为了提高决策的效率，可以考虑使用统一的标准和风格。统

一的标准和风格并不是一朝一夕形成的。因为每个人都有自己不同的

习惯和经历，强制性的要求开发人员使用统一的标准（风格）容易引

起开发人员的不满。因此在操作上需要注意技巧。对架构设计而言，

比较重要的标准（风格）包括以下的这些类别：

界面设计

流程设计

建模规范

编码规范

持久层设计

测试数据

在我的经验中，有一些组织平时并不注意标准（风格）的积累，认为

这种积累属于雕虫小技，但正是这些小技，能够非常有效的提高沟通

的效率和降低开发人员的学习曲线。试想一下，如果一个团队中所有

人写出的代码都是不同标准和风格的，那么理解起来肯定会困难许

多。当然，我们没有必要自己开发一套标准（风格）出来，现实中有

很多可以直接借用的资料。最好的标准是UML语言，我们可以从

UML的官方网站下载到最新的规范，常用的编码标准更是随处可见。

不过虽然有了统一的标准，如果风格不统一，同样会造成沟通的障碍。

例如下图显示的类图，虽然它们表示的是同一个类，但是由于版型、

可视性、详细程度的差别，看起来又很大的差别。而在其它的标准中,

这种差别也是普遍存在的。因此，我们在使用了统一的标准之后，还

应该使用同样的风格。ScottW.Ambler专门成立了一个网站讨论UML

的建模风格的相关问题，有兴趣的读者可以做额外的阅读。

图4.两种风格的类图

<<businessentity//

Interest

(fromLogicalView)

Interest©RvalueDate：Date

valueDate®>dueDate：Date

dueDate^hbalance：Decimal

balance

♦getBalHc

eDeciinal

getBalanceO♦get1tM

♦eein

set1tMI

在统一的风格的基础上更进一步的是使用术语。使用沟通双方都了解

专门的术语，可以代表大量的信息。最好的术语的范例就是设计模式

的模式名。如果沟通的双方都了解设计模式，那么一方只需要说这部

分的设计可以使用工厂模式，另一方就能够理解，而不用再详细的解

释设计的思路。这种的沟通方式是最高效的，但它所需要的学习曲线

也会比较陡。

团队设计的四明确

为了最大程度的提高团队设计的高效性，可以从4个方面来考虑:

1、明确目标

泛泛的召开架构讨论会议是没有什么意义的，一个没有鲜明主题的会

议也不会有什么结果。在源自需求的模式中，我们谈到说可以有非功

能需求的架构，可以有功能需求的架构。因此，在进行团队设计之前,

我们首先也需要确定，此次要解决什么问题，是讨论业务逻辑的架构,

还是技术架构；是全局性的架构，还是各模块的架构。

2、明确分工

我们之所以重视团队，很重要的额一个原因就是不同的成员有不同的

擅长的区域。有些成员可能擅长于业务逻辑的建模，有的擅长于原型

设计，有的擅长于数据库设计，有的则擅长于Web编程。你能够想

象一个软件没有界面吗？（有些软件可能是这种情况）你能够想象一

个软件只有数据库，而没有处理逻辑吗？因此，架构设计就需要综合

的考虑各个方面，充分利用成员的优势。这就要求团队的各个成员都

能够明确自己的分工。

3、明确责权

除了明确自己的分工，每位成员都需要清楚自己的责任。没有责任,

分工就不会有任何的效力。每位成员都需要明确自己要做些什么。当

然，和责任相对的，没有成员还