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

1、Evaluation Warning: The document was created with Spire.Doc for .NET.敏捷思維架構(gòu)設(shè)計(jì)中的方法學(xué)(1)方法論對(duì)軟軟件開(kāi)發(fā)發(fā)而言意意味著什什么？我我們?nèi)绾魏慰创涇浖_(kāi)發(fā)發(fā)中的方方法論？方法論論能夠成成為軟件件開(kāi)發(fā)的的救命稻稻草嗎？在讀過(guò)過(guò)此文后后，這些些疑惑就就會(huì)得到到解答。在第一篇文章中，我們來(lái)了解標(biāo)題中的一些詞的含義。 方法學(xué)是什么？ 敏捷是什么？ 為什么討論架構(gòu)？方法論方法論的英文為Methodology，詞典中的解釋為A series of related methods or techniques我們可以把它定義為軟

2、件開(kāi)發(fā)（針對(duì)軟件開(kāi)發(fā)）的一整套方法、過(guò)程、規(guī)則、實(shí)踐、技術(shù)。關(guān)于方法論的出現(xiàn)的問(wèn)題，我很贊同Alistair Cockburn的一句話，方法論源于恐懼。出于對(duì)項(xiàng)目的超期、成本失控等等因素的恐懼，項(xiàng)目經(jīng)理們從以前的經(jīng)驗(yàn)出發(fā)，制定出了一些控制、監(jiān)測(cè)項(xiàng)目的方法、技巧。這就是方法論產(chǎn)生的原因。在Agile Software Development一書(shū)中，作者提到了方法論的十三個(gè)要素，基本能夠函蓋方法論的各個(gè)方面：角色（Roles） 個(gè)性（Personality） 技能（Skills） 團(tuán)隊(duì)（Teams） 技術(shù)（Techniques） 活動(dòng)（Activities） 過(guò)程（Process） 工件（Work

3、 products） 里程碑（Milestones） 標(biāo)準(zhǔn)（Standards） 質(zhì)量（Quality） 工具（Tools） 團(tuán)隊(duì)價(jià)值（Team Values）它們之間的關(guān)系可以用一幅圖來(lái)表示：圖 1. 方法論的十三個(gè)要素很多的方法論，都涉及了上面列舉的十三要素中的部分要素，因此，我們可以把方法論看作是一個(gè)抽象的、無(wú)窮的超集，而現(xiàn)實(shí)中的方法論都是指超集的一個(gè)有限的子集而已。它們之間的關(guān)系就好像有理數(shù)和1到100之間的整數(shù)的關(guān)系一樣。不論是XP，還是UI設(shè)計(jì)經(jīng)驗(yàn)之類，都屬于方法論的一個(gè)子集，只是這兩個(gè)子集之間有大小的差別而已。我們還應(yīng)該看到，討論一個(gè)完備的方法論是沒(méi)有意義的，因此這種方法論鐵定不

4、存在，就好像你視圖窮舉出所有的有理數(shù)一樣荒唐。因此，我們關(guān)于一個(gè)通用的方法論的說(shuō)法也是無(wú)意義的。好的方法論，比如說(shuō)XP、水晶系列，它們都有一個(gè)適合的范圍，因?yàn)樗鼈兞私庖稽c(diǎn)，自己并不是一個(gè)無(wú)所不能的方法論。 在現(xiàn)實(shí)中，我們其實(shí)不斷的在接觸方法論。比如說(shuō)，為了控制項(xiàng)目的進(jìn)度，項(xiàng)目經(jīng)理要求所有的開(kāi)發(fā)人員每周遞交一份詳細(xì)的進(jìn)度報(bào)告，這就是一種方法、一種技巧。如果把開(kāi)發(fā)過(guò)程中的這些技巧系統(tǒng)的組織起來(lái)，就能夠成為一種方法論。你可能會(huì)說(shuō)，那一種方法論的產(chǎn)生也太容易了吧。不，這樣產(chǎn)生的方法論并沒(méi)有太大的實(shí)用價(jià)值，沒(méi)有實(shí)用價(jià)值的方法論根本就沒(méi)有存在的必要。因此，一個(gè)成功的方法論是要能夠?yàn)槎鄠€(gè)的項(xiàng)目所接受，并且能

5、夠成功實(shí)現(xiàn)軟件的交付的方法論。我和我的同事在實(shí)踐中做了一些試驗(yàn)，希望能夠把一些好的方法論應(yīng)用于開(kāi)發(fā)團(tuán)隊(duì)。試驗(yàn)的結(jié)果很無(wú)奈，方法論實(shí)施的效果并不理想，一開(kāi)始我們認(rèn)為是方法本身的原因，到后來(lái)，我們發(fā)現(xiàn)事情并不是這么簡(jiǎn)單。在試驗(yàn)的過(guò)程中，開(kāi)發(fā)人員一致認(rèn)同方法論的優(yōu)勢(shì)所在，但是在實(shí)施過(guò)程中，鮮有堅(jiān)持的下來(lái)的。在Agile Software Development中，我發(fā)現(xiàn)作者遇到了和我們一樣的問(wèn)題。Alistair Cockburn在和大量的項(xiàng)目團(tuán)隊(duì)的訪談之后，寫(xiě)成了Agile Software Development一書(shū)。在訪談之前，他篤定自己將會(huì)發(fā)現(xiàn)高度精確的過(guò)程控制是成功的關(guān)鍵所在，結(jié)果他發(fā)現(xiàn)事

6、實(shí)并非如此，他把他的發(fā)現(xiàn)歸結(jié)為7條定律。而我在實(shí)際中的發(fā)現(xiàn)也包含在這七條定律中，總結(jié)起來(lái)就只有兩點(diǎn)：溝通和反饋。只要能夠保證良好的溝通和即時(shí)的反饋，那么開(kāi)發(fā)團(tuán)隊(duì)即使并沒(méi)有采用先進(jìn)的方法論，一樣可以成功。相反，那些高質(zhì)量的團(tuán)隊(duì)卻往往由于缺乏這兩個(gè)因素而導(dǎo)致失?。ㄎ覀冞@里指的失敗是用戶拒絕使用最終的軟件）。最有效，而成本也最低的溝通方法就是面對(duì)面（face to face）的溝通，而隨著項(xiàng)目團(tuán)隊(duì)的變大，或是另外一些影響因素的加入（比如地理位置的隔絕），面對(duì)面的溝通越來(lái)越難實(shí)現(xiàn)，這導(dǎo)致溝通的的成本逐漸加大，質(zhì)量也慢慢下降。但這并不是說(shuō)非面對(duì)面的溝通不可，重要的是我們需要知道不同的溝通方式的成本和質(zhì)量

7、并不相同。XP方法尤為強(qiáng)調(diào)面對(duì)面的溝通，通過(guò)現(xiàn)場(chǎng)客戶、站立會(huì)議、結(jié)對(duì)編程等方式來(lái)保證溝通的有效。在我的經(jīng)驗(yàn)中，一個(gè)開(kāi)發(fā)團(tuán)隊(duì)其實(shí)是需要多種溝通方式的結(jié)合的。完全的面對(duì)面的溝通對(duì)某些團(tuán)隊(duì)來(lái)說(shuō)是很難實(shí)現(xiàn)的，那么問(wèn)題的關(guān)鍵就在于你如何應(yīng)用溝通的方式來(lái)達(dá)到你希望的效果。在前不久結(jié)束的歐萊雅創(chuàng)業(yè)計(jì)劃大賽上，有一支團(tuán)隊(duì)特別引人注目，他們彼此間素未謀面，僅僅憑借Internet和電話完成了高效的合作。他們雖然沒(méi)有使用面對(duì)面的溝通方式，但是仍然達(dá)成了既定的目標(biāo)。軟件開(kāi)發(fā)也是一樣的，面對(duì)面的溝通是非常有必要的，但其它的溝通方式也是需要的。再看反饋，不論是控制進(jìn)度，還是保證客戶的滿意度，這些活動(dòng)都需要管理成本。軟件

8、開(kāi)發(fā)中的管理成本的一個(gè)通性就是伴隨有中間產(chǎn)出物（intermediate delivery）。比如說(shuō)我們的需求規(guī)約、分析文檔、設(shè)計(jì)文檔、測(cè)試計(jì)劃，這些都屬于中間產(chǎn)出物。中間產(chǎn)出物的增加將會(huì)帶來(lái)效率下降的問(wèn)題，因?yàn)殚_(kāi)發(fā)人員的時(shí)間都花在了完成中間產(chǎn)出物的工作上，花在給軟件新功能上的時(shí)間就減少了。而中間產(chǎn)出物的主要目的是兩個(gè)，一個(gè)是為了保證軟件如客戶所愿，例如需求規(guī)約；另一個(gè)是為了作為團(tuán)隊(duì)中的其他成員工作的輸入，例如開(kāi)發(fā)計(jì)劃、測(cè)試計(jì)劃等。因此，我們也可以針對(duì)這兩點(diǎn)來(lái)商討對(duì)策，一種是采用迭代的思想，提高軟件發(fā)布的頻率，以保證客戶的需求被確實(shí)的滿足，另一種就是縮小團(tuán)隊(duì)的溝通范圍，保證成員能夠從其他人那里

