敏捷思維-架構(gòu)設(shè)計(jì)中的方法學(xué)

敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)

作者：林星

1.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(1)--從方法論看架構(gòu)設(shè)計(jì)..............1

2.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(2)-架構(gòu)設(shè)計(jì)的敏捷視圖.............12

3.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(3)-源自需求.......................24

4.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(4)—團(tuán)隊(duì)設(shè)計(jì).......................35

5.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(5)—簡(jiǎn)單設(shè)計(jì).......................46

6.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(6)-迭代設(shè)計(jì).......................58

7.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(7)-組合使用模式...................71

8.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(8)—架構(gòu)愿景.......................81

9.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(9)—分層(上).......................91

10.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(10)—分層(下)....................104

11.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(11)-精化和合并...................117

12.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(12)—Refactoring.......................................127

13.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(13)-穩(wěn)定化......................137

14.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(14)—代碼驗(yàn)證...................145

15.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(15)-進(jìn)一步閱讀..................156

在這個(gè)關(guān)于軟件工程的專欄里,作者將應(yīng)用敏施入疝斗方法學(xué)對(duì)軟件

開發(fā)過程中架構(gòu)設(shè)計(jì)進(jìn)行研究。

1.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(1)-從方法論看架構(gòu)

設(shè)計(jì)

方法論對(duì)軟件開發(fā)而言意味著什么？我們?nèi)绾慰创浖_發(fā)中的方

法論？方法論能夠成為軟件開發(fā)的救命稻草嗎？在讀過此文后，這些

疑惑就會(huì)得到解答。

在第一篇文章中，我們來了解標(biāo)題中的一些詞的含義。

方法學(xué)是什么?

敏捷是什么?

為什么討論架構(gòu)?

方法論

方法論的英文為Methodology,詞典中的解釋為"Aseriesofrelated

methodsortechniques"我們可以把它定義為軟件開發(fā)(針對(duì)軟件開發(fā))

的一整套方法、過程、規(guī)則、實(shí)踐、技術(shù)。關(guān)于方法論的出現(xiàn)的問題,

我很贊同AlistairCockburn的一句話，”方法論源于恐懼。"出于對(duì)項(xiàng)

目的超期、成本失控等等因素的恐懼，項(xiàng)目經(jīng)理們從以前的經(jīng)驗(yàn)出發(fā),

制定出了一些控制、監(jiān)測(cè)項(xiàng)目的方法、技巧。這就是方法論產(chǎn)生的原

因。

在SoftwareDevelopment一書中，作者提到了方法論的十三個(gè)要

素，基本能夠函蓋方法論的各個(gè)方面：

角色(Roles)

個(gè)性(Personality)

技能(Skills)

團(tuán)隊(duì)(Teams)

技術(shù)(Techniques)

活動(dòng)(Activities)

過程(Process)

工件(Workproducts)

里程碑(Milestones)

標(biāo)準(zhǔn)(Standards)

質(zhì)量(Quality)

工具(Tools)

團(tuán)隊(duì)價(jià)值(TeamValues)

它們之間的關(guān)系可以用一幅圖來表示:

//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.方法論的十三個(gè)要素

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

我們可以把方法論看作是一個(gè)抽象的、無窮的超集，而現(xiàn)實(shí)中的方法

論都是指超集的一個(gè)有限的子集而已。它們之間的關(guān)系就好像有理數(shù)

和1至I」100之間的整數(shù)的關(guān)系一樣。不論是XP,還是UI設(shè)計(jì)經(jīng)驗(yàn)之

類，都屬于方法論的一個(gè)子集，只是這兩個(gè)子集之間有大小的差別而

已。我們還應(yīng)該看到，討論一個(gè)完備的方法論是沒有意義的，因此這

種方法論鐵定不存在，就好像你視圖窮舉出所有的有理數(shù)一樣荒唐。

因此，我們關(guān)于一個(gè)通用的方法論的說法也是無意義的。好的方法論,

比如說XP、水晶系列，它們都有一個(gè)適合的范圍，因?yàn)樗鼈兞私庖?/p>

點(diǎn)，自己并不是一個(gè)無所不能的方法論。

在現(xiàn)實(shí)中，我們其實(shí)不斷的在接觸方法論。比如說，為了控制項(xiàng)目的

進(jìn)度，項(xiàng)目經(jīng)理要求所有的開發(fā)人員每周遞交一份詳細(xì)的進(jìn)度報(bào)告，

這就是一種方法、一種技巧。如果把開發(fā)過程中的這些技巧系統(tǒng)的組

織起來，就能夠成為一種方法論。你可能會(huì)說，那一種方法論的產(chǎn)生

也太容易了吧。不，這樣產(chǎn)生的方法論并沒有太大的實(shí)用價(jià)值，沒有

實(shí)用價(jià)值的方法論根本就沒有存在的必要。因此，一個(gè)成功的方法論

是要能夠?yàn)槎鄠€(gè)的項(xiàng)目所接受，并且能夠成功實(shí)現(xiàn)軟件的交付的方法

論。

我和我的同事在實(shí)踐中做了一些試驗(yàn)，希望能夠把一些好的方法論應(yīng)

用于開發(fā)團(tuán)隊(duì)。試驗(yàn)的結(jié)果很無奈，方法論實(shí)施的效果并不理想，一

開始我們認(rèn)為是方法本身的原因，到后來，我們發(fā)現(xiàn)事情并不是這么

簡(jiǎn)單。在試驗(yàn)的過程中，開發(fā)人員一致認(rèn)同方法論的優(yōu)勢(shì)所在，但是

在實(shí)施過程中，鮮有堅(jiān)持的下來的。在AgileSoftwareDevelopment

中，我發(fā)現(xiàn)作者遇到了和我們一樣的問題。

AlistairCockburn在和大量的項(xiàng)目團(tuán)隊(duì)的訪談之后，寫成了Agile

SoftwareDevelopment一書。在訪談之前，他篤定自己將會(huì)發(fā)現(xiàn)高度

精確的過程控制是成功的關(guān)鍵所在，結(jié)果他發(fā)現(xiàn)事實(shí)并非如此，他把

他的發(fā)現(xiàn)歸結(jié)為7條定律。而我在實(shí)際中的發(fā)現(xiàn)也包含在這七條定律

中，總結(jié)起來就只有兩點(diǎn)：溝通和反饋。

只要能夠保證良好的溝通和即時(shí)的反饋，那么開發(fā)團(tuán)隊(duì)即使并沒有采

用先進(jìn)的方法論，一樣可以成功。相反，那些“高質(zhì)量”的團(tuán)隊(duì)卻往往

由于缺乏這兩個(gè)因素而導(dǎo)致失敗（我們這里指的失敗是用戶拒絕使用

最終的軟件）。最有效，而成本也最低的溝通方法就是面對(duì)面（facet。

face）的溝通，而隨著項(xiàng)目團(tuán)隊(duì)的變大，或是另外一些影響因素的加

入（比如地理位置的隔絕），面對(duì)面的溝通越來越難實(shí)現(xiàn)，這導(dǎo)致溝

通的的成本逐漸加大，質(zhì)量也慢慢下降。但這并不是說非面對(duì)面的溝

通不可，重要的是我們需要知道不同的溝通方式的成本和質(zhì)量并不相

同。XP方法尤為強(qiáng)調(diào)面對(duì)面的溝通，通過現(xiàn)場(chǎng)客戶、站立會(huì)議、結(jié)

對(duì)編程等方式來保證溝通的有效。在我的經(jīng)驗(yàn)中，一個(gè)開發(fā)團(tuán)隊(duì)其實(shí)

是需要多種溝通方式的結(jié)合的。完全的面對(duì)面的溝通對(duì)某些團(tuán)隊(duì)來說

是很難實(shí)現(xiàn)的，那么問題的關(guān)鍵就在于你如何應(yīng)用溝通的方式來達(dá)到

你希望的效果。在前不久結(jié)束的歐萊雅創(chuàng)業(yè)計(jì)劃大賽上，有一支團(tuán)隊(duì)

特別引人注目，他們彼此間素未謀面，僅僅憑借Internet和電話完成

了高效的合作。他們雖然沒有使用面對(duì)面的溝通方式，但是仍然達(dá)成

了既定的目標(biāo)。軟件開發(fā)也是一樣的，面對(duì)面的溝通是非常有必要的,

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

再看反饋，不論是控制進(jìn)度，還是保證客戶的滿意度，這些活動(dòng)都需

要管理成本。軟件開發(fā)中的管理成本的一個(gè)通性就是伴隨有中間產(chǎn)出

物（intermediatedelivery）o比如說我們的需求規(guī)約、分析文檔、設(shè)計(jì)

文檔、測(cè)試計(jì)劃，這些都屬于中間產(chǎn)出物。中間產(chǎn)出物的增加將會(huì)帶

來效率下降的問題，因?yàn)殚_發(fā)人員的時(shí)間都花在了完成中間產(chǎn)出物的

工作上，花在給軟件新功能上的時(shí)間就減少了。而中間產(chǎn)出物的主要

目的是兩個(gè)，一個(gè)是為了保證軟件如客戶所愿，例如需求規(guī)約；另一

個(gè)是為了作為團(tuán)隊(duì)中的其他成員工作的輸入，例如開發(fā)計(jì)劃、測(cè)試計(jì)

劃等。因此，我們也可以針對(duì)這兩點(diǎn)來商討對(duì)策，一種是采用迭代的

思想，提高軟件發(fā)布的頻率，以保證客戶的需求被確實(shí)的滿足，另一

種就是縮小團(tuán)隊(duì)的溝通范圍，保證成員能夠從其他人那里得到新的思

路，而不是撰寫規(guī)范的內(nèi)部文檔（內(nèi)部文檔指那些僅為內(nèi)部開發(fā)人員

之間的溝通所需要的文檔）。

因此，一個(gè)軟件項(xiàng)目的成功和你采用的開發(fā)方法論并沒有直接的關(guān)

系。

重量

我們根據(jù)把擁有大量artifact（RUP官方翻譯為工件，意思是軟件開

發(fā)過程中的中間產(chǎn)物，如需求規(guī)約、設(shè)計(jì)模型等）和復(fù)雜控制的軟件

開發(fā)方法稱為重型(HeavyWeight)方法，相對(duì)的，我們稱artifact

較少的方法為輕型(LightWeight)方法。在傳統(tǒng)的觀念中，我們認(rèn)

為重型方法要比輕型安全許多。因?yàn)槲覀冎韵氤鲋匦头椒?，就?/p>

由于在中大型的項(xiàng)目中，項(xiàng)目經(jīng)理往往遠(yuǎn)離代碼，他無法有效的了解

目前的工程的進(jìn)度、質(zhì)量、成本等因素。為了克服未知的恐懼感，項(xiàng)

