我們之所以考慮以團(tuán)隊(duì)為單位來(lái)考慮架構(gòu)設(shè)計(jì)，是因?yàn)檐浖_發(fā)本身就不是一件個(gè)人的事情，架構(gòu)設(shè)計(jì)更是如此。單個(gè)人的思維不免有考慮欠妥之處，單個(gè)人的學(xué)識(shí)也不可能覆蓋所有的學(xué)科。而組織有效的團(tuán)隊(duì)卻能夠彌補(bǔ)這些缺憾。

　　誰(shuí)來(lái)負(fù)責(zé)架構(gòu)的設(shè)計(jì)？

　　在我們的印象中，總認(rèn)為架構(gòu)設(shè)計(jì)是那些所謂架構(gòu)設(shè)計(jì)師的專屬工作，他們往往擁有豐富的設(shè)計(jì)經(jīng)驗(yàn)和相關(guān)的技能，他們不用編寫代碼，就能夠設(shè)計(jì)出理論上盡善盡美的架構(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ú)法滿足需求。

　　問(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í)的反映目前的軟件需要。

　　解決辦法

　　團(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ì)軟件來(lái)說(shuō)，架構(gòu)設(shè)計(jì)是一項(xiàng)至關(guān)重要的工作。這樣的工作交給某個(gè)人是非常危險(xiǎn)的。即便這個(gè)人再怎么聰明，他也可能會(huì)遺漏部分的細(xì)節(jié)。組織有效的團(tuán)隊(duì)的力量是大大超過(guò)個(gè)人的力量的，因此團(tuán)隊(duì)的成果較之個(gè)人的成果，在穩(wěn)定性和思考的周密程度上，都要更勝一籌。

　　Scott W. Ambler在其著作中給出了象牙塔式架構(gòu)（ivory tower architecture）的概念：

　　An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).

　　中國(guó)現(xiàn)在的軟件開發(fā)行業(yè)中也逐漸出現(xiàn)了象牙塔式的架構(gòu)設(shè)計(jì)師。這些架構(gòu)師并不參與實(shí)際的程序編寫，他的工作就是為項(xiàng)目制作出精美的架構(gòu)模型，這種架構(gòu)模型在理論上是相當(dāng)完美的。

　　例1：在XP中，我們基本上看不到架構(gòu)設(shè)計(jì)的影子。并不是說(shuō)采用XP技術(shù)的團(tuán)隊(duì)就不需要架構(gòu)設(shè)計(jì)。XP不存在專門的設(shè)計(jì)時(shí)期，它提倡使用一些簡(jiǎn)單的圖例、比喻的方式來(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ì)。

　　優(yōu)秀的架構(gòu)師能夠充分的利用現(xiàn)有框架，減少軟件的投入，增強(qiáng)軟件的穩(wěn)定性。這些都沒(méi)有錯(cuò)，但是問(wèn)題在于“過(guò)猶不及”。象牙塔式架構(gòu)師往往會(huì)出現(xiàn)文章開始指出的那些問(wèn)題。架構(gòu)設(shè)計(jì)其實(shí)并不是非常復(fù)雜的工作，但它要求開發(fā)人員具備相關(guān)的技能、經(jīng)驗(yàn)以及對(duì)問(wèn)題域有一定的了解。開發(fā)人員往往都具有相關(guān)的技術(shù)技能（編程、數(shù)據(jù)庫(kù)設(shè)計(jì)、建模），而對(duì)問(wèn)題域的理解可以從用戶和行業(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)另外一種角色，他來(lái)自于開發(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)在軟件的生命周期的全過(guò)程中都很重要，也就是說(shuō)，軟件開發(fā)團(tuán)隊(duì)中的所有人員都需要和架構(gòu)打交道。因此，最好的團(tuán)隊(duì)組織方式是所有開發(fā)人員都參與架構(gòu)的設(shè)計(jì)，我們稱這種方式為全員參與。全員參與的方式保證了所有開發(fā)人員都能夠?qū)軜?gòu)設(shè)計(jì)提出自己的見(jiàn)解，綜合多方面的意見(jiàn)，在全體開發(fā)人員中達(dá)成一致。這種方式尤其適合于一些小的團(tuán)隊(duì)。

　　還是會(huì)有很多的團(tuán)隊(duì)由于種種的原因不適合采用全員參與的方式。那么，組織優(yōu)秀的開發(fā)人員組成設(shè)計(jì)組也是比較好的方式。一般，我們選擇那些在項(xiàng)目中比較重要的，有較多開發(fā)經(jīng)驗(yàn)，或是理論扎實(shí)的那些人來(lái)組成設(shè)計(jì)組。當(dāng)然，如果你考慮到為組織培養(yǎng)后續(xù)力量，你也可以讓一些新手加入設(shè)計(jì)組，或是你覺(jué)得自己的開發(fā)力量不足，邀請(qǐng)外部的咨詢力量介入，這完全取決于具體的情況。