9、得到新的思路，而不是撰寫(xiě)規(guī)范的內(nèi)部文檔（內(nèi)部文檔指那些僅為內(nèi)部開(kāi)發(fā)人員之間的溝通所需要的文檔）。因此，一個(gè)軟件項(xiàng)目的成功和你采用的開(kāi)發(fā)方法論并沒(méi)有直接的關(guān)系。重量我們根據(jù)把擁有大量artifact（RUP官方翻譯為工件，意思是軟件開(kāi)發(fā)過(guò)程中的中間產(chǎn)物，如需求規(guī)約、設(shè)計(jì)模型等）和復(fù)雜控制的軟件開(kāi)發(fā)方法稱為重型（Heavy Weight）方法，相對(duì)的，我們稱artifact較少的方法為輕型（Light Weight）方法。在傳統(tǒng)的觀念中，我們認(rèn)為重型方法要比輕型安全許多。因?yàn)槲覀冎韵氤鲋匦头椒?，就是由于在中大型的?xiàng)目中，項(xiàng)目經(jīng)理往往遠(yuǎn)離代碼，他無(wú)法有效的了解目前的工程的進(jìn)度、質(zhì)量、成本等因素。

10、為了克服未知的恐懼感，項(xiàng)目經(jīng)理制定了大量的中間管理方法，希望能夠控制整個(gè)項(xiàng)目，最典型的莫過(guò)于要求開(kāi)發(fā)人員頻繁的遞交各種表示項(xiàng)目目前狀態(tài)的報(bào)告。在Planning XP一書(shū)中有一段討論輕重型方法論的精辟論述，它把重型方法論歸結(jié)為一種防御性的姿態(tài)（defensive posture），而把輕型方法論歸結(jié)為一種渴望成功（Plan to win）的心態(tài)。如果你是采用了防御性姿態(tài)，那么你的工作就集中在防止和跟蹤錯(cuò)誤上，大量的工作流程的制定，是為了保證項(xiàng)目不犯錯(cuò)誤，而不是項(xiàng)目成功。而這種方法也不可謂不好，但前提是如果整個(gè)團(tuán)隊(duì)能夠滿足前面所提到的兩個(gè)條件的話，項(xiàng)目也肯定會(huì)成功，但是重型方法論的一個(gè)弊端就在于

11、，大家都在防止錯(cuò)誤，都在懼怕錯(cuò)誤，因此人和人之間的關(guān)系是很微妙的，要達(dá)到充分的溝通也是很難的。最終，連對(duì)人的評(píng)價(jià)也變成是以避免錯(cuò)誤的多寡作為考評(píng)的依據(jù)，而不是成就。我們?cè)谧鲈囼?yàn)的時(shí)候，一位項(xiàng)目經(jīng)理開(kāi)玩笑說(shuō)，方法論源自項(xiàng)目經(jīng)理的恐懼，這沒(méi)錯(cuò)。但最糟糕的是整個(gè)團(tuán)隊(duì)只有項(xiàng)目經(jīng)理一個(gè)人恐懼，如果能夠做到人人的恐懼，那大家也就沒(méi)有什么好恐懼的了。這句話提醒了我們，如果一個(gè)團(tuán)隊(duì)的精神就是力求成功，那么這支團(tuán)隊(duì)的心態(tài)就和其它的團(tuán)隊(duì)不同了，尤其是對(duì)待錯(cuò)誤的心態(tài)上。根本就沒(méi)有必要花費(fèi)大量的精力來(lái)預(yù)防錯(cuò)誤，錯(cuò)誤犯了就犯了，即時(shí)改正就可以了。這其實(shí)就是渴望成功的心態(tài)。方法論的藝術(shù)管理，被稱為科學(xué)和藝術(shù)的融合體，而管

12、理的藝術(shù)性部分很大程度的體現(xiàn)為人的管理上。我說(shuō)，方法學(xué)，一樣是科學(xué)和藝術(shù)的融合體。這是有依據(jù)的，其實(shí)方法論和管理學(xué)是近親關(guān)系，管理學(xué)中有一門(mén)分支是項(xiàng)目管理，而在軟件組織中，項(xiàng)目管理是非常重要的，方法學(xué)就是一種針對(duì)軟件開(kāi)發(fā)的一種特定的項(xiàng)目管理（或是項(xiàng)目管理的一個(gè)子集）。重型方法最大的一個(gè)問(wèn)題就在于他不清楚或忽略了藝術(shù)這個(gè)層次，忽視了人的因素，把人做為一個(gè)計(jì)量單位，一種資源，一種線性元素。而人的要素在軟件開(kāi)發(fā)中是非常重要的，軟件開(kāi)發(fā)實(shí)際上是一種知識(shí)、智力的轉(zhuǎn)移過(guò)程，最終形成的產(chǎn)品是一種知識(shí)產(chǎn)品，它的成本取決于開(kāi)發(fā)者的知識(shí)價(jià)值，因此，人是最重要的因素。而人這個(gè)要素是很難衡量的，每個(gè)人都有不同的個(gè)性、

13、想法、經(jīng)驗(yàn)、經(jīng)歷，這么多復(fù)雜的因素加在一起，就導(dǎo)致了人的不可預(yù)見(jiàn)性。因此，我們強(qiáng)調(diào)管人的藝術(shù)。最簡(jiǎn)單的例子是，在重型方法中，我們的基本假設(shè)是對(duì)人的不信任。項(xiàng)目經(jīng)理要控制項(xiàng)目。但不信任就會(huì)產(chǎn)生很多的問(wèn)題，比如士氣不高，計(jì)劃趕不上變化，創(chuàng)新能力低下，跳槽率升高等等。人都是希望被尊重的，技術(shù)人員更看重這一點(diǎn)，而很多公司也口口聲聲說(shuō)自己多么多么以人為本，可是采用的卻是以不信任人為前提的開(kāi)發(fā)方法，言行不一。我們說(shuō)敏捷方法的出發(fā)點(diǎn)是相互信任，做到這一點(diǎn)是很難的，但是一旦做到了，那這個(gè)團(tuán)隊(duì)就是非常具有競(jìng)爭(zhēng)力的。因此，這就產(chǎn)生了一個(gè)問(wèn)題，在沒(méi)有做到完全的相互信任之前，我們到底相不相信他人呢，這就是我提到的藝術(shù)

14、性的問(wèn)題，什么時(shí)候你要相信人？什么時(shí)候你不相信人，這些都是需要權(quán)衡的問(wèn)題，也都是表現(xiàn)你藝術(shù)性的問(wèn)題。敏捷敏捷代表著有效和靈活。我們稱那些輕型的、有效的方法為敏捷方法。在重型方法中，我們?cè)谝恍┎槐匾?、重?fù)的中間環(huán)節(jié)上浪費(fèi)了太多的精力，而敏捷則避免了這種浪費(fèi)。我們的文章將會(huì)重點(diǎn)的討論敏捷（Agile）方法論的思想，敏捷這個(gè)名字的前身就是輕型。目前已經(jīng)有了一個(gè)敏捷聯(lián)盟，他們制定了敏捷宣言：Individuals and interactions over processes and tools. Working software over comprehensive documentation. C

15、ustomer collaboration over contract negotiation. Responding to change over following a plan.而我對(duì)敏捷的理解包括了幾個(gè)方面：較低的管理成本和高質(zhì)量的產(chǎn)出。軟件開(kāi)發(fā)存在兩個(gè)極端：一個(gè)是沒(méi)有任何的管理成本，所有的工作都是為了軟件的產(chǎn)出，但是這種方式卻往往導(dǎo)致軟件開(kāi)發(fā)過(guò)程的混沌，產(chǎn)品的低質(zhì)量，團(tuán)隊(duì)士氣的低落。另一個(gè)是大量管理活動(dòng)的加入，評(píng)審、變更管理，缺陷跟蹤，雖然管理活動(dòng)的加入能夠在一定程度上提高開(kāi)發(fā)過(guò)程的有序性，但是成本卻因此提高，更糟糕的是，很容易導(dǎo)致團(tuán)隊(duì)的低效率，降低創(chuàng)新能力。因此，敏捷方法視圖尋找一

16、個(gè)平衡點(diǎn)，用低成本的管理活動(dòng)帶來(lái)最大的產(chǎn)出，即軟件的高質(zhì)量。尊重人性。敏捷方法尊重人性，強(qiáng)調(diào)效率。軟件開(kāi)發(fā)可以說(shuō)是一種腦力的投入，如果不能保證開(kāi)發(fā)人員的自愿投入，產(chǎn)品就肯定要打折扣。事實(shí)多次的證明，一個(gè)愿意投入的開(kāi)發(fā)人員和一個(gè)不愿意投入的開(kāi)發(fā)人員效率相差在三倍以上，對(duì)組織的貢獻(xiàn)更是在十倍以上。溝通和反饋是一切的基礎(chǔ)。我們已經(jīng)討論過(guò)溝通的重要程度，而即時(shí)的反饋是擁抱變化的前提條件?？蛻羰巧系?。沒(méi)有客戶就沒(méi)有一切，客戶的重要性可以用一句話來(lái)形容，就是以合理的成本建造合適的軟件（build the right system at the right cost）。敏捷其實(shí)也有輕重之分，關(guān)鍵在于是否能夠