目經(jīng)理制定了大量的中間管理方法，希望能夠控制整個(gè)項(xiàng)目，最典型

的莫過于要求開發(fā)人員頻繁的遞交各種表示項(xiàng)目目前狀態(tài)的報(bào)告。

在PlanningXP一書中有一段討論輕重型方法論的精辟論述，它把重

型方法論歸結(jié)為一種防御性的姿態(tài)(defensiveposture),而把輕型方

法論歸結(jié)為一種渴望成功(Plantowin)的心態(tài)。如果你是采用了防

御性姿態(tài)，那么你的工作就集中在防止和跟蹤錯(cuò)誤上，大量的工作流

程的制定，是為了保證項(xiàng)目不犯錯(cuò)誤，而不是項(xiàng)目成功。而這種方法

也不可謂不好，但前提是如果整個(gè)團(tuán)隊(duì)能夠滿足前面所提到的兩個(gè)條

件的話，項(xiàng)目也肯定會(huì)成功，但是重型方法論的一個(gè)弊端就在于，大

家都在防止錯(cuò)誤，都在懼怕錯(cuò)誤，因此人和人之間的關(guān)系是很微妙的,

要達(dá)到充分的溝通也是很難的。最終，連對(duì)人的評(píng)價(jià)也變成是以避免

錯(cuò)誤的多寡作為考評(píng)的依據(jù)，而不是成就。我們?cè)谧鲈囼?yàn)的時(shí)候，一

位項(xiàng)目經(jīng)理開玩笑說，"方法論源自項(xiàng)目經(jīng)理的恐懼，這沒錯(cuò)。但最

糟糕的是整個(gè)團(tuán)隊(duì)只有項(xiàng)目經(jīng)理一個(gè)人恐懼，如果能夠做到人人的恐

懼，那大家也就沒有什么好恐懼的了。"這句話提醒了我們，如果一

個(gè)團(tuán)隊(duì)的精神就是力求成功，那么這支團(tuán)隊(duì)的心態(tài)就和其它的團(tuán)隊(duì)不

同了，尤其是對(duì)待錯(cuò)誤的心態(tài)上。根本就沒有必要花費(fèi)大量的精力來

預(yù)防錯(cuò)誤，錯(cuò)誤犯了就犯了，即時(shí)改正就可以了。這其實(shí)就是渴望成

功的心態(tài)。

方法論的藝術(shù)

管理，被稱為科學(xué)和藝術(shù)的融合體，而管理的藝術(shù)性部分很大程度的

體現(xiàn)為人的管理上。我說，方法學(xué)，一樣是科學(xué)和藝術(shù)的融合體。這

是有依據(jù)的，其實(shí)方法論和管理學(xué)是近親關(guān)系，管理學(xué)中有一門分支

是項(xiàng)目管理，而在軟件組織中，項(xiàng)目管理是非常重要的，方法學(xué)就是

一種針對(duì)軟件開發(fā)的一種特定的項(xiàng)目管理（或是項(xiàng)目管理的一個(gè)子

集）。

重型方法最大的一個(gè)問題就在于他不清楚或忽略了藝術(shù)這個(gè)層次，忽

視了人的因素，把人做為一個(gè)計(jì)量單位，一種資源，一種線性元素。

而人的要素在軟件開發(fā)中是非常重要的，軟件開發(fā)實(shí)際上是一種知

識(shí)、智力的轉(zhuǎn)移過程，最終形成的產(chǎn)品是一種知識(shí)產(chǎn)品，它的成本取

決于開發(fā)者的知識(shí)價(jià)值，因此，人是最重要的因素。而人這個(gè)要素是

很難衡量的，每個(gè)人都有不同的個(gè)性、想法、經(jīng)驗(yàn)、經(jīng)歷，這么多復(fù)

雜的因素加在一起，就導(dǎo)致了人的不可預(yù)見性。因此，我們強(qiáng)調(diào)管人

的藝術(shù)。

最簡(jiǎn)單的例子是，在重型方法中，我們的基本假設(shè)是對(duì)人的不信任。

項(xiàng)目經(jīng)理要控制項(xiàng)目。但不信任就會(huì)產(chǎn)生很多的問題，比如士氣不高,

計(jì)劃趕不上變化，創(chuàng)新能力低下，跳槽率升高等等。人都是希望被尊

重的，技術(shù)人員更看重這一點(diǎn)，而很多公司也口口聲聲說自己多么多

么以人為本，可是采用的卻是以不信任人為前提的開發(fā)方法，言行不

一。我們說敏捷方法的出發(fā)點(diǎn)是相互信任，做到這一點(diǎn)是很難的，但

是一旦做到了，那這個(gè)團(tuán)隊(duì)就是非常具有競(jìng)爭(zhēng)力的。因此，這就產(chǎn)生

了一個(gè)問題，在沒有做到完全的相互信任之前，我們到底相不相信他

人呢，這就是我提到的藝術(shù)性的問題，什么時(shí)候你要相信人？什么時(shí)

候你不相信人，這些都是需要權(quán)衡的問題，也都是表現(xiàn)你藝術(shù)性的問

題。

敏捷

敏捷代表著有效和靈活。我們稱那些輕型的、有效的方法為敏捷方法。

在重型方法中，我們?cè)谝恍┎槐匾?、重?fù)的中間環(huán)節(jié)上浪費(fèi)了太多的

精力，而敏捷則避免了這種浪費(fèi)。我們的文章將會(huì)重點(diǎn)的討論敏捷

(Agile)方法論的思想，敏捷這個(gè)名字的前身就是輕型。目前已經(jīng)

有了一個(gè)敏捷聯(lián)盟，他們制定了敏捷宣言：

Individualsandinteractionsoverprocessesandtools.

Workingsoftwareovercomprehensivedocumentation.

Customercollaborationovercontractnegotiation.

Respondingtochangeoverfollowingaplan.

而我對(duì)敏捷的理解包括了兒個(gè)方面:

較低的管理成本和高質(zhì)量的產(chǎn)出。軟件開發(fā)存在兩個(gè)極端：一個(gè)是沒

有任何的管理成本，所有的工作都是為了軟件的產(chǎn)出，但是這種方式

卻往往導(dǎo)致軟件開發(fā)過程的混沌，產(chǎn)品的低質(zhì)量，團(tuán)隊(duì)士氣的低落。

另一個(gè)是大量管理活動(dòng)的加入，評(píng)審、變更管理，缺陷跟蹤，雖然管

理活動(dòng)的加入能夠在一定程度上提高開發(fā)過程的有序性，但是成本卻

因此提高，更糟糕的是，很容易導(dǎo)致團(tuán)隊(duì)的低效率，降低創(chuàng)新能力。

因此，敏捷方法視圖尋找一個(gè)平衡點(diǎn)，用低成本的管理活動(dòng)帶來最大

的產(chǎn)出，即軟件的高質(zhì)量。

尊重人性。敏捷方法尊重人性，強(qiáng)調(diào)效率。軟件開發(fā)可以說是一種腦

力的投入，如果不能保證開發(fā)人員的自愿投入，產(chǎn)品就肯定要打折扣。

事實(shí)多次的證明，一個(gè)愿意投入的開發(fā)人員和一個(gè)不愿意投入的開發(fā)

人員效率相差在三倍以上，對(duì)組織的貢獻(xiàn)更是在十倍以上。

溝通和反饋是一切的基礎(chǔ)。我們已經(jīng)討論過溝通的重要程度，而即時(shí)

的反饋是擁抱變化的前提條件。

客戶是上帝。沒有客戶就沒有一切，客戶的重要性可以用一句話來形

容，就是以合理的成本建造合適的軟件(buildtherightsystematthe

rightcost)o

敏捷其實(shí)也有輕重之分，關(guān)鍵在于是否能夠做到有效和靈活。因此，

敏捷方法論提倡的一個(gè)思想是"剛好夠(barelysufficient)"o不過這

個(gè)"剛好夠"可不是那么容易判斷的。一支8個(gè)人的團(tuán)隊(duì)采用XP方法,

隨著方法的熟練使用，團(tuán)隊(duì)的能力在不斷的增強(qiáng)，能夠處理的問題越

越來越復(fù)雜，也許他們能夠處理采用重型方法的20個(gè)人團(tuán)隊(duì)能夠處

理的問題?？墒侨绻麍F(tuán)隊(duì)的人數(shù)突然增加到12人，這支團(tuán)隊(duì)肯定就

會(huì)出問題，他的表現(xiàn)可能還不如那支20個(gè)人的團(tuán)隊(duì)了。人數(shù)增加了

的時(shí)候，原先的方法肯定還做適當(dāng)?shù)恼{(diào)整，比如說，在原先的敏捷方

法上增加一些重型方法的技巧。我們不能夠要求一支6個(gè)人的團(tuán)隊(duì)和

一支20個(gè)人的團(tuán)隊(duì)用同樣的方法，前者可能采用輕一些的敏捷方法,

后者可能采用重一些的敏捷方法，關(guān)鍵的問題在于，兩支團(tuán)隊(duì)都把重

點(diǎn)放在溝通、反饋、頻繁交付軟件這些關(guān)鍵的因素上，也就是做到有

效和靈活。

架構(gòu)設(shè)計(jì)

架構(gòu)(Architecture)(也有被稱為體系結(jié)構(gòu)的)是軟件設(shè)計(jì)中非常重

要的一個(gè)環(huán)節(jié)。軟件開發(fā)的過程中只要需求和架構(gòu)確定之后，這個(gè)軟

件就基本上可以定型了。這就好比骨骼確定了，這個(gè)人的體形就不會(huì)

有很大的變化。因此我選擇了架構(gòu)設(shè)計(jì)來討論敏捷軟件開發(fā)(需求我

已經(jīng)寫過了)。我們?cè)谇懊嬗懻撨^超集和子集的概念，因此我們接下

去要討論的架構(gòu)設(shè)計(jì)也是一個(gè)很小的子集。方法論如果沒有經(jīng)歷過多

個(gè)項(xiàng)目的檢驗(yàn)是不能稱為成功的方法論的，我也并不認(rèn)為我的架構(gòu)設(shè)

計(jì)就是一個(gè)好的方法論，但引玉還需拋磚，他的主要目的是為了傳播

一種思想。因此，我采用了模式語言(PLOP)做為寫作架構(gòu)設(shè)計(jì)的

形式，主要的原因就是模式是一種很好的組織思想的方法。

因此，在我們接下去的歷程中，我們集中討論的東西就圍繞著架構(gòu)、

方法學(xué)、敏捷這三個(gè)要素展開。這篇文章并不是討論如何編碼實(shí)現(xiàn)軟

件架構(gòu)的，也不要單純的把它看作架構(gòu)設(shè)計(jì)的指南，其實(shí)文中的很多

思想來自于方法論，因此提到的很多架構(gòu)設(shè)計(jì)的思想也適用于其它工