　　設(shè)計(jì)組不同于我們之前提到的象牙塔式架構(gòu)設(shè)計(jì)師。設(shè)計(jì)組設(shè)計(jì)出來(lái)的架構(gòu)只能稱為原始架構(gòu)，它是需要不斷的反饋和改進(jìn)的。因此，在架構(gòu)實(shí)現(xiàn)中，設(shè)計(jì)組的成員將會(huì)分布到開發(fā)團(tuán)隊(duì)的各個(gè)領(lǐng)域，把架構(gòu)的思想帶給所有開發(fā)人員，編寫代碼來(lái)檢驗(yàn)架構(gòu)，并獲得具體的反饋，然后所有的成員再集中到設(shè)計(jì)組中討論架構(gòu)的演進(jìn)。

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

　　在團(tuán)隊(duì)設(shè)計(jì)的過(guò)程，我們會(huì)遇到各種各樣的問(wèn)題，首當(dāng)其沖的就是溝通成本的問(wèn)題。架構(gòu)設(shè)計(jì)時(shí)，需求尚未被充分理解，軟件的設(shè)計(jì)思路還處于萌發(fā)的狀態(tài)。這樣的情況下，團(tuán)隊(duì)的每位成員對(duì)軟件都有獨(dú)特的見(jiàn)解，這些可能有些是相同的，有些是互斥的。就好比盲人摸象一樣，他們的觀點(diǎn)都代表了軟件的一部分或是一方面，但是沒(méi)有辦法代表軟件的全部。

　　在敏捷方法論中，我們的每一個(gè)流程都是迅速進(jìn)行、不斷改進(jìn)的。架構(gòu)設(shè)計(jì)也是一樣，我們不可能在一次架構(gòu)設(shè)計(jì)上花費(fèi)更多的時(shí)間。而團(tuán)隊(duì)決策總是傾向于較長(zhǎng)的討論和權(quán)衡。

　　例2中的問(wèn)題在架構(gòu)設(shè)計(jì)中時(shí)有發(fā)生，純技術(shù)的討論很容易上升稱為爭(zhēng)吵。這種情況幾乎沒(méi)有辦法完全避免。團(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è)非常需要注意的問(wèn)題，上述的情境在軟件組織中是經(jīng)常發(fā)生的，因?yàn)榧夹g(shù)人員很自然認(rèn)為自己的技術(shù)比別人的好，如果自己的技術(shù)受到質(zhì)疑，那怕對(duì)方是抱著討論的態(tài)度，也無(wú)異于自身的權(quán)威受到了挑戰(zhàn)，面子是無(wú)論如何都需要捍衛(wèi)的。而溝通如果帶上了這樣一層主觀色彩，那么溝通信息的受眾就會(huì)潛意識(shí)的拒絕接受信息。相反，他會(huì)找出對(duì)方話語(yǔ)中的漏洞，準(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ì)大家提出新的建議。

　　例2：敏捷方法非常注重的就是團(tuán)隊(duì)的溝通。溝通是一個(gè)很有意思的話題，講起來(lái)會(huì)花費(fèi)大量的時(shí)間，我們這里只是針對(duì)架構(gòu)設(shè)計(jì)中可能存在的溝通問(wèn)題做一個(gè)簡(jiǎn)單的討論。我們這里假設(shè)一個(gè)討論情境，這個(gè)情境來(lái)源于真實(shí)的生活：項(xiàng)目主管徐輝、設(shè)計(jì)師李浩、設(shè)計(jì)師羅亦明正在討論一個(gè)新的軟件架構(gòu)。 "李浩你認(rèn)為這個(gè)軟件數(shù)據(jù)庫(kù)連接部分應(yīng)該如何考慮？"徐輝問(wèn)。李浩想了想，"我覺(jué)得方案A不錯(cuò)…" "方案A肯定有問(wèn)題！這個(gè)軟件和上一次的又不同。"羅亦明打斷了李浩的發(fā)言。 "你懂什么！你到公司才多久，方案A是經(jīng)過(guò)很長(zhǎng)時(shí)間的證明的！"發(fā)言被打斷，李浩有點(diǎn)惱火，羅亦明進(jìn)入公司沒(méi)有多久，但在一些事情上老是和他唱反調(diào)。 "我進(jìn)公司多久和方案A的錯(cuò)誤有什么關(guān)系！" 在這樣一種氛圍中，會(huì)議的結(jié)果可想而知。

　　良好的溝通有助于架構(gòu)設(shè)計(jì)工作的開展。一個(gè)成員的能力平平的團(tuán)隊(duì)，可以藉由良好的溝通，設(shè)計(jì)出優(yōu)秀的架構(gòu)，而一個(gè)擁有一個(gè)優(yōu)秀成員的團(tuán)隊(duì)，如果缺乏溝通，最后可能連設(shè)計(jì)都出不來(lái)。這種例子現(xiàn)實(shí)中可以找到很多。

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