17、做到有效和靈活。因此，敏捷方法論提倡的一個(gè)思想是剛好夠（barely sufficient）。不過(guò)這個(gè)剛好夠可不是那么容易判斷的。一支8個(gè)人的團(tuán)隊(duì)采用XP方法，隨著方法的熟練使用，團(tuán)隊(duì)的能力在不斷的增強(qiáng)，能夠處理的問(wèn)題越越來(lái)越復(fù)雜，也許他們能夠處理采用重型方法的20個(gè)人團(tuán)隊(duì)能夠處理的問(wèn)題。可是如果團(tuán)隊(duì)的人數(shù)突然增加到12人，這支團(tuán)隊(duì)肯定就會(huì)出問(wèn)題，他的表現(xiàn)可能還不如那支20個(gè)人的團(tuán)隊(duì)了。人數(shù)增加了的時(shí)候，原先的方法肯定還做適當(dāng)?shù)恼{(diào)整，比如說(shuō)，在原先的敏捷方法上增加一些重型方法的技巧。我們不能夠要求一支6個(gè)人的團(tuán)隊(duì)和一支20個(gè)人的團(tuán)隊(duì)用同樣的方法，前者可能采用輕一些的敏捷方法，后者可能采用重一些

18、的敏捷方法，關(guān)鍵的問(wèn)題在于，兩支團(tuán)隊(duì)都把重點(diǎn)放在溝通、反饋、頻繁交付軟件這些關(guān)鍵的因素上，也就是做到有效和靈活。架構(gòu)設(shè)計(jì)架構(gòu)（Architecture）（也有被稱為體系結(jié)構(gòu)的）是軟件設(shè)計(jì)中非常重要的一個(gè)環(huán)節(jié)。軟件開(kāi)發(fā)的過(guò)程中只要需求和架構(gòu)確定之后，這個(gè)軟件就基本上可以定型了。這就好比骨骼確定了，這個(gè)人的體形就不會(huì)有很大的變化。因此我選擇了架構(gòu)設(shè)計(jì)來(lái)討論敏捷軟件開(kāi)發(fā)（需求我已經(jīng)寫(xiě)過(guò)了）。我們?cè)谇懊嬗懻撨^(guò)超集和子集的概念，因此我們接下去要討論的架構(gòu)設(shè)計(jì)也是一個(gè)很小的子集。方法論如果沒(méi)有經(jīng)歷過(guò)多個(gè)項(xiàng)目的檢驗(yàn)是不能稱為成功的方法論的，我也并不認(rèn)為我的架構(gòu)設(shè)計(jì)就是一個(gè)好的方法論，但引玉還需拋磚，他的主要

19、目的是為了傳播一種思想。因此，我采用了模式語(yǔ)言（PLOP）作為寫(xiě)作架構(gòu)設(shè)計(jì)的形式，主要的原因就是模式是一種很好的組織思想的方法。因此，在我們接下去的歷程中，我們集中討論的東西就圍繞著架構(gòu)、方法學(xué)、敏捷這三個(gè)要素展開(kāi)。這篇文章并不是討論如何編碼實(shí)現(xiàn)軟件架構(gòu)的，也不要單純的把它看作架構(gòu)設(shè)計(jì)的指南，其實(shí)文中的很多思想來(lái)自于方法論，因此提到的很多架構(gòu)設(shè)計(jì)的思想也適用于其它工作，如果能夠了解這一點(diǎn)，看這篇文章的收獲可能會(huì)更多一些。敏捷思維架構(gòu)設(shè)設(shè)計(jì)中的的方法學(xué)學(xué)(2)通過(guò)上一章章的介紹紹，我們們對(duì)敏捷捷和方法法有了一一個(gè)大致致的了解解，從這這一章起起，我們們開(kāi)始對(duì)對(duì)軟件開(kāi)開(kāi)發(fā)過(guò)程程中架構(gòu)構(gòu)設(shè)計(jì)的的研究。

20、記記住一點(diǎn)點(diǎn)，我們們并不是是為了架架構(gòu)設(shè)計(jì)計(jì)而研究究架構(gòu)設(shè)設(shè)計(jì)，我我們的目目的在于于敏捷方方法學(xué)的的應(yīng)用。架構(gòu)設(shè)計(jì)是一種權(quán)衡（trade-off）。一個(gè)問(wèn)題總是有多種的解決方案。而我們要確定唯一的架構(gòu)設(shè)計(jì)的解決方案，就意味著我們要在不同的矛盾體之間做出一個(gè)權(quán)衡。我們?cè)谠O(shè)計(jì)的過(guò)程總是可以看到很多的矛盾體：開(kāi)放和整合，一致性和特殊化，穩(wěn)定性和延展性等等。任何一對(duì)矛盾體都源于我們對(duì)軟件的不同期望。可是，要滿足我們希望軟件穩(wěn)定運(yùn)行的要求，就必然會(huì)影響我們對(duì)軟件易于擴(kuò)展的期望。我們希望軟件簡(jiǎn)單明了，卻增加了我們?cè)O(shè)計(jì)的復(fù)雜度。沒(méi)有一個(gè)軟件能夠滿足所有的要求，因?yàn)檫@些要求之間帶有天生的互斥性。而我們?cè)u(píng)價(jià)架構(gòu)

21、設(shè)計(jì)的好壞的依據(jù)，就只能是根據(jù)不同要求的輕重緩急，在其間做出權(quán)衡的合理性。目標(biāo)我們希望一個(gè)好的架構(gòu)能夠：重用：為了避免重復(fù)勞動(dòng)，為了降低成本，我們希望能夠重用之前的代碼、之前的設(shè)計(jì)。重用是我們不斷追求的目標(biāo)之一，但事實(shí)上，做到這一點(diǎn)可沒(méi)有那么容易。在現(xiàn)實(shí)中，人們已經(jīng)在架構(gòu)重用上做了很多的工作，工作的成果稱為框架（Framework），比如說(shuō)Windows的窗口機(jī)制、J2EE平臺(tái)等。但是在企業(yè)商業(yè)建模方面，有效的框架還非常的少。透明：有些時(shí)候，我們?yōu)榱颂岣咝剩褜?shí)現(xiàn)的細(xì)節(jié)隱藏起來(lái)，僅把客戶需求的接口呈現(xiàn)給客戶。這樣，具體的實(shí)現(xiàn)對(duì)客戶來(lái)說(shuō)就是透明的。一個(gè)具體的例子是我們使用JSP的tag技術(shù)來(lái)代

22、替JSP的嵌入代碼，因?yàn)槲覀兊腍TML界面人員更熟悉tag的方式。延展：我們對(duì)延展的渴求源于需求的易變。因此我們需要架構(gòu)具有一定的延展性，以適應(yīng)未來(lái)可能的變化?？墒?，如上所說(shuō)，延展性和穩(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)單明了的含義究竟是什么好像并沒(méi)有一個(gè)明確的定義。使用模式能夠使設(shè)計(jì)變得簡(jiǎn)單，但這是建立在我熟悉設(shè)計(jì)模式的基礎(chǔ)上。對(duì)于一個(gè)并不懂設(shè)計(jì)模式的人，他會(huì)認(rèn)為這個(gè)架構(gòu)很復(fù)雜。對(duì)于這種情況，我只能對(duì)他說(shuō)，去看看設(shè)計(jì)模式

23、。高效：不論是什么系統(tǒng)，我們都希望架構(gòu)是高效的。這一點(diǎn)對(duì)于一些特定的系統(tǒng)來(lái)說(shuō)尤其重要。例如實(shí)時(shí)系統(tǒng)、高訪問(wèn)量的網(wǎng)站。這些值的是技術(shù)上的高效，有時(shí)候我們指的高效是效益上的高效。例如，一個(gè)只有幾十到一百訪問(wèn)量的信息系統(tǒng)，是不是有必要使用EJB技術(shù)，這就需要我們綜合的評(píng)估效益了。安全：安全并不是我們文章討論的重點(diǎn)，卻是架構(gòu)的一個(gè)很重要的方面。規(guī)則為了達(dá)到上述的目的，我們通常需要對(duì)架構(gòu)設(shè)計(jì)制定一些簡(jiǎn)單的規(guī)則：功能分解顧名思義，就是把功能分解開(kāi)來(lái)。為什么呢？我們之所以很難達(dá)到重用目標(biāo)就是因?yàn)槲覀兙帉?xiě)的程序經(jīng)常處于一種好像是重復(fù)的功能，但又有輕微差別的狀態(tài)中。我們很多時(shí)候就會(huì)經(jīng)不住誘惑，用拷貝粘貼再做少量