作，如果能夠了解這一點(diǎn)，看這篇文章的收獲可能會(huì)更多一些。

2.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(2)-架構(gòu)設(shè)計(jì)的敏捷

視圖

通過上一章的介紹，我們對(duì)敏捷和方法有了一個(gè)大致的了解，從這一

章起，我們開始對(duì)軟件開發(fā)過程中架構(gòu)設(shè)計(jì)的研究。記住一點(diǎn)，我們

并不是為了架構(gòu)設(shè)計(jì)而研究架構(gòu)設(shè)計(jì)，我們的目的在于敏捷方法學(xué)的

應(yīng)用。

架構(gòu)設(shè)計(jì)是一種權(quán)衡(trade-off)。一個(gè)問題總是有多種的解決方案。

而我們要確定唯一的架構(gòu)設(shè)計(jì)的解決方案，就意味著我們要在不同的

矛盾體之間做出一個(gè)權(quán)衡。我們?cè)谠O(shè)計(jì)的過程總是可以看到很多的矛

盾體：開放和整合，一致性和特殊化，穩(wěn)定性和延展性等等。任何一

對(duì)矛盾體都源于我們對(duì)軟件的不同期望?？墒?，要滿足我們希望軟件

穩(wěn)定運(yùn)行的要求，就必然會(huì)影響我們對(duì)軟件易于擴(kuò)展的期望。我們希

望軟件簡(jiǎn)單明了，卻增加了我們?cè)O(shè)計(jì)的復(fù)雜度。沒有一個(gè)軟件能夠滿

足所有的要求，因?yàn)檫@些要求之間帶有天生的互斥性。而我們?cè)u(píng)價(jià)架

構(gòu)設(shè)計(jì)的好壞的依據(jù)，就只能是根據(jù)不同要求的輕重緩急，在其間做

出權(quán)衡的合理性。

目標(biāo)

我們希望一個(gè)好的架構(gòu)能夠：

重用：為了避免重復(fù)勞動(dòng)，為了降低成本，我們希望能夠重用之前的

代碼、之前的設(shè)計(jì)。重用是我們不斷追求的目標(biāo)之一，但事實(shí)上，做

到這一點(diǎn)可沒有那么容易。在現(xiàn)實(shí)中，人們已經(jīng)在架構(gòu)重用上做了很

多的工作，工作的成果稱為框架(Framework),比如說Windows的

窗口機(jī)制、J2EE平臺(tái)等。但是在企業(yè)商業(yè)建模方面，有效的框架還

非常的少。

透明：有些時(shí)候，我們?yōu)榱颂岣咝?，把?shí)現(xiàn)的細(xì)節(jié)隱藏起來，僅把

客戶需求的接口呈現(xiàn)給客戶。這樣，具體的實(shí)現(xiàn)對(duì)客戶來說就是透明

的。一個(gè)具體的例子是我們使用JSP的tag技術(shù)來代替JSP的嵌入代

碼，因?yàn)槲覀兊腍TML界面人員更熟悉tag的方式。

延展：我們對(duì)延展的渴求源于需求的易變。因此我們需要架構(gòu)具有一

定的延展性，以適應(yīng)未來可能的變化?？墒牵缟纤f，延展性和穩(wěn)

定性，延展性和簡(jiǎn)單性都是矛盾的。因此我們需要權(quán)衡我們的投入/

產(chǎn)出比。以設(shè)計(jì)出具有適當(dāng)和延展性的架構(gòu)。

簡(jiǎn)明：一個(gè)復(fù)雜的架構(gòu)不論是測(cè)試還是維護(hù)都是困難的。我們希望架

構(gòu)能夠在滿足目的的情況下盡可能的簡(jiǎn)單明了。但是簡(jiǎn)單明了的含義

究竟是什么好像并沒有一個(gè)明確的定義。使用模式能夠使設(shè)計(jì)變得簡(jiǎn)

單，但這是建立在我熟悉設(shè)計(jì)模式的基礎(chǔ)上。對(duì)于一個(gè)并不懂設(shè)計(jì)模

式的人，他會(huì)認(rèn)為這個(gè)架構(gòu)很復(fù)雜。對(duì)于這種情況，我只能對(duì)他說，

去看看設(shè)計(jì)模式。

高效：不論是什么系統(tǒng)，我們都希望架構(gòu)是高效的。這一點(diǎn)對(duì)于一些

特定的系統(tǒng)來說尤其重要。例如實(shí)時(shí)系統(tǒng)、高訪問量的網(wǎng)站。這些值

的是技術(shù)上的高效，有時(shí)候我們指的高效是效益上的高效。例如，一

個(gè)只有兒十到一百訪問量的信息系統(tǒng)，是不是有必要使用EJB技術(shù)，

這就需要我們綜合的評(píng)估效益了。

安全：安全并不是我們文章討論的重點(diǎn)，卻是架構(gòu)的一個(gè)很重要的方

面。

規(guī)則

為了達(dá)到上述的目的，我們通常需要對(duì)架構(gòu)設(shè)計(jì)制定一些簡(jiǎn)單的規(guī)

則：

功能分解

顧名思義，就是把功能分解開來。為什么呢？我們之所以很難達(dá)到重

用目標(biāo)就是因?yàn)槲覀兙帉懙某绦蚪?jīng)常處于一種好像是重復(fù)的功能，但

又有輕微差別的狀態(tài)中。我們很多時(shí)候就會(huì)經(jīng)不住誘惑，用拷貝粘貼

再做少量修改的方式完成一個(gè)功能。這種行為在XP中是堅(jiān)決不被允

許的。XP提倡"Onceandonlyonce",目的就是為了杜絕這種拷貝修

改的現(xiàn)象。為了做到這一點(diǎn)，我們通常要把功能分解到細(xì)粒度。很多

的設(shè)計(jì)思想都提倡小類，為的就是這個(gè)目的。

所以，我們的程序中的類和方法的數(shù)目就會(huì)大大增長(zhǎng)，而每個(gè)類和方

法的平均代碼卻會(huì)大大的下降?？墒牵覀?cè)趺粗肋@個(gè)度應(yīng)該要如

何把握呢，關(guān)于這個(gè)疑問，并沒有明確的答案，要看個(gè)人的功力和具

體的要求，但是一般來說，我們可以用一個(gè)簡(jiǎn)單的動(dòng)詞短語來命名類

或方法的，那就會(huì)是比較好的分類方法。

我們使用功能分解的規(guī)則，有助于提高重用性，因?yàn)槲覀兠總€(gè)類和方

法的精度都提高了。這是符合大自然的原則的，我們研究自然的主要

的一個(gè)方向就是將物質(zhì)分解。我們的思路同樣可以應(yīng)用在軟件開發(fā)

上。除了重用性，功能分解還能實(shí)現(xiàn)透明的目標(biāo)，因?yàn)槲覀兪褂昧斯?/p>

能分解的規(guī)則之后，每個(gè)類都有自己的單獨(dú)功能，這樣，我們對(duì)一個(gè)

類的研究就可以集中在這個(gè)類本身，而不用牽涉到過多的類。

根據(jù)實(shí)際情況決定不同類間的耦合度

雖然我們總是希望類間的耦合度比較低，但是我們必須客觀的評(píng)價(jià)耦

合度。系統(tǒng)之間不可能總是松耦合的，那樣肯定什么也做不了。而我

們決定耦合的程度的依據(jù)何在呢？簡(jiǎn)單的說，就是根據(jù)需求的穩(wěn)定

性，來決定耦合的程度。對(duì)于穩(wěn)定性高的需求，不容易發(fā)生變化的需

求，我們完全可以把各類設(shè)計(jì)成緊耦合的（我們雖然討論類之間的耦

合度，但其實(shí)功能塊、模塊、包之間的耦合度也是一樣的），因?yàn)檫@

樣可以提高效率，而且我們還可以使用一些更好的技術(shù)來提高效率或

簡(jiǎn)化代碼，例如Java中的內(nèi)部類技術(shù)。可是，如果需求極有可能變

化，我們就需要充分的考慮類之間的耦合問題，我們可以想出各種各

樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層次來

隔離不同的類，這個(gè)抽象層次可以是具體的類，也可以是接口，或是

一組的類（例如Beans）。我們可以借用Java中的一句話來概括降低

耦合度的思想：”針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程。”

設(shè)計(jì)不同的耦合度有利于實(shí)現(xiàn)透明和延展。對(duì)于類的客戶（調(diào)用者）

來說，他不需要知道過多的細(xì)節(jié)（實(shí)現(xiàn)），他只關(guān)心他感興趣的（接

口）。這樣，目標(biāo)類對(duì)客戶來說就是一個(gè)黑盒子。如果接口是穩(wěn)定的,

那么，實(shí)現(xiàn)再怎么擴(kuò)展，對(duì)客戶來說也不會(huì)有很大的影響。以前那種

牽一發(fā)而動(dòng)全身的問題完全可以緩解甚至避免。

其實(shí)，我們仔細(xì)的觀察GOF的23種設(shè)計(jì)模式，沒有一種模式的思路

不是從增加抽象層次入手來解決問題的。同樣，我們?nèi)ビ^察Java源

碼的時(shí)候，我們也可以發(fā)現(xiàn)，Java源碼中存在著大量的抽象層次，初

看之下，它們什么都不干，但是它們對(duì)系統(tǒng)的設(shè)計(jì)起著重大的作用。

夠用就好

我們?cè)谏弦徽轮芯驼勥^敏捷方法很看重剛好夠用的問題，現(xiàn)在我們結(jié)

合架構(gòu)設(shè)計(jì)來看：在同樣都能夠滿足需要的情況下，一項(xiàng)復(fù)雜的設(shè)計(jì)

和一項(xiàng)簡(jiǎn)單的設(shè)計(jì)，哪一個(gè)更好。從敏捷的觀點(diǎn)來看，一定是后者。

因?yàn)槟壳暗男枨笾挥?0項(xiàng)，而你的設(shè)計(jì)能夠滿足100項(xiàng)的需求，只

能說這是種浪費(fèi)。你在設(shè)計(jì)時(shí)完全沒有考慮成本問題，不考慮成本問

題，你就是對(duì)開發(fā)組織的不負(fù)責(zé)，對(duì)客戶的不負(fù)責(zé)。

應(yīng)用模式

這篇文章的寫作思路很多來源于對(duì)模式的研究。因此，文章中到處都

可以看到模式思想的影子。模式是一種整理、傳播思想的非常優(yōu)秀的

途徑，我們可以通過模式的方式學(xué)習(xí)他人的經(jīng)驗(yàn)。一個(gè)好的模式代表

了某個(gè)問題研究的成果，因此我們把模式應(yīng)用在架構(gòu)設(shè)計(jì)上，能夠大

大增強(qiáng)架構(gòu)的穩(wěn)定性。

抽象