　　我們總是在不知不覺(jué)之中使用各種各樣的標(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)格的，那么理解起來(lái)肯定會(huì)困難許多。當(dāng)然，我們沒(méi)有必要自己開發(fā)一套標(biāo)準(zhǔn)（風(fēng)格）出來(lái)，現(xiàn)實(shí)中有很多可以直接借用的資料。最好的標(biāo)準(zhǔn)是UML語(yǔ)言，我們可以從UML的官方網(wǎng)站下載到最新的規(guī)范，常用的編碼標(biāo)準(zhǔn)更是隨處可見(jiàn)。不過(guò)雖然有了統(tǒng)一的標(biāo)準(zhǔn)，如果風(fēng)格不統(tǒng)一，同樣會(huì)造成溝通的障礙。例如下圖顯示的類圖，雖然它們表示的是同一個(gè)類，但是由于版型、可視性、詳細(xì)程度的差別，看起來(lái)又很大的差別。而在其它的標(biāo)準(zhǔn)中，這種差別也是普遍存在的。因此，我們?cè)谑褂昧私y(tǒng)一的標(biāo)準(zhǔn)之后，還應(yīng)該使用同樣的風(fēng)格。Scott W. Ambler專門成立了一個(gè)網(wǎng)站討論UML的建模風(fēng)格的相關(guān)問(wèn)題，有興趣的讀者可以做額外的閱讀。

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

　　在統(tǒng)一的風(fēng)格的基礎(chǔ)上更進(jìn)一步的是使用術(shù)語(yǔ)。使用溝通雙方都了解專門的術(shù)語(yǔ)，可以代表大量的信息。最好的術(shù)語(yǔ)的范例就是設(shè)計(jì)模式的模式名。如果溝通的雙方都了解設(shè)計(jì)模式，那么一方只需要說(shuō)這部分的設(shè)計(jì)可以使用工廠模式，另一方就能夠理解，而不用再詳細(xì)的解釋設(shè)計(jì)的思路。這種的溝通方式是最高效的，但它所需要的學(xué)習(xí)曲線也會(huì)比較陡。

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

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

　　1、明確目標(biāo)

　　泛泛的召開架構(gòu)討論會(huì)議是沒(méi)有什么意義的，一個(gè)沒(méi)有鮮明主題的會(huì)議也不會(huì)有什么結(jié)果。在源自需求的模式中，我們談到說(shuō)可以有非功能需求的架構(gòu)，可以有功能需求的架構(gòu)。因此，在進(jìn)行團(tuán)隊(duì)設(shè)計(jì)之前，我們首先也需要確定，此次要解決什么問(wèn)題，是討論業(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è)軟件沒(méi)有界面嗎？（有些軟件可能是這種情況）你能夠想象一個(gè)軟件只有數(shù)據(jù)庫(kù)，而沒(méi)有處理邏輯嗎？因此，架構(gòu)設(shè)計(jì)就需要綜合的考慮各個(gè)方面，充分利用成員的優(yōu)勢(shì)。這就要求團(tuán)隊(duì)的各個(gè)成員都能夠明確自己的分工。

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

　　除了明確自己的分工，每位成員都需要清楚自己的責(zé)任。沒(méi)有責(zé)任，分工就不會(huì)有任何的效力。每位成員都需要明確自己要做些什么。當(dāng)然，和責(zé)任相對(duì)的，沒(méi)有成員還需要知道自己的權(quán)力是什么。這些清楚了，進(jìn)行高效的溝通的前提就具備了。每次架構(gòu)的討論下來(lái)，每個(gè)人都清楚，自己要做些什么，自己需要要求其他人做些什么，自己該對(duì)誰(shuí)負(fù)責(zé)。如果這些問(wèn)題回答不了，那這次的討論就白費(fèi)了。

　　4、明確溝通方式

　　這里使用溝通方式可能有一點(diǎn)點(diǎn)不恰當(dāng)，為了明確的表達(dá)意思，大家可以考慮信息流這個(gè)詞。一個(gè)完整架構(gòu)包括幾個(gè)方面，分別都由那些人負(fù)責(zé)，如何產(chǎn)生，產(chǎn)生的整個(gè)過(guò)程應(yīng)該是什么樣的？這樣的一個(gè)信息流程，囊括了上面提到的三個(gè)明確。如果團(tuán)隊(duì)的每一個(gè)人都能夠?yàn)榧軜?gòu)的產(chǎn)生而努力，并順利的設(shè)計(jì)出架構(gòu)，那么這樣的流程是完美的。如果你發(fā)現(xiàn)其中的一些人不知道做些什么，那么，這就是流程出問(wèn)題的現(xiàn)象了。完美的流程還會(huì)有一個(gè)額外的副產(chǎn)品，架構(gòu)產(chǎn)生之后，團(tuán)隊(duì)對(duì)于軟件的設(shè)計(jì)已經(jīng)是非常的清晰了。因?yàn)槲覀兲岢氖潜M可能多的開發(fā)人員參與架構(gòu)的設(shè)計(jì)。

　　不僅僅是架構(gòu)

　　討論到這里，其實(shí)有很多的內(nèi)容已經(jīng)脫離了架構(gòu)設(shè)計(jì)了。也就是說(shuō)，很多的原則和技巧都是可以用于軟件開發(fā)的其它活動(dòng)的。至于哪一些活動(dòng)能夠利用這些方法呢？大家可以結(jié)合自己的實(shí)際情況，來(lái)思考這個(gè)問(wèn)題。提示一點(diǎn)，關(guān)鍵的入手處在于目前效率較低之處。