24、修改的方式完成一個(gè)功能。這種行為在XP中是堅(jiān)決不被允許的。XP提倡Once and only once，目的就是為了杜絕這種拷貝修改的現(xiàn)象。為了做到這一點(diǎn)，我們通常要把功能分解到細(xì)粒度。很多的設(shè)計(jì)思想都提倡小類，為的就是這個(gè)目的。所以，我們的程序中的類和方法的數(shù)目就會(huì)大大增長(zhǎng)，而每個(gè)類和方法的平均代碼卻會(huì)大大的下降?？墒牵覀?cè)趺粗肋@個(gè)度應(yīng)該要如何把握呢，關(guān)于這個(gè)疑問(wèn)，并沒(méi)有明確的答案，要看個(gè)人的功力和具體的要求，但是一般來(lái)說(shuō)，我們可以用一個(gè)簡(jiǎn)單的動(dòng)詞短語(yǔ)來(lái)命名類或方法的，那就會(huì)是比較好的分類方法。我們使用功能分解的規(guī)則，有助于提高重用性，因?yàn)槲覀兠總€(gè)類和方法的精度都提高了。這是符合大自然的

25、原則的，我們研究自然的主要的一個(gè)方向就是將物質(zhì)分解。我們的思路同樣可以應(yīng)用在軟件開(kāi)發(fā)上。除了重用性，功能分解還能實(shí)現(xiàn)透明的目標(biāo)，因?yàn)槲覀兪褂昧斯δ芊纸獾囊?guī)則之后，每個(gè)類都有自己的單獨(dú)功能，這樣，我們對(duì)一個(gè)類的研究就可以集中在這個(gè)類本身，而不用牽涉到過(guò)多的類。根據(jù)實(shí)際情況決定不同類間的耦合度雖然我們總是希望類間的耦合度比較低，但是我們必須客觀的評(píng)價(jià)耦合度。系統(tǒng)之間不可能總是松耦合的，那樣肯定什么也做不了。而我們決定耦合的程度的依據(jù)何在呢？簡(jiǎn)單的說(shuō)，就是根據(jù)需求的穩(wěn)定性，來(lái)決定耦合的程度。對(duì)于穩(wěn)定性高的需求，不容易發(fā)生變化的需求，我們完全可以把各類設(shè)計(jì)成緊耦合的（我們雖然討論類之間的耦合度，但其實(shí)

26、功能塊、模塊、包之間的耦合度也是一樣的），因?yàn)檫@樣可以提高效率，而且我們還可以使用一些更好的技術(shù)來(lái)提高效率或簡(jiǎn)化代碼，例如Java中的內(nèi)部類技術(shù)?？墒?，如果需求極有可能變化，我們就需要充分的考慮類之間的耦合問(wèn)題，我們可以想出各種各樣的辦法來(lái)降低耦合程度，但是歸納起來(lái)，不外乎增加抽象的層次來(lái)隔離不同的類，這個(gè)抽象層次可以是具體的類，也可以是接口，或是一組的類（例如Beans）。我們可以借用Java中的一句話來(lái)概括降低耦合度的思想：針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程。設(shè)計(jì)不同的耦合度有利于實(shí)現(xiàn)透明和延展。對(duì)于類的客戶（調(diào)用者）來(lái)說(shuō)，他不需要知道過(guò)多的細(xì)節(jié)（實(shí)現(xiàn)），他只關(guān)心他感興趣的（接口）。這樣，目

27、標(biāo)類對(duì)客戶來(lái)說(shuō)就是一個(gè)黑盒子。如果接口是穩(wěn)定的，那么，實(shí)現(xiàn)再怎么擴(kuò)展，對(duì)客戶來(lái)說(shuō)也不會(huì)有很大的影響。以前那種牽一發(fā)而動(dòng)全身的問(wèn)題完全可以緩解甚至避免。其實(shí)，我們仔細(xì)的觀察GOF的23種設(shè)計(jì)模式，沒(méi)有一種模式的思路不是從增加抽象層次入手來(lái)解決問(wèn)題的。同樣，我們?nèi)ビ^察Java源碼的時(shí)候，我們也可以發(fā)現(xiàn)，Java源碼中存在著大量的抽象層次，初看之下，它們什么都不干，但是它們對(duì)系統(tǒng)的設(shè)計(jì)起著重大的作用。夠用就好我們?cè)谏弦徽轮芯驼勥^(guò)敏捷方法很看重剛好夠用的問(wèn)題，現(xiàn)在我們結(jié)合架構(gòu)設(shè)計(jì)來(lái)看：在同樣都能夠滿足需要的情況下，一項(xiàng)復(fù)雜的設(shè)計(jì)和一項(xiàng)簡(jiǎn)單的設(shè)計(jì)，哪一個(gè)更好。從敏捷的觀點(diǎn)來(lái)看，一定是后者。因?yàn)槟壳暗男枨?/p>

28、只有10項(xiàng)，而你的設(shè)計(jì)能夠滿足100項(xiàng)的需求，只能說(shuō)這是種浪費(fèi)。你在設(shè)計(jì)時(shí)完全沒(méi)有考慮成本問(wèn)題，不考慮成本問(wèn)題，你就是對(duì)開(kāi)發(fā)組織的不負(fù)責(zé)，對(duì)客戶的不負(fù)責(zé)。應(yīng)用模式這篇文章的寫(xiě)作思路很多來(lái)源于對(duì)模式的研究。因此，文章中到處都可以看到模式思想的影子。模式是一種整理、傳播思想的非常優(yōu)秀的途徑，我們可以通過(guò)模式的方式學(xué)習(xí)他人的經(jīng)驗(yàn)。一個(gè)好的模式代表了某個(gè)問(wèn)題研究的成果，因此我們把模式應(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ù)來(lái)實(shí)現(xiàn)現(xiàn)

29、實(shí)世界到模型的映射。因此，我們?cè)趯?duì)業(yè)務(wù)或技術(shù)理解不夠深入的情況下，就很難設(shè)計(jì)出好的架構(gòu)。當(dāng)然，這時(shí)候我們發(fā)現(xiàn)一個(gè)問(wèn)題：怎樣才能算是理解足夠深入呢。我認(rèn)為這沒(méi)有一個(gè)絕對(duì)的準(zhǔn)則。一次，一位朋友問(wèn)我：他現(xiàn)在做的系統(tǒng)有很大的變化，原先設(shè)計(jì)的工作流架構(gòu)不能滿足現(xiàn)在的要求。他很希望能夠設(shè)計(jì)出足夠好的工作流架構(gòu)，以適應(yīng)不同的變化。但是他發(fā)現(xiàn)這樣做無(wú)異于重新開(kāi)發(fā)一個(gè)lotus notes。我聽(tīng)了他的疑問(wèn)之后覺(jué)得有兩點(diǎn)問(wèn)題：首先，他的開(kāi)發(fā)團(tuán)隊(duì)中并沒(méi)有工作流領(lǐng)域的專家。他的客戶雖然了解自己的工作流程，但是缺乏足夠的理論知識(shí)把工作流提到抽象的地步。顯然，他本身雖然有技術(shù)方面的才能，但就工作流業(yè)務(wù)本身，他也沒(méi)有足夠的

30、經(jīng)驗(yàn)。所以，設(shè)計(jì)出象notes那樣的系統(tǒng)的前提條件并不存在。其次，開(kāi)發(fā)一個(gè)工作流系統(tǒng)的目的是什么。原先的工作流系統(tǒng)運(yùn)作的不好，其原因是有變化發(fā)生。因此才有改進(jìn)工作流系統(tǒng)的動(dòng)機(jī)出現(xiàn)?？墒牵吘筺otes是為了滿足世界上所有的工作流系統(tǒng)而開(kāi)發(fā)的，他目前的應(yīng)用肯定達(dá)不到這個(gè)層次。因此，雖然做不到最優(yōu)的業(yè)務(wù)抽象，但是我們完全可以在特定目的下，特定范圍內(nèi)做到最優(yōu)的業(yè)務(wù)抽象。比如說(shuō)，我們工作流可能的變化是工組流路徑的變化。我們就完全可以把工作流的路徑做一個(gè)抽象，設(shè)計(jì)一個(gè)可以動(dòng)態(tài)改變路徑的工作流架構(gòu)。有些時(shí)候，我們雖然在技術(shù)上和業(yè)務(wù)上都有所欠缺，沒(méi)有辦法設(shè)計(jì)出好的架構(gòu)。但是我們完全可以借鑒他人的經(jīng)驗(yàn)，看看類

31、似的問(wèn)題別人是如何解決的。這就是我們前面提到的模式。我們不要把模式看成是一個(gè)硬性的解決方法，它只是一種解決問(wèn)題的思路。Martin Fowler曾說(shuō)：模式和業(yè)務(wù)組件的區(qū)別就在于模式會(huì)引發(fā)你的思考。在分析模式一書(shū)中，Martin Fowler提到了分析和設(shè)計(jì)的區(qū)別。分析并不僅僅只是用用例列出所有的需求，分析還應(yīng)該深入到表面需求的背后，以得到關(guān)于問(wèn)題本質(zhì)的Mental Model。然后，他引出了概念模型的概念。概念模型就類似于我們?cè)谟懻摰某橄蟆artin Fowler提到了一個(gè)有趣的例子，如果要開(kāi)發(fā)一套軟件來(lái)模擬桌球游戲，那么，用用例來(lái)描述各種的需求，可能會(huì)導(dǎo)致大量的運(yùn)動(dòng)軌跡的出現(xiàn)。如果你沒(méi)有了