架構(gòu)的本質(zhì)在于其抽象性。它包括兩個(gè)方面的抽象：業(yè)務(wù)抽象和技術(shù)

抽象。架構(gòu)是現(xiàn)實(shí)世界的一個(gè)模型，所以我們首先需要對(duì)現(xiàn)實(shí)世界有

一個(gè)很深的了解，然后我們還要能夠熟練的應(yīng)用技術(shù)來實(shí)現(xiàn)現(xiàn)實(shí)世界

到模型的映射。因此，我們?cè)趯?duì)業(yè)務(wù)或技術(shù)理解不夠深入的情況下，

就很難設(shè)計(jì)出好的架構(gòu)。當(dāng)然，這時(shí)候我們發(fā)現(xiàn)一個(gè)問題：怎樣才能

算是理解足夠深入呢。我認(rèn)為這沒有一個(gè)絕對(duì)的準(zhǔn)則。

一次，一位朋友問我：他現(xiàn)在做的系統(tǒng)有很大的變化，原先設(shè)計(jì)的工

作流架構(gòu)不能滿足現(xiàn)在的要求。他很希望能夠設(shè)計(jì)出足夠好的工作流

架構(gòu)，以適應(yīng)不同的變化。但是他發(fā)現(xiàn)這樣做無異于重新開發(fā)一個(gè)

lotusnotes。我聽了他的疑問之后覺得有兩點(diǎn)問題：

首先，他的開發(fā)團(tuán)隊(duì)中并沒有工作流領(lǐng)域的專家。他的客戶雖然了解

自己的工作流程，但是缺乏足夠的理論知識(shí)把工作流提到抽象的地

步。顯然，他本身雖然有技術(shù)方面的才能，但就工作流業(yè)務(wù)本身，他

也沒有足夠的經(jīng)驗(yàn)。所以，設(shè)計(jì)出象notes那樣的系統(tǒng)的前提條件并

不存在。

其次，開發(fā)一個(gè)工作流系統(tǒng)的目的是什么。原先的工作流系統(tǒng)運(yùn)作的

不好，其原因是有變化發(fā)生。因此才有改進(jìn)工作流系統(tǒng)的動(dòng)機(jī)出現(xiàn)。

可是，畢竟notes是為了滿足世界上所有的工作流系統(tǒng)而開發(fā)的，他

目前的應(yīng)用肯定達(dá)不到這個(gè)層次。

因此，雖然做不到最優(yōu)的業(yè)務(wù)抽象，但是我們完全可以在特定目的下，

特定范圍內(nèi)做到最優(yōu)的業(yè)務(wù)抽象。比如說，我們工作流可能的變化是

工組流路徑的變化。我們就完全可以把工作流的路徑做一個(gè)抽象，設(shè)

計(jì)一個(gè)可以動(dòng)態(tài)改變路徑的工作流架構(gòu)。

有些時(shí)候，我們雖然在技術(shù)上和業(yè)務(wù)上都有所欠缺，沒有辦法設(shè)計(jì)出

好的架構(gòu)。但是我們完全可以借鑒他人的經(jīng)驗(yàn)，看看類似的問題別人

是如何解決的。這就是我們前面提到的模式。我們不要把模式看成是

一個(gè)硬性的解決方法，它只是一種解決問題的思路。MartinFowler

曾說："模式和業(yè)務(wù)組件的區(qū)別就在于模式會(huì)引發(fā)你的思考。"

在《分析模式》一書中，MartinFowler提到了分析和設(shè)計(jì)的區(qū)別。分

析并不僅僅只是用用例列出所有的需求，分析還應(yīng)該深入到表面需求

的的背后，以得到關(guān)于問題本質(zhì)的MentalModel。然后，他引出了概

念模型的概念。概念模型就類似于我們?cè)谟懻摰某橄?。MartinFowler

提到了一個(gè)有趣的例子，如果要開發(fā)一套軟件來模擬桌球游戲，那么，

用用例來描述各種的需求，可能會(huì)導(dǎo)致大量的運(yùn)動(dòng)軌跡的出現(xiàn)。如果

你沒有了解表面現(xiàn)象之后隱藏的運(yùn)動(dòng)定律的本質(zhì)，你可能永遠(yuǎn)無法開

發(fā)出這樣一個(gè)系統(tǒng)。

關(guān)于架構(gòu)和抽象的問題，在后面的文章中有一個(gè)測(cè)量模式的案例可以

很形象的說明這個(gè)問題。

架構(gòu)的一些誤解

我們花了一些篇幅來介紹架構(gòu)的一些知識(shí)。現(xiàn)在回到我們的另一個(gè)主

題上來。對(duì)于一個(gè)敏捷開發(fā)過程，架構(gòu)意味著什么，我們?cè)撊绾蚊鎸?duì)

架構(gòu)。這里我們首先要澄清一些誤解：

誤解1:架構(gòu)設(shè)計(jì)需要很強(qiáng)的技術(shù)能力。從某種程度來說，這句話并

沒有很大的錯(cuò)誤。畢竟，你的能力越強(qiáng)，設(shè)計(jì)出優(yōu)秀架構(gòu)的兒率也會(huì)

上升。但是能力和架構(gòu)設(shè)計(jì)之間并沒有一個(gè)很強(qiáng)的聯(lián)系。即使是普通

的編程人員，他一樣有能力設(shè)計(jì)出能實(shí)現(xiàn)目標(biāo)的架構(gòu)。

誤解2：架構(gòu)由專門的設(shè)計(jì)師來設(shè)計(jì)，設(shè)計(jì)出的藍(lán)圖交由程序員來實(shí)

現(xiàn)。我們之所以會(huì)認(rèn)為架構(gòu)是設(shè)計(jì)師的工作，是因?yàn)槲覀兿矚g把軟件

開發(fā)和建筑工程做類比。但是，這兩者實(shí)際上是有著很大的區(qū)別的。

關(guān)鍵之處在于，建筑設(shè)計(jì)已經(jīng)有很長(zhǎng)的歷史，已經(jīng)發(fā)展出完善的理論,

可以通過某些理論（如力學(xué)原理）來驗(yàn)證設(shè)計(jì)藍(lán)圖?？墒?，對(duì)軟件開

發(fā)而言，驗(yàn)證架構(gòu)設(shè)計(jì)的正確性，只能夠通過寫代碼來驗(yàn)證。因此,

很多看似完美的架構(gòu)，往往在實(shí)現(xiàn)時(shí)會(huì)出現(xiàn)問題。

誤解3：在一開始就要設(shè)計(jì)出完善的架構(gòu)。這種方式是最傳統(tǒng)的前期

設(shè)計(jì)方式。這也是為XP所摒棄的一種設(shè)計(jì)方式。主要的原因是，在

一開始設(shè)計(jì)出完美的架構(gòu)根本就是在自欺欺人。因?yàn)檫@樣做的基本假

設(shè)就是需求的不變性。但需求是沒有不變的（關(guān)于需求的細(xì)節(jié)討論，

請(qǐng)參看拙作『需求的實(shí)踐』）。這樣做的壞處是，我們一開始就限制了

整個(gè)的軟件的形狀。而到實(shí)現(xiàn)時(shí)，我們雖然發(fā)現(xiàn)原來的設(shè)計(jì)有失誤之

處，但卻不愿意面對(duì)現(xiàn)實(shí)。這使得軟件畸形的生長(zhǎng)。原本一些簡(jiǎn)單的

問題，卻因?yàn)閯e扭的架構(gòu)，變得非常的復(fù)雜。這種例子我們經(jīng)?？梢?/p>

看到，例如為兼容前個(gè)版本而導(dǎo)致的軟件復(fù)雜性。而2000年問題，

TCP/IP網(wǎng)絡(luò)的安全性問題也從一個(gè)側(cè)面反映了這個(gè)問題的嚴(yán)重性。

誤解4：架構(gòu)藍(lán)圖交給程序員之后，架構(gòu)設(shè)計(jì)師的任務(wù)就完成了。和

誤解2一樣，我們借鑒了建筑工程的經(jīng)驗(yàn)。我們看到建筑設(shè)計(jì)師把設(shè)

計(jì)好的藍(lán)圖交給施工人員，施工人員就會(huì)按照?qǐng)D紙建造出和圖紙一模

一樣的大廈。于是，我們也企圖在軟件開發(fā)中使用這種模式。這是非

常要命的。軟件開發(fā)中缺乏一種通用的語言，能夠充分的消除設(shè)計(jì)師

和程序員的溝通隔閡。有人說，UML不可以嗎？UML的設(shè)計(jì)理念是

好的，可以減輕溝通障礙問題?？墒且胪耆鉀Q這個(gè)問題，UML

還做不到。首先，程序員都具有個(gè)性化的思維，他會(huì)以自己的思維方

式去理解設(shè)計(jì)，因?yàn)閺脑O(shè)計(jì)到實(shí)現(xiàn)并不是一項(xiàng)機(jī)械的勞動(dòng)，還是屬于

一項(xiàng)知識(shí)性的勞動(dòng)(這和施工人員的工作是不同的)。此外，對(duì)于程

序員來說，他還極有可能按照自己的想法對(duì)設(shè)計(jì)圖進(jìn)行一定的修改，

這是非常正常的一項(xiàng)舉動(dòng)。更糟的是，程序員往往都比較自負(fù)，他們

會(huì)潛意識(shí)的排斥那些未經(jīng)過自己認(rèn)同的設(shè)計(jì)。

架構(gòu)設(shè)計(jì)的過程模式

通常我們認(rèn)為模式都是用在軟件開發(fā)、架構(gòu)設(shè)計(jì)上的。其實(shí)，這只是

模式的一個(gè)方面。模式的定義告訴我們，模式描述了一個(gè)特定環(huán)境的

解決方法，這個(gè)特定環(huán)境往往重復(fù)出現(xiàn)，制定出一個(gè)較好的解決方法

有利于我們?cè)谖磥砟苡行У慕鉀Q類似的問題。其實(shí)，在管理學(xué)上，也

存在這種類似的這種思維。稱為結(jié)構(gòu)性問題的程序化解決方法。所以

呢，我們完全可以把模式的思想用在其它的方面，而目前最佳的運(yùn)用

就是過程模式和組織模式。在我們的文章中，我們僅限于討論過程模

式。

我們討論的過程僅限于面向?qū)ο蟮能浖_發(fā)過程。我們稱之為OOSP

(object-orientedsoftwareprocess)。因?yàn)槲覀兊倪^程需要面向?qū)ο筇?/p>

性的支持。當(dāng)然，我們的很多做法一樣可以用在非OO的開發(fā)過程中，

但是為了達(dá)到最佳的效果，我建議您使用OO技術(shù)。

那么，我們應(yīng)該如何避開這些誤區(qū)呢，或者，換句話說，敏捷軟件開

發(fā)是如何做架構(gòu)設(shè)計(jì)的。這里有兒種過程模式:

在接下去的篇幅中，我們會(huì)逐一對(duì)各種過程模式進(jìn)行介紹。然后再站

在全局的角度分析各個(gè)模式之間的關(guān)系，并將之歸納為架構(gòu)設(shè)計(jì)的模

式。

敏捷型架構(gòu)設(shè)計(jì)

我們說我們這里列出的過程模式是敏捷型的，關(guān)于這一點(diǎn)我們會(huì)在接

下去的各個(gè)章節(jié)中驗(yàn)證這一點(diǎn)。我們列出的各個(gè)過程模式并不是完全

照搬敏捷型方法，因?yàn)樵诟鞣N敏捷型方法中，某些技巧適合架構(gòu)設(shè)計(jì),

某些方法則不適合架構(gòu)設(shè)計(jì)。因此，我們?cè)诓捎靡环N方法和技術(shù)前，

我們會(huì)問自己幾個(gè)簡(jiǎn)單的問題：

該方法/技巧有什么價(jià)值？

該方法/技巧需要多大的投入？從創(chuàng)建、維護(hù)、培訓(xùn)等多方面估計(jì)。

比較該方法/技巧的投入和價(jià)值，它還值得我們采用嗎？

是否還有其它價(jià)值/投入比更高的方法/技巧呢？

在我們的文章中，每一種方法/技巧的討論都回答了前三個(gè)問題，至

于第四個(gè)問題，希望有同行能夠告訴我。

3.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(3)-源自需求

我們說，和重型方法偏重于計(jì)劃、過程和中間產(chǎn)物不同，敏捷方法更

加看重人和溝通。人和溝通永遠(yuǎn)是第一位的，而計(jì)劃、過程和中間產(chǎn)

物，那只是保證溝通、實(shí)現(xiàn)目標(biāo)的手段。這并不是說計(jì)劃、過程、中

間產(chǎn)物不重要，只是不能夠本末倒置

注：我們把中間產(chǎn)物定義為為了實(shí)現(xiàn)跨邊界的溝通而制定的文檔、模

型、代碼。例如設(shè)計(jì)文檔、數(shù)據(jù)模型等。參考RUP的Artifact。

評(píng)判軟件成功的標(biāo)準(zhǔn)有很多，對(duì)于敏捷方法論來說，成功的標(biāo)準(zhǔn)首先

在于交付可用的軟件。為了保證軟件的可用性，最重要的就是做好需

求。做好需求的方法有很多（參見拙作需求的實(shí)踐），但這并不是我

們討論的主題。對(duì)于我們要開始的架構(gòu)設(shè)計(jì)的工作來說，從需求出發(fā)

來設(shè)計(jì)架構(gòu)，這就是保證軟件可用性的一個(gè)基本的保證。

Context

我們?nèi)绾伍_始我們的架構(gòu)設(shè)計(jì)工作?

Problem

我們?cè)谶M(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，往往主要考慮的都是平臺(tái)、語言、開發(fā)

環(huán)境、數(shù)據(jù)庫(kù)等一些基本問題，可是對(duì)于和客戶的具體情況密切相關(guān)

的一些問題卻很少系統(tǒng)的考慮。甚至還存在一種誤區(qū)，認(rèn)為架構(gòu)設(shè)計(jì)

無非就是寫一些空話，套話。這樣子做出來架構(gòu)設(shè)計(jì)，如何用于指導(dǎo)

軟件的實(shí)現(xiàn)呢？

IT界的技術(shù)層出不窮，面對(duì)著如此之多的技術(shù)、平臺(tái)、框架、函數(shù)

庫(kù)，我們?nèi)绾芜x擇一組適合軟件的技術(shù)？

每一個(gè)客戶的軟件都有自身的特點(diǎn)，如何才能夠設(shè)計(jì)出符合客戶利益

的架構(gòu)？

軟件中往往都充斥著眾多的問題，在一開始就把所有的問題都想清楚

往往很難做到，但是如果不解決問題，風(fēng)險(xiǎn)又居高不下。

Solution

針對(duì)需求設(shè)計(jì)架構(gòu)。

例1：城市中自來水管的架設(shè)是一項(xiàng)非常的復(fù)雜的工程。為了需要滿足每家每戶

的需要,自來水管組成了一個(gè)龐大的網(wǎng)絡(luò)。在這樣一個(gè)復(fù)雜的網(wǎng)絡(luò)中,如何完成

鋪設(shè)的任務(wù)呢。一般的做法是,先找出問題的根源,也就是水的源頭。從水源鋪

設(shè)一條管道通至城市,然后根據(jù)城市的區(qū)域劃分,設(shè)計(jì)出主管道,剩下的就是使

用的問題了,每家每戶的管道最終都是連到主管道上的。因此,雖然自來水網(wǎng)絡(luò)

龐大復(fù)雜。但是真正的主管道的非常簡(jiǎn)單的。

架構(gòu)設(shè)計(jì)就是鋪設(shè)軟件的主管道（例1）。我們根據(jù)什么來制定主管

道的粗細(xì)、路徑等因素呢？很明顯，是根據(jù)城市的人口、地理位置、

水源等因素來決定的。對(duì)應(yīng)到軟件設(shè)計(jì)也是一樣的。城市的各因素就

是軟件中的各種需求：功能需求、非功能需求、變化案例等等。

一般來說，功能需求決定業(yè)務(wù)架構(gòu)、非功能需求決定技術(shù)架構(gòu)，變化

案例決定架構(gòu)的范圍。需求方面的知識(shí)告訴我們，功能需求定義了軟

件能夠做些什么。我們需要根據(jù)業(yè)務(wù)上的需求來設(shè)計(jì)業(yè)務(wù)架構(gòu)，以使

得未來的軟件能夠滿足客戶的需要。非功能需求定義了一些性能、效

率上的一些約束、規(guī)則。而我們的技術(shù)架構(gòu)要能夠滿足這些約束和規(guī)

則。變化案例是對(duì)未來可能發(fā)生的變化的一個(gè)估計(jì)，結(jié)合功能需求和

非功能需求，我們就可以確定一個(gè)需求的范圍，進(jìn)而確定一個(gè)架構(gòu)的

范圍。

例2：我們打算開發(fā)一個(gè)字處理軟件,功能需求可以簡(jiǎn)單概括為格式化用戶輸入

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

于10S,變化案例可能是推出多種語言版本。那么我們?cè)谠O(shè)計(jì)業(yè)務(wù)架構(gòu)的時(shí)候,

我們會(huì)集中于如何表示文字、圖象、媒體等要素,我們?cè)撔枰辛硗獾募夹g(shù)架構(gòu)

來處理速度問題,比如緩沖技術(shù),對(duì)于變化案例,我們也要考慮相應(yīng)的架構(gòu),比

如把字體獨(dú)立于程序包的設(shè)計(jì)。

從例2中，我們看到自已字處理軟件的兒種需求的范例。真正的字處

理軟件要復(fù)雜的多。而我們最主要的就是必須認(rèn)識(shí)到，架構(gòu)是來自于

需求的。有什么樣的需求就有什么樣的架構(gòu)。試想一下，如果我們沒

有對(duì)速度的要求，我們還需要考慮這方面的設(shè)計(jì)嗎？我們上面提到了

幾種類型的需求對(duì)架構(gòu)的影響，其實(shí)還有一個(gè)很重要的需求，就是環(huán)

境的需求。這并不是一個(gè)很重要的需求，但是對(duì)于部署（d印10yment）

架構(gòu)設(shè)計(jì)來說就特別重要。畢竟，我們開發(fā)出的軟件是要上"戰(zhàn)場(chǎng)”的,

充分的考慮部署問題是非常有必要的。

從需求到架構(gòu)。

在需求階段，我們可以得到一些代表需求調(diào)研成果的中間產(chǎn)物。比如

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

程圖、非功能需求、變化案例等。我們?cè)诩軜?gòu)設(shè)計(jì)階段的主要工作就

是要把這些需求階段的中間產(chǎn)物轉(zhuǎn)換為架構(gòu)設(shè)計(jì)階段的中間產(chǎn)物。

圖3.需求階段的中間產(chǎn)物

其實(shí)，架構(gòu)設(shè)計(jì)就是要完成兩項(xiàng)工作，一是分析，二是設(shè)計(jì)。分析是

分析需求，設(shè)計(jì)則是設(shè)計(jì)軟件的大致結(jié)構(gòu)。很多的方法論把分析和設(shè)

計(jì)兩種活動(dòng)分開來，但其實(shí)這兩者是很難區(qū)分的，做分析的時(shí)候會(huì)想

到如何設(shè)計(jì)，而思考如何設(shè)計(jì)反過來又會(huì)影響分析的效果?？梢哉f，

他們兩者之間是相互聯(lián)系和不斷迭代的。這種形態(tài)我們將會(huì)在后面的

迭代設(shè)計(jì)模式中詳細(xì)的討論。

在敏捷方法論中,需求最好是迭代進(jìn)行的,也就是說一點(diǎn)一點(diǎn)的作

需求。這種做法在那些需求變化快的項(xiàng)目中尤其適用。由于我們采用

的流程是一種迭代式的流程，這里我們將會(huì)面臨著如何對(duì)待上一次迭

代的中間產(chǎn)物的問題。如果我們每一次迭代都需要修改已存在的中間

產(chǎn)物，那么這種維護(hù)的成本未免過大。因此，敏捷方法論的基本做法

是，扔掉那些已經(jīng)沒有用處的中間產(chǎn)物。還記得在第一章的時(shí)候，我

們強(qiáng)調(diào)說軟件要比文檔重要。我們生成中間產(chǎn)物的目的都是為了生成

最終的程序，對(duì)于這些已經(jīng)完成作用的模型，沒有必要付出額外的維

護(hù)成本。

不要斷章取義的采用拋棄模型的做法。因?yàn)?，拋棄模型的做法需要?/p>

個(gè)適合環(huán)境的支持。后面會(huì)針對(duì)這個(gè)話題開展大范圍的討論。這里我

們簡(jiǎn)單的做一個(gè)了解：

簡(jiǎn)單化：簡(jiǎn)單的模型和簡(jiǎn)單的程序。模型和程序越復(fù)雜，就需要更多

的精力來處理它們。因此，我們盡可能的簡(jiǎn)化它們，為的是更容易的

處理它們。

高效的溝通渠道：通過增強(qiáng)溝通的效果來減少對(duì)中間產(chǎn)物的需要。試

想一下，如果我隨時(shí)能夠從客戶那里得到需求的細(xì)節(jié)資料，那前期的

需求調(diào)研就沒有必要做的太細(xì)致。

角色的交叉輪換：開發(fā)人員之間建立起交換角色的機(jī)制，這樣，能夠

盡量的避免各子系統(tǒng)諸侯割據(jù)的局面。