32、解表面現(xiàn)象之后隱藏的運(yùn)動(dòng)定律的本質(zhì)，你可能永遠(yuǎn)無(wú)法開(kāi)發(fā)出這樣一個(gè)系統(tǒng)。關(guān)于架構(gòu)和抽象的問(wèn)題，在后面的文章中有一個(gè)測(cè)量模式的案例可以很形象的說(shuō)明這個(gè)問(wèn)題。架構(gòu)的一些誤解我們花了一些篇幅來(lái)介紹架構(gòu)的一些知識(shí)?，F(xiàn)在回到我們的另一個(gè)主題上來(lái)。對(duì)于一個(gè)敏捷開(kāi)發(fā)過(guò)程，架構(gòu)意味著什么，我們?cè)撊绾蚊鎸?duì)架構(gòu)。這里我們首先要澄清一些誤解：誤解1：架構(gòu)設(shè)計(jì)需要很強(qiáng)的技術(shù)能力。從某種程度來(lái)說(shuō)，這句話并沒(méi)有很大的錯(cuò)誤。畢竟，你的能力越強(qiáng)，設(shè)計(jì)出優(yōu)秀架構(gòu)的幾率也會(huì)上升。但是能力和架構(gòu)設(shè)計(jì)之間并沒(méi)有一個(gè)很強(qiáng)的聯(lián)系。即使是普通的編程人員，他一樣有能力設(shè)計(jì)出能實(shí)現(xiàn)目標(biāo)的架構(gòu)。誤解2：架構(gòu)由專門(mén)的設(shè)計(jì)師來(lái)設(shè)計(jì)，設(shè)計(jì)出的藍(lán)圖交由程

33、序員來(lái)實(shí)現(xiàn)。我們之所以會(huì)認(rèn)為架構(gòu)是設(shè)計(jì)師的工作，是因?yàn)槲覀兿矚g把軟件開(kāi)發(fā)和建筑工程做類比。但是，這兩者實(shí)際上是有著很大的區(qū)別的。關(guān)鍵之處在于，建筑設(shè)計(jì)已經(jīng)有很長(zhǎng)的歷史，已經(jīng)發(fā)展出完善的理論，可以通過(guò)某些理論（如力學(xué)原理）來(lái)驗(yàn)證設(shè)計(jì)藍(lán)圖?？墒?，對(duì)軟件開(kāi)發(fā)而言，驗(yàn)證架構(gòu)設(shè)計(jì)的正確性，只能夠通過(guò)寫(xiě)代碼來(lái)驗(yàn)證。因此，很多看似完美的架構(gòu)，往往在實(shí)現(xiàn)時(shí)會(huì)出現(xiàn)問(wèn)題。誤解3：在一開(kāi)始就要設(shè)計(jì)出完善的架構(gòu)。這種方式是最傳統(tǒng)的前期設(shè)計(jì)方式。這也是為XP所摒棄的一種設(shè)計(jì)方式。主要的原因是，在一開(kāi)始設(shè)計(jì)出完美的架構(gòu)根本就是在自欺欺人。因?yàn)檫@樣做的基本假設(shè)就是需求的不變性。但需求是沒(méi)有不變的（關(guān)于需求的細(xì)節(jié)討論，請(qǐng)參看

34、拙作需求的實(shí)踐）。這樣做的壞處是，我們一開(kāi)始就限制了整個(gè)的軟件的形狀。而到實(shí)現(xiàn)時(shí)，我們雖然發(fā)現(xiàn)原來(lái)的設(shè)計(jì)有失誤之處，但卻不愿意面對(duì)現(xiàn)實(shí)。這使得軟件畸形的生長(zhǎng)。原本一些簡(jiǎn)單的問(wèn)題，卻因?yàn)閯e扭的架構(gòu)，變得非常的復(fù)雜。這種例子我們經(jīng)?？梢钥吹?，例如為兼容前個(gè)版本而導(dǎo)致的軟件復(fù)雜性。而2000年問(wèn)題，TCP/IP網(wǎng)絡(luò)的安全性問(wèn)題也從一個(gè)側(cè)面反映了這個(gè)問(wèn)題的嚴(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紙建造出和圖紙一模一樣的大廈。于是，我們也企圖在軟件開(kāi)發(fā)中使用這種模式。這是非常

35、要命的。軟件開(kāi)發(fā)中缺乏一種通用的語(yǔ)言，能夠充分的消除設(shè)計(jì)師和程序員的溝通隔閡。有人說(shuō)，UML不可以嗎？UML的設(shè)計(jì)理念是好的，可以減輕溝通障礙問(wèn)題。可是要想完全解決這個(gè)問(wèn)題，UML還做不到。首先，程序員都具有個(gè)性化的思維，他會(huì)以自己的思維方式去理解設(shè)計(jì)，因?yàn)閺脑O(shè)計(jì)到實(shí)現(xiàn)并不是一項(xiàng)機(jī)械的勞動(dòng)，還是屬于一項(xiàng)知識(shí)性的勞動(dòng)（這和施工人員的工作是不同的）。此外，對(duì)于程序員來(lái)說(shuō)，他還極有可能按照自己的想法對(duì)設(shè)計(jì)圖進(jìn)行一定的修改，這是非常正常的一項(xiàng)舉動(dòng)。更糟的是，程序員往往都比較自負(fù)，他們會(huì)潛意識(shí)的排斥那些未經(jīng)過(guò)自己認(rèn)同的設(shè)計(jì)。架構(gòu)設(shè)計(jì)的過(guò)程模式通常我們認(rèn)為模式都是用在軟件開(kāi)發(fā)、架構(gòu)設(shè)計(jì)上的。其實(shí)，這只是模

36、式的一個(gè)方面。模式的定義告訴我們，模式描述了一個(gè)特定環(huán)境的解決方法，這個(gè)特定環(huán)境往往重復(fù)出現(xiàn)，制定出一個(gè)較好的解決方法有利于我們?cè)谖磥?lái)能有效的解決類似的問(wèn)題。其實(shí)，在管理學(xué)上，也存在這種類似的這種思維。稱為結(jié)構(gòu)性問(wèn)題的程序化解決方法。所以呢，我們完全可以把模式的思想用在其它的方面，而目前最佳的運(yùn)用就是過(guò)程模式和組織模式。在我們的文章中，我們僅限于討論過(guò)程模式。我們討論的過(guò)程僅限于面向?qū)ο蟮能浖_(kāi)發(fā)過(guò)程。我們稱之為OOSP（object-oriented software process ）。因?yàn)槲覀兊倪^(guò)程需要面向?qū)ο筇匦缘闹С帧．?dāng)然，我們的很多做法一樣可以用在非OO的開(kāi)發(fā)過(guò)程中，但是為了達(dá)到最

37、佳的效果，我建議您使用OO技術(shù)。那么，我們應(yīng)該如何避開(kāi)這些誤區(qū)呢，或者，換句話說(shuō)，敏捷軟件開(kāi)發(fā)是如何做架構(gòu)設(shè)計(jì)的。這里有幾種過(guò)程模式：圖 2. 敏捷架構(gòu)過(guò)程模式概覽（High-Level）在接下去的篇幅中，我們會(huì)逐一對(duì)各種過(guò)程模式進(jìn)行介紹。然后再站在全局的角度分析各個(gè)模式之間的關(guān)系，并將之歸納為架構(gòu)設(shè)計(jì)的模式。敏捷型架構(gòu)設(shè)計(jì)我們說(shuō)我們這里列出的過(guò)程模式是敏捷型的，關(guān)于這一點(diǎn)我們會(huì)在接下去的各個(gè)章節(jié)中驗(yàn)證這一點(diǎn)。我們列出的各個(gè)過(guò)程模式并不是完全照搬敏捷型方法，因?yàn)樵诟鞣N敏捷型方法中，某些技巧適合架構(gòu)設(shè)計(jì)，某些方法則不適合架構(gòu)設(shè)計(jì)。因此，我們?cè)诓捎靡环N方法和技術(shù)前，我們會(huì)問(wèn)自己幾個(gè)簡(jiǎn)單的問(wèn)題：該方

38、法/技巧有什么價(jià)值？ 該方法/技巧需要多大的投入？從創(chuàng)建、維護(hù)、培訓(xùn)等多方面估計(jì)。 比較該方法/技巧的投入和價(jià)值，它還值得我們采用嗎？ 是否還有其它價(jià)值/投入比更高的方法/技巧呢？在我們的文章中，每一種方法/技巧的討論都回答了前三個(gè)問(wèn)題，至于第四個(gè)問(wèn)題，希望有同行能夠告訴我。敏捷思維架構(gòu)設(shè)設(shè)計(jì)中的的方法學(xué)學(xué)(3)我們說(shuō)，和和重型方方法偏重重于計(jì)劃劃、過(guò)程程和中間間產(chǎn)物不不同，敏敏捷方法法更加看看重人和和溝通。人人和溝通通永遠(yuǎn)是是第一位位的，而而計(jì)劃、過(guò)過(guò)程和中中間產(chǎn)物物，那只只是保證證溝通、實(shí)實(shí)現(xiàn)目標(biāo)標(biāo)的手段段。這并并不是說(shuō)說(shuō)計(jì)劃、過(guò)過(guò)程、中中間產(chǎn)物物不重要要，只是是不能夠夠本末倒倒置注：我們