清晰的流程：或者我們可以稱之為明確的過程。過程在方法論中向來

都是一個(gè)重點(diǎn)，敏捷方法論也不例外。開發(fā)人員能夠清楚的知道，今

天做什么，明天做什么。過程不是給別人看的，而是給自己用的。

工具：好用的工具能夠節(jié)省大量的時(shí)間，這里的工具并不僅僅指

CASE工具，還包括了版本控制工具、自動(dòng)化測(cè)試工具、畫圖工具、

文檔制作和管理工具。使用工具要注意成本和效益的問題。

標(biāo)準(zhǔn)和風(fēng)格：語言不通是溝通的一個(gè)很大的障礙。語言從某個(gè)角度來

看屬于一種標(biāo)準(zhǔn)、一種風(fēng)格。因此，一個(gè)團(tuán)隊(duì)如果采用同樣的編碼標(biāo)

準(zhǔn)、文檔標(biāo)準(zhǔn)、注釋風(fēng)格、制圖風(fēng)格，那么這個(gè)團(tuán)隊(duì)的溝通效率一定

非常的高。

如果上述的環(huán)境你都不具備，或是欠缺好兒項(xiàng)，那你的文檔的模型還

是留著的好。

僅針對(duì)需求設(shè)計(jì)架構(gòu)

僅針對(duì)需求設(shè)計(jì)架構(gòu)的含義就是說不要做未來才有用的事情。有時(shí)

候，我們會(huì)把架構(gòu)考慮的非常復(fù)雜，主要的原因就是我們把很多未來

的因素放入到現(xiàn)在來考慮?；蛘?，我們?cè)陂_發(fā)第一個(gè)產(chǎn)品的時(shí)候就視

圖把它做成一個(gè)完美的框架。以上的這兩種思路有沒有錯(cuò)呢？沒有

錯(cuò)，這只是如何看待投入的問題，有人希望開始的時(shí)候多投入一些，

這樣后續(xù)的投入就會(huì)節(jié)省下來。但在現(xiàn)實(shí)中，由于需求的不確定性，

希望通過增加開始階段的投入來將降低未來的投入往往是難以做到

的，框架的設(shè)計(jì)也絕對(duì)不是能夠一蹴而就的，此這種做法并不是一個(gè)

好的做法。所以我們?cè)诤箢^會(huì)著重論述架構(gòu)設(shè)計(jì)的簡(jiǎn)單性和迭代過

程，也就是因?yàn)檫@個(gè)理由。

模式

模式將可以幫助我們抓住重點(diǎn)。設(shè)計(jì)模式在書的一開始（第二章）就

討論了一個(gè)設(shè)計(jì)一個(gè)文檔編輯器的問題。為了解決設(shè)計(jì)文檔編輯器引

出的七個(gè)問題，一共使用了8種不同的模式。這8種模式的組合其實(shí)

就是架構(gòu)，因?yàn)樗鼈兘鉀Q的，都是系統(tǒng)中最高層的問題。

在實(shí)踐中，人們發(fā)現(xiàn)架構(gòu)也是存在模式的。比如，對(duì)于系統(tǒng)結(jié)構(gòu)設(shè)計(jì),

我們使用層模式；對(duì)于分布式系統(tǒng)，我們使用代理模式；對(duì)于交互系

統(tǒng)，我們使用MVC（模型-視圖-控制器）模式。模式本來就是針對(duì)

特定問題的解，因此，針對(duì)需求的特點(diǎn)，我們也可以采用相應(yīng)的模式

來設(shè)計(jì)架構(gòu)。

在sun網(wǎng)站上提供的寵物商店的范例中，就把MVC模式的思想擴(kuò)展

成為架構(gòu)的思想，用于提供不同的界面視圖：

MVC架構(gòu)圖，這里提供原圖的概覽，查看其出處請(qǐng)點(diǎn)擊這里。

我們可以了解到在圖的背后隱藏著的需求：系統(tǒng)需要支持多種用戶界

面，包括為普通用戶提供的HTML界面，為無線用戶提供的WML

界面，為管理員提供的Swing界面，以及為B2B業(yè)務(wù)設(shè)計(jì)的

WebService界面。這是系統(tǒng)最重要的需求，因此，系統(tǒng)的設(shè)計(jì)者就需

要確定一個(gè)穩(wěn)定的架構(gòu)，以解決多界面的問題。相對(duì)于多界面的問題，

后端的業(yè)務(wù)處理邏輯都是一致的。比如HTML界面和WML界面的

功能并沒有太大的差別。把處理邏輯和界面分離開來還有額外的好

處，可以在添加功能的同時(shí)，不涉及界面的改動(dòng)，反之亦然。這就是

我們?cè)诘诙刑岬降鸟詈隙鹊膯栴}。

MVC模式正可以適用于解決該問題。系統(tǒng)使用控制器來為業(yè)務(wù)邏輯

選擇不同的界面，這就完成了MVC架構(gòu)的設(shè)計(jì)思路。在架構(gòu)設(shè)計(jì)的

工作中，我們手頭上有模式這樣一張好牌，有什么理由不去使用它

呢？

例3：信貸系統(tǒng)

在一個(gè)銀行的信貸帳務(wù)處理系統(tǒng)中,我們應(yīng)該如何把握最初的架構(gòu)思路呢?從需

求上來看,這個(gè)信貸帳務(wù)處理系統(tǒng)有幾個(gè)特點(diǎn):

它不是一個(gè)單獨(dú)的系統(tǒng),它需要和外部的其它系統(tǒng)交互,例如信貸業(yè)務(wù)系統(tǒng)、網(wǎng)

上銀行、數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)等。

在所有的需求中,最復(fù)雜的就是它的利息計(jì)算的需求,它要求能夠支持多種的利

息算法。

因此,我們的架構(gòu)設(shè)計(jì)首先是從系統(tǒng)的全局環(huán)境開始考慮。其它系統(tǒng)和該系統(tǒng)的

關(guān)系如何,應(yīng)該如何設(shè)計(jì)系統(tǒng)間的接口。通過需求的調(diào)研,系統(tǒng)的接口分為4

和企業(yè)外部系統(tǒng)的接口。信貸系統(tǒng)需要連接到人民銀行的系統(tǒng)。

和企業(yè)內(nèi)部系統(tǒng)的接口。信貸系統(tǒng)需要能夠?yàn)閿?shù)據(jù)倉(cāng)庫(kù)系統(tǒng)和網(wǎng)上銀行系統(tǒng)提供

數(shù)據(jù)。

和平級(jí)系統(tǒng)的接口。信貸系統(tǒng)需要從平級(jí)的帳戶、資金、財(cái)務(wù)系統(tǒng)中取數(shù)據(jù),并

向帳戶、押匯系統(tǒng)發(fā)送數(shù)據(jù)。

具體的實(shí)現(xiàn)策略并不在我們的討論范圍之內(nèi),但是可以看到,架構(gòu)策略的制定是

以需求為基礎(chǔ)的。我們可以把這部分的需求歸納為技術(shù)架構(gòu)或平臺(tái)架構(gòu)。

然后是利息算法的問題,我們經(jīng)過統(tǒng)計(jì),目前的利息計(jì)算方式有四種,可預(yù)見到

的還有兩種。在一開始的階段,我們并不需要考慮具體算法的實(shí)現(xiàn),但是我們需

要考慮算法的實(shí)現(xiàn)框架,因此我們很自然的想到Strategy模式可以勝任這一工作,

把不同的利息算法封裝起來。而我們的工作重點(diǎn)也就轉(zhuǎn)到定義利息算法的接口問

題。通過分析、比較多種利息算法,我們定義了一個(gè)最初始的算法接口,然后由

不同的利息算法來實(shí)現(xiàn)算法接口。雖然,這個(gè)接口目前還不是很完整,但是它會(huì)

在接下去的開發(fā)過程中慢慢的完善起來。這部分的需求屬于業(yè)務(wù)架構(gòu)的一部分。

考慮到系統(tǒng)的結(jié)構(gòu)非常的復(fù)雜,因此在系統(tǒng)結(jié)構(gòu)的處理上,我們采用了層模式做

為系統(tǒng)的基本結(jié)構(gòu)。此外,在每個(gè)層,我們還定義了幾個(gè)子模塊來處理特定的問

題。這樣,我們就可以將復(fù)雜的功能有序的組織起來。

經(jīng)過上述的分析,我們對(duì)系統(tǒng)的架構(gòu)有了一個(gè)簡(jiǎn)單的認(rèn)識(shí),但是還沒有結(jié)束,-

個(gè)架構(gòu)應(yīng)該包括系統(tǒng)的各個(gè)基本部分,因此,我們還要考慮票據(jù)處理、報(bào)表、帳

務(wù)處理等環(huán)節(jié),但是一開始就考慮周詳,這要花費(fèi)大量的時(shí)間,因此我們只是簡(jiǎn)

單的定義了一個(gè)原始的架構(gòu),然后在后續(xù)的開發(fā)過程中把這個(gè)架構(gòu)完善起來。

抓住重點(diǎn)

在架構(gòu)設(shè)計(jì)一開始，我們就說架構(gòu)是一種抽象，那就是說，架構(gòu)設(shè)計(jì)

摒棄了具體的細(xì)節(jié)，僅僅抓住軟件最高層的概念，也就是最上層、優(yōu)

先級(jí)最高、風(fēng)險(xiǎn)最大的那部分需求。

我們考慮、分析、解決一個(gè)問題，一定有一個(gè)漸進(jìn)的過程。架構(gòu)設(shè)計(jì)

就是解決問題其中比較早期的一個(gè)階段，我們不會(huì)在架構(gòu)設(shè)計(jì)這個(gè)階

段投入過多的時(shí)間（具體的原因在下文會(huì)有討論），因此關(guān)鍵點(diǎn)在于

我們要能夠在架構(gòu)設(shè)計(jì)中把握住需求的重點(diǎn)。比如，我們?cè)谀Ｊ揭还?jié)

中提到了分布式系統(tǒng)和交互系統(tǒng)，分布和交互就是這兩個(gè)系統(tǒng)的重

點(diǎn)。那么，如果說我們面對(duì)的是一個(gè)分布式的交互系統(tǒng)，那么，我們

就需要把這兩種特性做為重點(diǎn)來考慮，并以此為基礎(chǔ)，設(shè)計(jì)架構(gòu)。而

我們提到的寵物商店的范例也是類似的，除了MVC的架構(gòu)，還有很

多的設(shè)計(jì)問題需要解決，例如用于數(shù)據(jù)庫(kù)訪問的數(shù)據(jù)對(duì)象，用于視圖

管理的前端控制器，等等（具體使用到的架構(gòu)模式可以訪問sun的網(wǎng)

站）。但是這些相對(duì)于MVC模式來說，屬于局部的，優(yōu)先級(jí)較低的