39、把把中間產(chǎn)產(chǎn)物定義義為為了了實(shí)現(xiàn)跨跨邊界的的溝通而而制定的的文檔、模模型、代代碼。例例如設(shè)計(jì)計(jì)文檔、數(shù)數(shù)據(jù)模型型等。參參考RUUP的AArtiifacct。 評(píng)判軟軟件成功功的標(biāo)準(zhǔn)準(zhǔn)有很多多，對(duì)于于敏捷方方法論來(lái)來(lái)說(shuō)，成成功的標(biāo)標(biāo)準(zhǔn)首先先在于交交付可用用的軟件件。為了了保證軟軟件的可可用性，最最重要的的就是做做好需求求。做好好需求的的方法有有很多（參參見(jiàn)拙作作需求的的實(shí)踐），但但這并不不是我們們討論的的主題。對(duì)對(duì)于我們們要開(kāi)始始的架構(gòu)構(gòu)設(shè)計(jì)的的工作來(lái)來(lái)說(shuō)，從從需求出出發(fā)來(lái)設(shè)設(shè)計(jì)架構(gòu)構(gòu)，這就就是保證證軟件可可用性的的一個(gè)基基本的保保證。CConttextt 我們?nèi)缛绾伍_(kāi)始始我們的的架構(gòu)設(shè)設(shè)計(jì)工作

40、作？Prrobllem 我們?cè)谠谶M(jìn)行架架構(gòu)設(shè)計(jì)計(jì)的時(shí)候候，往往往主要考考慮的都都是平臺(tái)臺(tái)、語(yǔ)言言、開(kāi)發(fā)發(fā)環(huán)境、數(shù)數(shù)據(jù)庫(kù)等等一些基基本問(wèn)題題，可是是對(duì)于和和客戶的的具體情情況密切切相關(guān)的的一些問(wèn)問(wèn)題卻很很少系統(tǒng)統(tǒng)的考慮慮。甚至至還存在在一種誤誤區(qū)，認(rèn)認(rèn)為架構(gòu)構(gòu)設(shè)計(jì)無(wú)無(wú)非就是是寫(xiě)一些些空話，套套話。這這樣子做做出來(lái)架架構(gòu)設(shè)計(jì)計(jì)，如何何用于指指導(dǎo)軟件件的實(shí)現(xiàn)現(xiàn)呢？IIT界的的技術(shù)層層出不窮窮，面對(duì)對(duì)著如此此之多的的技術(shù)、平平臺(tái)、框框架、函函數(shù)庫(kù)，我我們?nèi)绾魏芜x擇一一組適合合軟件的的技術(shù)？每一個(gè)個(gè)客戶的的軟件都都有自身身的特點(diǎn)點(diǎn)，如何何才能夠夠設(shè)計(jì)出出符合客客戶利益益的架構(gòu)構(gòu)？軟件件中往往往都充斥斥著

41、眾多多的問(wèn)題題，在一一開(kāi)始就就把所有有的問(wèn)題題都想清清楚往往往很難做做到，但但是如果果不解決決問(wèn)題，風(fēng)風(fēng)險(xiǎn)又居居高不下下。Sooluttionn針對(duì)需需求設(shè)計(jì)計(jì)架構(gòu)架架構(gòu)設(shè)計(jì)計(jì)就是鋪鋪設(shè)軟件件的主管管道（例例1）。我我們根據(jù)據(jù)什么來(lái)來(lái)制定主主管道的的粗細(xì)、路路徑等因因素呢？很明顯顯，是根根據(jù)城市市的人口口、地理理位置、水水源等因因素來(lái)決決定的。對(duì)對(duì)應(yīng)到軟軟件設(shè)計(jì)計(jì)也是一一樣的。城城市的各各因素就就是軟件件中的各各種需求求：功能能需求、非非功能需需求、變變化案例例等等。一一般來(lái)說(shuō)說(shuō)，功能能需求決決定業(yè)務(wù)務(wù)架構(gòu)、非非功能需需求決定定技術(shù)架架構(gòu)，變變化案例例決定架架構(gòu)的范范圍。需需求方面面的知識(shí)識(shí)告

42、訴我我們，功功能需求求定義了了軟件能能夠做些些什么。我我們需要要根據(jù)業(yè)業(yè)務(wù)上的的需求來(lái)來(lái)設(shè)計(jì)業(yè)業(yè)務(wù)架構(gòu)構(gòu)，以使使得未來(lái)來(lái)的軟件件能夠滿滿足客戶戶的需要要。非功功能需求求定義了了一些性性能、效效率上的的一些約約束、規(guī)規(guī)則。而而我們的的技術(shù)架架構(gòu)要能能夠滿足足這些約約束和規(guī)規(guī)則。變變化案例例是對(duì)未未來(lái)可能能發(fā)生的的變化的的一個(gè)估估計(jì)，結(jié)結(jié)合功能能需求和和非功能能需求，我我們就可可以確定定一個(gè)需需求的范范圍，進(jìn)進(jìn)而確定定一個(gè)架架構(gòu)的范范圍。從從例2中中，我們們看到自自已字處處理軟件件的幾種種需求的的范例。真真正的字字處理軟軟件要復(fù)復(fù)雜的多多。而我我們最主主要的就就是必須須認(rèn)識(shí)到到，架構(gòu)構(gòu)是來(lái)自自于需

43、求求的。有有什么樣樣的需求求就有什什么樣的的架構(gòu)。試試想一下下，如果果我們沒(méi)沒(méi)有對(duì)速速度的要要求，我我們還需需要考慮慮這方面面的設(shè)計(jì)計(jì)嗎？我我們上面面提到了了幾種類類型的需需求對(duì)架架構(gòu)的影影響，其其實(shí)還有有一個(gè)很很重要的的需求，就就是環(huán)境境的需求求。這并并不是一一個(gè)很重重要的需需求，但但是對(duì)于于部署（ddeplloymmentt）架構(gòu)構(gòu)設(shè)計(jì)來(lái)來(lái)說(shuō)就特特別重要要。畢竟竟，我們們開(kāi)發(fā)出出的軟件件是要上上戰(zhàn)場(chǎng)場(chǎng)的，充充分的考考慮部署署問(wèn)題是是非常有有必要的的。例1：城市中自來(lái)水管的架設(shè)是一項(xiàng)非常的復(fù)雜的工程。為了需要滿足每家每戶的需要，自來(lái)水管組成了一個(gè)龐大的網(wǎng)絡(luò)。在這樣一個(gè)復(fù)雜的網(wǎng)絡(luò)中，如何完成鋪

44、設(shè)的任務(wù)呢。一般的做法是，先找出問(wèn)題的根源，也就是水的源頭。從水源鋪設(shè)一條管道通至城市，然后根據(jù)城市的區(qū)域劃分，設(shè)計(jì)出主管道，剩下的就是使用的問(wèn)題了，每家每戶的管道最終都是連到主管道上的。因此，雖然自來(lái)水網(wǎng)絡(luò)龐大復(fù)雜。但是真正的主管道的非常簡(jiǎn)單的。例2：我們打算開(kāi)發(fā)一個(gè)字處理軟件，功能需求可以簡(jiǎn)單概括為格式化用戶輸入的文字，非功能需求可能是格式化大小為1000K的一段文字的處理速度不能低于10S，變化案例可能是推出多種語(yǔ)言版本。那么我們?cè)谠O(shè)計(jì)業(yè)務(wù)架構(gòu)的時(shí)候，我們會(huì)集中于如何表示文字、圖象、媒體等要素，我們?cè)撔枰辛硗獾募夹g(shù)架構(gòu)來(lái)處理速度問(wèn)題，比如緩沖技術(shù)，對(duì)于變化案例，我們也要考慮相應(yīng)的架構(gòu)，

45、比如把字體獨(dú)立于程序包的設(shè)計(jì)。從需求到架架構(gòu)在需需求階段段，我們們可以得得到一些些代表需需求調(diào)研研成果的的中間產(chǎn)產(chǎn)物。比比如說(shuō)，CCRC卡卡片、基基本用例例模型、用用戶素材材、界面面原型、界界面原型型流程圖圖、非功功能需求求、變化化案例等等。我們們?cè)诩軜?gòu)構(gòu)設(shè)計(jì)階階段的主主要工作作就是要要把這些些需求階階段的中中間產(chǎn)物物轉(zhuǎn)換為為架構(gòu)設(shè)設(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)分開(kāi)來(lái)，但其實(shí)這兩者是很難區(qū)分的，做分析的時(shí)候會(huì)想到如何設(shè)計(jì)，而思考如何設(shè)計(jì)反過(guò)來(lái)

46、又會(huì)影響分析的效果。可以說(shuō)，他們兩者之間是相互聯(lián)系和不斷迭代的。這種形態(tài)我們將會(huì)在后面的迭代設(shè)計(jì)模式中詳細(xì)的討論。在敏捷方法論中，需求最好是迭代進(jìn)行的，也就是說(shuō)一點(diǎn)一點(diǎn)的作需求。這種做法在那些需求變化快的項(xiàng)目中尤其適用。由于我們采用的流程是一種迭代式的流程，這里我們將會(huì)面臨著如何對(duì)待上一次迭代的中間產(chǎn)物的問(wèn)題。如果我們每一次迭代都需要修改已存在的中間產(chǎn)物，那么這種維護(hù)的成本未免過(guò)大。因此，敏捷方法論的基本做法是，扔掉那些已經(jīng)沒(méi)有用處的中間產(chǎn)物。還記得在第一章的時(shí)候，我們強(qiáng)調(diào)說(shuō)軟件要比文檔重要。我們生成中間產(chǎn)物的目的都是為了生成最終的程序，對(duì)于這些已經(jīng)完成作用的模型，沒(méi)有必要付出額外的維護(hù)成本。

47、不要斷章取義的采用拋棄模型的做法。因?yàn)?，拋棄模型的做法需要一個(gè)適合環(huán)境的支持。后面會(huì)針對(duì)這個(gè)話題開(kāi)展大范圍的討論。這里我們簡(jiǎn)單的做一個(gè)了解：簡(jiǎn)單化：簡(jiǎn)單的模型和簡(jiǎn)單的程序。模型和程序越復(fù)雜，就需要更多的精力來(lái)處理它們。因此，我們盡可能的簡(jiǎn)化它們，為的是更容易的處理它們。高效的溝通渠道：通過(guò)增強(qiáng)溝通的效果來(lái)減少對(duì)中間產(chǎn)物的需要。試想一下，如果我隨時(shí)能夠從客戶那里得到需求的細(xì)節(jié)資料，那前期的需求調(diào)研就沒(méi)有必要做的太細(xì)致。角色的交叉輪換：開(kāi)發(fā)人員之間建立起交換角色的機(jī)制，這樣，能夠盡量的避免各子系統(tǒng)諸侯割據(jù)的局面。清晰的流程：或者我們可以稱之為明確的過(guò)程。過(guò)程在方法論中向來(lái)都是一個(gè)重點(diǎn)，敏捷方法論也

48、不例外。開(kāi)發(fā)人員能夠清楚的知道，今天做什么，明天做什么。過(guò)程不是給別人看的，而是給自己用的。工具：好用的工具能夠節(jié)省大量的時(shí)間，這里的工具并不僅僅指CASE工具，還包括了版本控制工具、自動(dòng)化測(cè)試工具、畫(huà)圖工具、文檔制作和管理工具。使用工具要注意成本和效益的問(wèn)題。標(biāo)準(zhǔn)和風(fēng)格：語(yǔ)言不通是溝通的一個(gè)很大的障礙。語(yǔ)言從某個(gè)角度來(lái)看屬于一種標(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)的含義就是說(shuō)不要做未來(lái)才有用的事情。有時(shí)

49、候，我們會(huì)把架構(gòu)考慮的非常復(fù)雜，主要的原因就是我們把很多未來(lái)的因素放入到現(xiàn)在來(lái)考慮?；蛘?，我們?cè)陂_(kāi)發(fā)第一個(gè)產(chǎn)品的時(shí)候就視圖把它做成一個(gè)完美的框架。以上的這兩種思路有沒(méi)有錯(cuò)呢？沒(méi)有錯(cuò)，這只是如何看待投入的問(wèn)題，有人希望開(kāi)始的時(shí)候多投入一些，這樣后續(xù)的投入就會(huì)節(jié)省下來(lái)。但在現(xiàn)實(shí)中，由于需求的不確定性，希望通過(guò)增加開(kāi)始階段的投入來(lái)將降低未來(lái)的投入往往是難以做到的，框架的設(shè)計(jì)也絕對(duì)不是能夠一蹴而就的，此這種做法并不是一個(gè)好的做法。所以我們?cè)诤箢^會(huì)著重論述架構(gòu)設(shè)計(jì)的簡(jiǎn)單性和迭代過(guò)程，也就是因?yàn)檫@個(gè)理由。例3：信貸系統(tǒng)在一個(gè)銀行的信貸帳務(wù)處理系統(tǒng)中，我們應(yīng)該如何把握最初的架構(gòu)思路呢？從需求上來(lái)看，這個(gè)信貸

50、帳務(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)境開(kāi)始考慮。其它系統(tǒng)和該系統(tǒng)的關(guān)系如何，應(yīng)該如何設(shè)計(jì)系統(tǒng)間的接口。通過(guò)需求的調(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)策略并不在我們的討論范圍

51、之內(nèi)，但是可以看到，架構(gòu)策略的制定是以需求為基礎(chǔ)的。我們可以把這部分的需求歸納為技術(shù)架構(gòu)或平臺(tái)架構(gòu)。然后是利息算法的問(wèn)題，我們經(jīng)過(guò)統(tǒng)計(jì)，目前的利息計(jì)算方式有四種，可預(yù)見(jiàn)到的還有兩種。在一開(kāi)始的階段，我們并不需要考慮具體算法的實(shí)現(xiàn)，但是我們需要考慮算法的實(shí)現(xiàn)框架，因此我們很自然的想到Strategy模式可以勝任這一工作，把不同的利息算法封裝起來(lái)。而我們的工作重點(diǎn)也就轉(zhuǎn)到定義利息算法的接口問(wèn)題。通過(guò)分析、比較多種利息算法，我們定義了一個(gè)最初始的算法接口，然后由不同的利息算法來(lái)實(shí)現(xiàn)算法接口。雖然，這個(gè)接口目前還不是很完整，但是它會(huì)在接下去的開(kāi)發(fā)過(guò)程中慢慢的完善起來(lái)。這部分的需求屬于業(yè)務(wù)架構(gòu)的一部分。

52、考慮到系統(tǒng)的結(jié)構(gòu)非常的復(fù)雜，因此在系統(tǒng)結(jié)構(gòu)的處理上，我們采用了層模式做為系統(tǒng)的基本結(jié)構(gòu)。此外，在每個(gè)層，我們還定義了幾個(gè)子模塊來(lái)處理特定的問(wèn)題。這樣，我們就可以將復(fù)雜的功能有序的組織起來(lái)。經(jīng)過(guò)上述的分析，我們對(duì)系統(tǒng)的架構(gòu)有了一個(gè)簡(jiǎn)單的認(rèn)識(shí)，但是還沒(méi)有結(jié)束，一個(gè)架構(gòu)應(yīng)該包括系統(tǒng)的各個(gè)基本部分，因此，我們還要考慮票據(jù)處理、報(bào)表、帳務(wù)處理等環(huán)節(jié)，但是一開(kāi)始就考慮周詳，這要花費(fèi)大量的時(shí)間，因此我們只是簡(jiǎn)單的定義了一個(gè)原始的架構(gòu)，然后在后續(xù)的開(kāi)發(fā)過(guò)程中把這個(gè)架構(gòu)完善起來(lái)。模式模式將將可以幫幫助我們們抓住重重點(diǎn)。設(shè)設(shè)計(jì)模式式在書(shū)的的一開(kāi)始始（第二二章）就就討論了了一個(gè)設(shè)設(shè)計(jì)一個(gè)個(gè)文檔編編輯器的的問(wèn)題。為為

53、了解決決設(shè)計(jì)文文檔編輯輯器引出出的七個(gè)個(gè)問(wèn)題，一一共使用用了8種種不同的的模式。這這8種模模式的組組合其實(shí)實(shí)就是架架構(gòu)，因因?yàn)樗鼈儌兘鉀Q的的，都是是系統(tǒng)中中最高層層的問(wèn)題題。在實(shí)實(shí)踐中，人們發(fā)現(xiàn)架構(gòu)也是存在模式的。比如，對(duì)于系統(tǒng)結(jié)構(gòu)設(shè)計(jì)，我們使用層模式；對(duì)于分布式系統(tǒng)，我們使用代理模式；對(duì)于交互系統(tǒng)，我們使用MVC（模型-視圖-控制器）模式。模式本來(lái)就是針對(duì)特定問(wèn)題的解，因此，針對(duì)需求的特點(diǎn)，我們也可以采用相應(yīng)的模式來(lái)設(shè)計(jì)架構(gòu)。在sun網(wǎng)站上提供的寵物商店的范例中，就把MVC模式的思想擴(kuò)展成為架構(gòu)的思想，用于提供不同的界面視圖：MVC架構(gòu)圖，這里提供原圖的概覽，查看其出處請(qǐng)點(diǎn)擊這里。我們可以了