部分，可以在架構(gòu)確定后再來設(shè)計(jì)。

架構(gòu)設(shè)計(jì)和領(lǐng)域?qū)＜?/p>

一個(gè)架構(gòu)要設(shè)計(jì)的好，和對(duì)需求的理解是分不開的。因此在現(xiàn)實(shí)中，

我們發(fā)現(xiàn)業(yè)務(wù)領(lǐng)域?qū)＜覒{借著他對(duì)業(yè)務(wù)領(lǐng)域的了解，能夠幫助開發(fā)人

員設(shè)計(jì)出優(yōu)秀的架構(gòu)來。架構(gòu)是需要抽象的，它是現(xiàn)實(shí)社會(huì)活動(dòng)的一

個(gè)基本模型，而業(yè)務(wù)領(lǐng)域的模型僅僅憑開發(fā)人員是很難設(shè)計(jì)出來的。

在ERP的發(fā)展史上，我們看到MRP發(fā)展為MRPIL在發(fā)展到閉環(huán)

MRP,直到發(fā)展成為現(xiàn)在的ERP,主要的因素是管理思想的演化，

也就是說，對(duì)業(yè)務(wù)領(lǐng)域的理解進(jìn)步了，架構(gòu)才有可能進(jìn)步。

因此，敏捷型架構(gòu)設(shè)計(jì)的過程中，我們也非常強(qiáng)調(diào)領(lǐng)域?qū)＜业淖饔谩?/p>

4.敏捷思維一架構(gòu)設(shè)計(jì)中的方法學(xué)(4)--團(tuán)隊(duì)設(shè)計(jì)

團(tuán)隊(duì)設(shè)計(jì)是敏捷方法論中很重要的一項(xiàng)實(shí)踐。我們這里說的團(tuán)隊(duì)，指

的并不是復(fù)數(shù)的人。一群人就是一群人，并沒有辦法構(gòu)成團(tuán)隊(duì)。要想

成為團(tuán)隊(duì)，有很多的工作要做。

我們之所以考慮以團(tuán)隊(duì)為單位來考慮架構(gòu)設(shè)計(jì)，是因?yàn)檐浖_發(fā)本身

就不是一件個(gè)人的事情，架構(gòu)設(shè)計(jì)更是如此。單個(gè)人的思維不免有考

慮欠妥之處，單個(gè)人的學(xué)識(shí)也不可能覆蓋所有的學(xué)科。而組織有效的

團(tuán)隊(duì)卻能夠彌補(bǔ)這些缺憾。

Context

誰來負(fù)責(zé)架構(gòu)的設(shè)計(jì)?

Problem

在我們的印象中，總認(rèn)為架構(gòu)設(shè)計(jì)是那些所謂架構(gòu)設(shè)計(jì)師的專屬工

作，他們往往擁有豐富的設(shè)計(jì)經(jīng)驗(yàn)和相關(guān)的技能，他們不用編寫代碼,

就能夠設(shè)計(jì)出理論上盡善盡美的架構(gòu)，配有精美的圖例。

問題1:理論上設(shè)計(jì)近乎完美的架構(gòu)缺乏程序的證明，在實(shí)際應(yīng)用中

往往會(huì)出這樣那樣的問題。

問題2：設(shè)計(jì)師設(shè)計(jì)架構(gòu)帶有很大的主觀性，往往會(huì)忽視客戶的需求,

導(dǎo)致架構(gòu)無法滿足需求。

問題3：實(shí)現(xiàn)的程序員對(duì)這種架構(gòu)有抵觸的情緒，或是因?yàn)椴焕斫饧?/p>

構(gòu)而導(dǎo)致架構(gòu)實(shí)現(xiàn)的失敗。

問題4：架構(gòu)師設(shè)計(jì)架構(gòu)主要是依據(jù)自己的大量經(jīng)驗(yàn)，設(shè)計(jì)出的架構(gòu)

不能真實(shí)的反映目前的軟件需要。

Solution

團(tuán)隊(duì)設(shè)計(jì)的理論依據(jù)是群體決策。和個(gè)人決策相比，群體決策的最大

好處就是其結(jié)論要更加的完整。而群體決策雖然有其優(yōu)點(diǎn)，但其缺點(diǎn)

也是很明顯的：需要額外付出溝通成本、決策效率低、責(zé)任不明確、

等等。但是群體決策如果能夠組織得當(dāng)?shù)脑挘悄軌蛟诩軜?gòu)設(shè)計(jì)中發(fā)

揮很大的優(yōu)勢(shì)的。

避免象牙塔式的架構(gòu)設(shè)計(jì)

對(duì)軟件來說，架構(gòu)設(shè)計(jì)是一項(xiàng)至關(guān)重要的工作。這樣的工作交給某個(gè)

人是非常危險(xiǎn)的。即便這個(gè)人再怎么聰明，他也可能會(huì)遺漏部分的細(xì)

節(jié)。組織有效的團(tuán)隊(duì)的力量是大大超過個(gè)人的力量的，因此團(tuán)隊(duì)的成

果較之個(gè)人的成果，在穩(wěn)定性和思考的周密程度上，都要更勝一籌。

ScottW.Ambler在其著作中給出了象牙塔式架構(gòu)(ivorytower

architecture)的概念：

Anivorytowerarchitectureisonethatisoftendevelopedbyanarchitect

orarchitecturalteaminrelativeisolationtotheday-to-daydevelopment

activitiesofyourprojectteam(s).

例1：在XP中,我們基本上看不到架構(gòu)設(shè)計(jì)的影子。并不是說采用XP技術(shù)的

團(tuán)隊(duì)就不需要架構(gòu)設(shè)計(jì)。XP不存在專門的設(shè)計(jì)時(shí)期,它提倡使用一些簡(jiǎn)單的圖

例、比喻的方式來表達(dá)軟件的架構(gòu),而這種的架構(gòu)設(shè)計(jì)是無時(shí)無刻不在進(jìn)行的。

其實(shí),XP中的設(shè)計(jì)采用的就是團(tuán)隊(duì)設(shè)計(jì)的方式,結(jié)隊(duì)編程(PairProgramming)

和代碼的集體所有制(CollectiveOwnership)是團(tuán)隊(duì)設(shè)計(jì)的基礎(chǔ),也就是基于口

述的溝通方式。通過采用這樣的方式,XP幾乎不需要文檔來表達(dá)架構(gòu)的設(shè)計(jì)。

中國(guó)現(xiàn)在的軟件開發(fā)行業(yè)中也逐漸出現(xiàn)了象牙塔式的架構(gòu)設(shè)計(jì)師。這

些架構(gòu)師并不參與實(shí)際的程序編寫，他的工作就是為項(xiàng)目制作出精美

的架構(gòu)模型，這種架構(gòu)模型在理論上是相當(dāng)完美的。

優(yōu)秀的架構(gòu)師能夠充分的利用現(xiàn)有框架，減少軟件的投入，增強(qiáng)軟件

的穩(wěn)定性。這些都沒有錯(cuò)，但是問題在于“過猶不及”。象牙塔式架

構(gòu)師往往會(huì)出現(xiàn)文章開始指出的那些問題。架構(gòu)設(shè)計(jì)其實(shí)并不是非常

復(fù)雜的工作，但它要求開發(fā)人員具備相關(guān)的技能、經(jīng)驗(yàn)以及對(duì)問題域

有一定的了解。開發(fā)人員往往都具有相關(guān)的技術(shù)技能（編程、數(shù)據(jù)庫(kù)

設(shè)計(jì)、建模），而對(duì)問題域的理解可以從用戶和行業(yè)專家那里獲得幫

助。因此，在理論上，我們要實(shí)現(xiàn)架構(gòu)設(shè)計(jì)的團(tuán)隊(duì)化是完全可能的。

在上面的象牙塔式架構(gòu)定義中，我們看到架構(gòu)師和日常的開發(fā)工作是

隔絕的。這樣的設(shè)計(jì)出的架構(gòu)有很大的局限性。在現(xiàn)實(shí)中，我們還會(huì)

發(fā)現(xiàn)另外一種角色，他來自于開發(fā)團(tuán)隊(duì)外部，為開發(fā)人員提供相關(guān)的

技術(shù)或業(yè)務(wù)的培訓(xùn)。這種角色稱為教練，在軟件開發(fā)中是非常重要的

角色，不能夠和象牙塔式架構(gòu)設(shè)計(jì)師之間畫等號(hào)。

選擇你的設(shè)計(jì)團(tuán)隊(duì)。

軟件的架構(gòu)在軟件的生命周期的全過程中都很重要，也就是說，軟件

開發(fā)團(tuán)隊(duì)中的所有人員都需要和架構(gòu)打交道。因此，最好的團(tuán)隊(duì)組織

方式是所有開發(fā)人員都參與架構(gòu)的設(shè)計(jì)，我們稱這種方式為全員參

與。全員參與的方式保證了所有開發(fā)人員都能夠?qū)軜?gòu)設(shè)計(jì)提出自己

的見解，綜合多方面的意見，在全體開發(fā)人員中達(dá)成一致。這種方式

尤其適合于一些小的團(tuán)隊(duì)。

還是會(huì)有很多的團(tuán)隊(duì)由于種種的原因不適合采用全員參與的方式。那

么，組織優(yōu)秀的開發(fā)人員組成設(shè)計(jì)組也是比較好的方式。一般，我們

選擇那些在項(xiàng)目中比較重要的，有較多開發(fā)經(jīng)驗(yàn)，或是理論扎實(shí)的那

些人來組成設(shè)計(jì)組。當(dāng)然，如果你考慮到為組織培養(yǎng)后續(xù)力量，你也

可以讓一些新手加入設(shè)計(jì)組，或是你覺得自己的開發(fā)力量不足，邀請(qǐng)

外部的咨詢力量介入，這完全取決于具體的情況。

設(shè)計(jì)組不同于我們之前提到的象牙塔式架構(gòu)設(shè)計(jì)師。設(shè)計(jì)組設(shè)計(jì)出來

的架構(gòu)只能稱為原始架構(gòu)，它是需要不斷的反饋和改進(jìn)的。因此，在

架構(gòu)實(shí)現(xiàn)中，設(shè)計(jì)組的成員將會(huì)分布到開發(fā)團(tuán)隊(duì)的各個(gè)領(lǐng)域，把架構(gòu)

的思想帶給所有開發(fā)人員，編寫代碼來檢驗(yàn)架構(gòu)，并獲得具體的反饋,

然后所有的成員再集中到設(shè)計(jì)組中討論架構(gòu)的演進(jìn)。

團(tuán)隊(duì)設(shè)計(jì)中存在的問題

在團(tuán)隊(duì)設(shè)計(jì)的過程，我們會(huì)遇到各種各樣的問題，首當(dāng)其沖的就是溝

通成本的問題。架構(gòu)設(shè)計(jì)時(shí)，需求尚未被充分理解，軟件的設(shè)計(jì)思路

還處于萌發(fā)的狀態(tài)。這樣的情況下，團(tuán)隊(duì)的每位成員對(duì)軟件都有獨(dú)特

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

樣，他們的觀點(diǎn)都代表了軟件的一部分或是一方面，但是沒有辦法代

表軟件的全部。

在敏捷方法論中，我們的每一個(gè)流程都是迅速進(jìn)行、不斷改進(jìn)的。架

構(gòu)設(shè)計(jì)也是一樣，我們不可能在一次架構(gòu)設(shè)計(jì)上花費(fèi)更多的時(shí)間。而

團(tuán)隊(duì)決策總是傾向于較長(zhǎng)的討論和權(quán)衡。

例2：敏捷方法非常注重的就是團(tuán)隊(duì)的溝通。溝通是一個(gè)很有意思的話題,講起

來會(huì)花費(fèi)大量的時(shí)間,我們這里只是針對(duì)架構(gòu)設(shè)計(jì)中可能存在的溝通問題做一個(gè)

簡(jiǎn)單的討論。我們這里假設(shè)一個(gè)討論情境,這個(gè)情境來源于真實(shí)的生活:

項(xiàng)目主管徐輝、設(shè)計(jì)師李浩、設(shè)計(jì)師羅亦明正在討論一個(gè)新的軟件架構(gòu)。

"李浩你認(rèn)為這個(gè)軟件數(shù)據(jù)庫(kù)連接部分應(yīng)該如何考慮?"徐輝問。

李浩想了想，"我覺得方案A不錯(cuò)…"”方案A肯定有問題!這個(gè)軟件和上一次的

又不同。"羅亦明打斷了李浩的發(fā)言。

"你懂什么!你到公司才多久,方案A是經(jīng)過很長(zhǎng)時(shí)間的證明的！"發(fā)言被打斷,

李浩有點(diǎn)惱火,羅亦明進(jìn)入公司沒有多久,但在一些事情上老是和他唱反調(diào)。

"我進(jìn)公司多久和方案A的錯(cuò)誤有什么關(guān)系！"

在這樣一種氛圍中,會(huì)議的結(jié)果可想而知。

例2中的問題在架構(gòu)設(shè)計(jì)中時(shí)有發(fā)生，純技術(shù)的討論很容易上升稱為

爭(zhēng)吵。這種情況幾乎沒有辦法完全避免。團(tuán)隊(duì)型的決策必然會(huì)發(fā)生觀

念的沖突?？刂埔欢ǔ潭葍?nèi)的觀念的沖突對(duì)團(tuán)隊(duì)的決策是有益，但是

如果超出了這個(gè)程度就意味著失控了，需要團(tuán)隊(duì)領(lǐng)導(dǎo)者的調(diào)節(jié)。而更

重要的，我們需要注意溝通的技巧：

團(tuán)隊(duì)溝通

團(tuán)隊(duì)進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候溝通是一個(gè)非常需要注意的問題，上述的情

境在軟件組織中是經(jīng)常發(fā)生的，因?yàn)榧夹g(shù)人員很自然認(rèn)為自己的技術(shù)

比別人的好，如果自己的技術(shù)受到質(zhì)疑，那怕對(duì)方是抱著討論的態(tài)度,

也無異于自身的權(quán)威受到了挑戰(zhàn)，面子是無論如何都需要捍衛(wèi)的。而

溝通如果帶上了這樣一層主觀色彩，那么溝通信息的受眾就會(huì)潛意識(shí)

的拒絕接受信息。相反，他會(huì)找出對(duì)方話語中的漏洞，準(zhǔn)備進(jìn)行反擊。

因此，我們要注意培養(yǎng)一種良好的溝通氛圍。

在實(shí)際的觀察中，我發(fā)現(xiàn)團(tuán)隊(duì)溝通中存在兩種角色，一種是建議者，

他們經(jīng)常能夠提出建議。一種是質(zhì)疑者，他們對(duì)建議提出否定性的看

法。這兩種角色是可能互換的，現(xiàn)在的建議者可能就是剛才的質(zhì)疑者。

質(zhì)疑者的發(fā)言是很能打擊建議者的積極性的，而在一個(gè)腦力激蕩的會(huì)

議中，最好是大家都能夠扮演建議者的角色，這就要求溝通會(huì)議的主

持者能夠掌握好這一點(diǎn)，對(duì)建議給予肯定的評(píng)價(jià)，并鼓勵(lì)大家提出新

的建議。

良好的溝通有助于架構(gòu)設(shè)計(jì)工作的開展。一個(gè)成員的能力平平的團(tuán)

隊(duì)，可以藉由良好的溝通，設(shè)計(jì)出優(yōu)秀的架構(gòu)，而一個(gè)擁有一個(gè)優(yōu)秀

成員的團(tuán)隊(duì)，如果缺乏溝通，最后可能連設(shè)計(jì)都出不來。這種例子現(xiàn)

實(shí)中可以找到很多。

標(biāo)準(zhǔn)和風(fēng)格

我們總是在不知不覺之中使用各種各樣的標(biāo)準(zhǔn)和風(fēng)格。在團(tuán)隊(duì)設(shè)計(jì)

中，我們?yōu)榱颂岣邲Q策的效率，可以考慮使用統(tǒng)一的標(biāo)準(zhǔn)和風(fēng)格。統(tǒng)

一的標(biāo)準(zhǔn)和風(fēng)格并不是一朝一夕形成的。因?yàn)槊總€(gè)人都有自己不同的

習(xí)慣和經(jīng)歷，強(qiáng)制性的要求開發(fā)人員使用統(tǒng)一的標(biāo)準(zhǔn)（風(fēng)格）容易引

起開發(fā)人員的不滿。因此在操作上需要注意技巧。對(duì)架構(gòu)設(shè)計(jì)而言，

比較重要的標(biāo)準(zhǔn)（風(fēng)格）包括以下的這些類別：

界面設(shè)計(jì)

流程設(shè)計(jì)

建模規(guī)范

編碼規(guī)范

持久層設(shè)計(jì)

測(cè)試數(shù)據(jù)

在我的經(jīng)驗(yàn)中，有一些組織平時(shí)并不注意標(biāo)準(zhǔn)（風(fēng)格）的積累，認(rèn)為

這種積累屬于雕蟲小技，但正是這些小技，能夠非常有效的提高溝通

的效率和降低開發(fā)人員的學(xué)習(xí)曲線。試想一下，如果一個(gè)團(tuán)隊(duì)中所有

人寫出的代碼都是不同標(biāo)準(zhǔn)和風(fēng)格的，那么理解起來肯定會(huì)困難許

多。當(dāng)然，我們沒有必要自己開發(fā)一套標(biāo)準(zhǔn)（風(fēng)格）出來，現(xiàn)實(shí)中有

很多可以直接借用的資料。最好的標(biāo)準(zhǔn)是UML語言，我們可以從

UML的官方網(wǎng)站下載到最新的規(guī)范，常用的編碼標(biāo)準(zhǔn)更是隨處可見。

不過雖然有了統(tǒng)一的標(biāo)準(zhǔn)，如果風(fēng)格不統(tǒng)一，同樣會(huì)造成溝通的障礙。

例如下圖顯示的類圖，雖然它們表示的是同一個(gè)類，但是由于版型、

可視性、詳細(xì)程度的差別，看起來又很大的差別。而在其它的標(biāo)準(zhǔn)中,

這種差別也是普遍存在的。因此，我們?cè)谑褂昧私y(tǒng)一的標(biāo)準(zhǔn)之后，還

應(yīng)該使用同樣的風(fēng)格。ScottW.Ambler專門成立了一個(gè)網(wǎng)站討論UML

的建模風(fēng)格的相關(guān)問題，有興趣的讀者可以做額外的閱讀。

圖4.兩種風(fēng)格的類圖

<<businessentity//

Interest

(fromLogicalView)

Interest?RvalueDate：Date

valueDate?>dueDate：Date

dueDate^hbalance：Decimal

balance

?getBalHc

eDeciinal

getBalanceO?get1tM

?eein

set1tMI

在統(tǒng)一的風(fēng)格的基礎(chǔ)上更進(jìn)一步的是使用術(shù)語。使用溝通雙方都了解

專門的術(shù)語，可以代表大量的信息。最好的術(shù)語的范例就是設(shè)計(jì)模式

的模式名。如果溝通的雙方都了解設(shè)計(jì)模式，那么一方只需要說這部

分的設(shè)計(jì)可以使用工廠模式，另一方就能夠理解，而不用再詳細(xì)的解

釋設(shè)計(jì)的思路。這種的溝通方式是最高效的，但它所需要的學(xué)習(xí)曲線

也會(huì)比較陡。

團(tuán)隊(duì)設(shè)計(jì)的四明確

為了最大程度的提高團(tuán)隊(duì)設(shè)計(jì)的高效性，可以從4個(gè)方面來考慮:

1、明確目標(biāo)

泛泛的召開架構(gòu)討論會(huì)議是沒有什么意義的，一個(gè)沒有鮮明主題的會(huì)

議也不會(huì)有什么結(jié)果。在源自需求的模式中，我們談到說可以有非功

能需求的架構(gòu)，可以有功能需求的架構(gòu)。因此，在進(jìn)行團(tuán)隊(duì)設(shè)計(jì)之前,

我們首先也需要確定，此次要解決什么問題，是討論業(yè)務(wù)邏輯的架構(gòu),

還是技術(shù)架構(gòu)；是全局性的架構(gòu)，還是各模塊的架構(gòu)。

2、明確分工

我們之所以重視團(tuán)隊(duì)，很重要的額一個(gè)原因就是不同的成員有不同的

擅長(zhǎng)的區(qū)域。有些成員可能擅長(zhǎng)于業(yè)務(wù)邏輯的建模，有的擅長(zhǎng)于原型

設(shè)計(jì)，有的擅長(zhǎng)于數(shù)據(jù)庫(kù)設(shè)計(jì)，有的則擅長(zhǎng)于Web編程。你能夠想

象一個(gè)軟件沒有界面嗎？（有些軟件可能是這種情況）你能夠想象一

個(gè)軟件只有數(shù)據(jù)庫(kù)，而沒有處理邏輯嗎？因此，架構(gòu)設(shè)計(jì)就需要綜合

的考慮各個(gè)方面，充分利用成員的優(yōu)勢(shì)。這就要求團(tuán)隊(duì)的各個(gè)成員都

能夠明確自己的分工。

3、明確責(zé)權(quán)

除了明確自己的分工，每位成員都需要清楚自己的責(zé)任。沒有責(zé)任,

分工就不會(huì)有任何的效力。每位成員都需要明確自己要做些什么。當(dāng)

然，和責(zé)任相對(duì)的，沒有成員還