54、解到在圖的背后隱藏著的需求：系統(tǒng)需要支持多種用戶界面，包括為普通用戶提供的HTML界面，為無(wú)線用戶提供的WML界面，為管理員提供的Swing界面，以及為B2B業(yè)務(wù)設(shè)計(jì)的WebService界面。這是系統(tǒng)最重要的需求，因此，系統(tǒng)的設(shè)計(jì)者就需要確定一個(gè)穩(wěn)定的架構(gòu)，以解決多界面的問(wèn)題。相對(duì)于多界面的問(wèn)題，后端的業(yè)務(wù)處理邏輯都是一致的。比如HTML界面和WML界面的功能并沒(méi)有太大的差別。把處理邏輯和界面分離開(kāi)來(lái)還有額外的好處，可以在添加功能的同時(shí)，不涉及界面的改動(dòng)，反之亦然。這就是我們?cè)诘诙刑岬降鸟詈隙鹊膯?wèn)題。MVC模式正可以適用于解決該問(wèn)題。系統(tǒng)使用控制器來(lái)為業(yè)務(wù)邏輯選擇不同的界面，這就完成了M

55、VC架構(gòu)的設(shè)計(jì)思路。在架構(gòu)設(shè)計(jì)的工作中，我們手頭上有模式這樣一張好牌，有什么理由不去使用它呢？抓住重點(diǎn)在架構(gòu)設(shè)計(jì)一開(kāi)始，我們就說(shuō)架構(gòu)是一種抽象，那就是說(shuō)，架構(gòu)設(shè)計(jì)摒棄了具體的細(xì)節(jié)，僅僅抓住軟件最高層的概念，也就是最上層、優(yōu)先級(jí)最高、風(fēng)險(xiǎn)最大的那部分需求。我們考慮、分析、解決一個(gè)問(wèn)題，一定有一個(gè)漸進(jìn)的過(guò)程。架構(gòu)設(shè)計(jì)就是解決問(wèn)題其中比較早期的一個(gè)階段，我們不會(huì)在架構(gòu)設(shè)計(jì)這個(gè)階段投入過(guò)多的時(shí)間（具體的原因在下文會(huì)有討論），因此關(guān)鍵點(diǎn)在于我們要能夠在架構(gòu)設(shè)計(jì)中把握住需求的重點(diǎn)。比如，我們?cè)谀Ｊ揭还?jié)中提到了分布式系統(tǒng)和交互系統(tǒng)，分布和交互就是這兩個(gè)系統(tǒng)的重點(diǎn)。那么，如果說(shuō)我們面對(duì)的是一個(gè)分布式的交互系統(tǒng)

56、，那么，我們就需要把這兩種特性做為重點(diǎn)來(lái)考慮，并以此為基礎(chǔ)，設(shè)計(jì)架構(gòu)。而我們提到的寵物商店的范例也是類似的，除了MVC的架構(gòu)，還有很多的設(shè)計(jì)問(wèn)題需要解決，例如用于數(shù)據(jù)庫(kù)訪問(wèn)的數(shù)據(jù)對(duì)象，用于視圖管理的前端控制器，等等（具體使用到的架構(gòu)模式可以訪問(wèn)sun的網(wǎng)站）。但是這些相對(duì)于MVC模式來(lái)說(shuō)，屬于局部的，優(yōu)先級(jí)較低的部分，可以在架構(gòu)確定后再來(lái)設(shè)計(jì)。架構(gòu)設(shè)計(jì)和領(lǐng)域?qū)＜乙粋€(gè)架構(gòu)要設(shè)計(jì)的好，和對(duì)需求的理解是分不開(kāi)的。因此在現(xiàn)實(shí)中，我們發(fā)現(xiàn)業(yè)務(wù)領(lǐng)域?qū)＜覒{借著他對(duì)業(yè)務(wù)領(lǐng)域的了解，能夠幫助開(kāi)發(fā)人員設(shè)計(jì)出優(yōu)秀的架構(gòu)來(lái)。架構(gòu)是需要抽象的，它是現(xiàn)實(shí)社會(huì)活動(dòng)的一個(gè)基本模型，而業(yè)務(wù)領(lǐng)域的模型僅僅憑開(kāi)發(fā)人員是很難設(shè)計(jì)出來(lái)

57、的。在ERP的發(fā)展史上，我們看到MRP發(fā)展為MRPII，在發(fā)展到閉環(huán)MRP，直到發(fā)展成為現(xiàn)在的ERP，主要的因素是管理思想的演化，也就是說(shuō)，對(duì)業(yè)務(wù)領(lǐng)域的理解進(jìn)步了，架構(gòu)才有可能進(jìn)步。因此，敏捷型架構(gòu)設(shè)計(jì)的過(guò)程中，我們也非常強(qiáng)調(diào)領(lǐng)域?qū)＜业淖饔?。敏捷思維架構(gòu)設(shè)設(shè)計(jì)中的的方法學(xué)學(xué)(4)團(tuán)隊(duì)設(shè)計(jì)是是敏捷方方法論中中很重要要的一項(xiàng)項(xiàng)實(shí)踐。我我們這里里說(shuō)的團(tuán)團(tuán)隊(duì)，指指的并不不是復(fù)數(shù)數(shù)的人。一一群人就就是一群群人，并并沒(méi)有辦辦法構(gòu)成成團(tuán)隊(duì)。要要想成為為團(tuán)隊(duì)，有有很多的的工作要要做。 我們之之所以考考慮以團(tuán)團(tuán)隊(duì)為單單位來(lái)考考慮架構(gòu)構(gòu)設(shè)計(jì)，是是因?yàn)檐涇浖_(kāi)發(fā)發(fā)本身就就不是一一件個(gè)人人的事情情，架構(gòu)構(gòu)設(shè)計(jì)更更是如

58、此此。單個(gè)個(gè)人的思思維不免免有考慮慮欠妥之之處，單單個(gè)人的的學(xué)識(shí)也也不可能能覆蓋所所有的學(xué)學(xué)科。而而組織有有效的團(tuán)團(tuán)隊(duì)卻能能夠彌補(bǔ)補(bǔ)這些缺缺憾。CConttextt 誰(shuí)來(lái)負(fù)負(fù)責(zé)架構(gòu)構(gòu)的設(shè)計(jì)計(jì)？ PProbblemm 在我我們的印印象中，總總認(rèn)為架架構(gòu)設(shè)計(jì)計(jì)是那些些所謂架架構(gòu)設(shè)計(jì)計(jì)師的專專屬工作作，他們們往往擁?yè)碛胸S富富的設(shè)計(jì)計(jì)經(jīng)驗(yàn)和和相關(guān)的的技能，他他們不用用編寫(xiě)代代碼，就就能夠設(shè)設(shè)計(jì)出理理論上盡盡善盡美美的架構(gòu)構(gòu)，配有有精美的的圖例。問(wèn)題1：理論上設(shè)計(jì)近乎完美的架構(gòu)缺乏程序的證明，在實(shí)際應(yīng)用中往往會(huì)出這樣那樣的問(wèn)題。問(wèn)題2：設(shè)計(jì)師設(shè)計(jì)架構(gòu)帶有很大的主觀性，往往會(huì)忽視客戶的需求，導(dǎo)致架構(gòu)無(wú)法滿

59、足需求。問(wèn)題3：實(shí)現(xiàn)的程序員對(duì)這種架構(gòu)有抵觸的情緒，或是因?yàn)椴焕斫饧軜?gòu)而導(dǎo)致架構(gòu)實(shí)現(xiàn)的失敗。問(wè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ì)的。例1：在XP中，我們基本上看不到架構(gòu)設(shè)計(jì)的影子。并不是說(shuō)采用XP技術(shù)的團(tuán)隊(duì)就不需要架構(gòu)設(shè)計(jì)。XP不存在專門(mén)的設(shè)計(jì)時(shí)期，它提倡使用一些簡(jiǎn)單的圖例、

60、比喻的方式來(lái)表達(dá)軟件的架構(gòu)，而這種的架構(gòu)設(shè)計(jì)是無(wú)時(shí)無(wú)刻不在進(jìn)行的。其實(shí)，XP中的設(shè)計(jì)采用的就是團(tuán)隊(duì)設(shè)計(jì)的方式，結(jié)隊(duì)編程（Pair Programming）和代碼的集體所有制（Collective Ownership）是團(tuán)隊(duì)設(shè)計(jì)的基礎(chǔ)，也就是基于口述的溝通方式。通過(guò)采用這樣的方式，XP幾乎不需要文檔來(lái)表達(dá)架構(gòu)的設(shè)計(jì)。避免象牙塔塔式的架架構(gòu)設(shè)計(jì)計(jì)對(duì)軟件件來(lái)說(shuō)，架架構(gòu)設(shè)計(jì)計(jì)是一項(xiàng)項(xiàng)至關(guān)重重要的工工作。這這樣的工工作交給給某個(gè)人人是非常常危險(xiǎn)的的。即便便這個(gè)人人再怎么么聰明，他他也可能能會(huì)遺漏漏部分的的細(xì)節(jié)。組組織有效效的團(tuán)隊(duì)隊(duì)的力量量是大大大超過(guò)個(gè)個(gè)人的力力量的，因因此團(tuán)隊(duì)隊(duì)的成果果較之個(gè)個(gè)人的成成