我們之所以考慮以團(tuán)隊為單位來考慮架構(gòu)設(shè)計，是因為軟件開發(fā)本身就不是一件個人的事情，架構(gòu)設(shè)計更是如此。單個人的思維不免有考慮欠妥之處，單個人的學(xué)識也不可能覆蓋所有的學(xué)科。而組織有效的團(tuán)隊卻能夠彌補(bǔ)這些缺憾。
誰來負(fù)責(zé)架構(gòu)的設(shè)計？
回頁首在我們的印象中，總認(rèn)為架構(gòu)設(shè)計是那些所謂架構(gòu)設(shè)計師的專屬工作，他們往往擁有豐富的設(shè)計經(jīng)驗和相關(guān)的技能，他們不用編寫代碼，就能夠設(shè)計出理論上盡善盡美的架構(gòu)，配有精美的圖例。
問題1：理論上設(shè)計近乎完美的架構(gòu)缺乏程序的證明，在實際應(yīng)用中往往會出這樣那樣的問題。
問題2：設(shè)計師設(shè)計架構(gòu)帶有很大的主觀性，往往會忽視客戶的需求，導(dǎo)致架構(gòu)無法滿足需求。
問題3：實現(xiàn)的程序員對這種架構(gòu)有抵觸的情緒，或是因為不理解架構(gòu)而導(dǎo)致架構(gòu)實現(xiàn)的失敗。
問題4：架構(gòu)師設(shè)計架構(gòu)主要是依據(jù)自己的大量經(jīng)驗，設(shè)計出的架構(gòu)不能真實的反映目前的軟件需要。
回頁首團(tuán)隊設(shè)計的理論依據(jù)是群體決策。和個人決策相比，群體決策的最大好處就是其結(jié)論要更加的完整。而群體決策雖然有其優(yōu)點，但其缺點也是很明顯的：需要額外付出溝通成本、決策效率低、責(zé)任不明確、等等。但是群體決策如果能夠組織得當(dāng)?shù)脑?，是能夠在架?gòu)設(shè)計中發(fā)揮很大的優(yōu)勢的。
避免象牙塔式的架構(gòu)設(shè)計
例1：在XP中，我們基本上看不到架構(gòu)設(shè)計的影子。并不是說采用XP技術(shù)的團(tuán)隊就不需要架構(gòu)設(shè)計。XP不存在專門的設(shè)計時期，它提倡使用一些簡單的圖例、比喻的方式來表達(dá)軟件的架構(gòu)，而這種的架構(gòu)設(shè)計是無時無刻不在進(jìn)行的。其實，XP中的設(shè)計采用的就是團(tuán)隊設(shè)計的方式，結(jié)隊編程（Pair Programming）和代碼的集體所有制（Collective Ownership）是團(tuán)隊設(shè)計的基礎(chǔ)，也就是基于口述的溝通方式。通過采用這樣的方式，XP幾乎不需要文檔來表達(dá)架構(gòu)的設(shè)計。
對軟件來說，架構(gòu)設(shè)計是一項至關(guān)重要的工作。這樣的工作交給某個人是非常危險的。即便這個人再怎么聰明，他也可能會遺漏部分的細(xì)節(jié)。組織有效的團(tuán)隊的力量是大大超過個人的力量的，因此團(tuán)隊的成果較之個人的成果，在穩(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).
中國現(xiàn)在的軟件開發(fā)行業(yè)中也逐漸出現(xiàn)了象牙塔式的架構(gòu)設(shè)計師。這些架構(gòu)師并不參與實際的程序編寫，他的工作就是為項目制作出精美的架構(gòu)模型，這種架構(gòu)模型在理論上是相當(dāng)完美的。
優(yōu)秀的架構(gòu)師能夠充分的利用現(xiàn)有框架，減少軟件的投入，增強(qiáng)軟件的穩(wěn)定性。這些都沒有錯，但是問題在于“過猶不及”。象牙塔式架構(gòu)師往往會出現(xiàn)文章開始指出的那些問題。架構(gòu)設(shè)計其實并不是非常復(fù)雜的工作，但它要求開發(fā)人員具備相關(guān)的技能、經(jīng)驗以及對問題域有一定的了解。開發(fā)人員往往都具有相關(guān)的技術(shù)技能（編程、數(shù)據(jù)庫設(shè)計、建模），而對問題域的理解可以從用戶和行業(yè)專家那里獲得幫助。因此，在理論上，我們要實現(xiàn)架構(gòu)設(shè)計的團(tuán)隊化是完全可能的。
在上面的象牙塔式架構(gòu)定義中，我們看到架構(gòu)師和日常的開發(fā)工作是隔絕的。這樣的設(shè)計出的架構(gòu)有很大的局限性。在現(xiàn)實中，我們還會發(fā)現(xiàn)另外一種角色，他來自于開發(fā)團(tuán)隊外部，為開發(fā)人員提供相關(guān)的技術(shù)或業(yè)務(wù)的培訓(xùn)。這種角色稱為教練，在軟件開發(fā)中是非常重要的角色，不能夠和象牙塔式架構(gòu)設(shè)計師之間畫等號。
選擇你的設(shè)計團(tuán)隊。
軟件的架構(gòu)在軟件的生命周期的全過程中都很重要，也就是說，軟件開發(fā)團(tuán)隊中的所有人員都需要和架構(gòu)打交道。因此，最好的團(tuán)隊組織方式是所有開發(fā)人員都參與架構(gòu)的設(shè)計，我們稱這種方式為全員參與。全員參與的方式保證了所有開發(fā)人員都能夠?qū)軜?gòu)設(shè)計提出自己的見解，綜合多方面的意見，在全體開發(fā)人員中達(dá)成一致。這種方式尤其適合于一些小的團(tuán)隊。
還是會有很多的團(tuán)隊由于種種的原因不適合采用全員參與的方式。那么，組織優(yōu)秀的開發(fā)人員組成設(shè)計組也是比較好的方式。一般，我們選擇那些在項目中比較重要的，有較多開發(fā)經(jīng)驗，或是理論扎實的那些人來組成設(shè)計組。當(dāng)然，如果你考慮到為組織培養(yǎng)后續(xù)力量，你也可以讓一些新手加入設(shè)計組，或是你覺得自己的開發(fā)力量不足，邀請外部的咨詢力量介入，這完全取決于具體的情況。
設(shè)計組不同于我們之前提到的象牙塔式架構(gòu)設(shè)計師。設(shè)計組設(shè)計出來的架構(gòu)只能稱為原始架構(gòu)，它是需要不斷的反饋和改進(jìn)的。因此，在架構(gòu)實現(xiàn)中，設(shè)計組的成員將會分布到開發(fā)團(tuán)隊的各個領(lǐng)域，把架構(gòu)的思想帶給所有開發(fā)人員，編寫代碼來檢驗架構(gòu)，并獲得具體的反饋，然后所有的成員再集中到設(shè)計組中討論架構(gòu)的演進(jìn)。
團(tuán)隊設(shè)計中存在的問題
例2：敏捷方法非常注重的就是團(tuán)隊的溝通。溝通是一個很有意思的話題，講起來會花費大量的時間，我們這里只是針對架構(gòu)設(shè)計中可能存在的溝通問題做一個簡單的討論。我們這里假設(shè)一個討論情境，這個情境來源于真實的生活：
項目主管徐輝、設(shè)計師李浩、設(shè)計師羅亦明正在討論一個新的軟件架構(gòu)。
"李浩你認(rèn)為這個軟件數(shù)據(jù)庫連接部分應(yīng)該如何考慮？"徐輝問。
李浩想了想，"我覺得方案A不錯…" "方案A肯定有問題！這個軟件和上一次的又不同。"羅亦明打斷了李浩的發(fā)言。
"你懂什么！你到公司才多久，方案A是經(jīng)過很長時間的證明的！"發(fā)言被打斷，李浩有點惱火，羅亦明進(jìn)入公司沒有多久，但在一些事情上老是和他唱反調(diào)。
"我進(jìn)公司多久和方案A的錯誤有什么關(guān)系！"
在這樣一種氛圍中，會議的結(jié)果可想而知。
在團(tuán)隊設(shè)計的過程，我們會遇到各種各樣的問題，首當(dāng)其沖的就是溝通成本的問題。架構(gòu)設(shè)計時，需求尚未被充分理解，軟件的設(shè)計思路還處于萌發(fā)的狀態(tài)。這樣的情況下，團(tuán)隊的每位成員對軟件都有獨特的見解，這些可能有些是相同的，有些是互斥的。就好比盲人摸象一樣，他們的觀點都代表了軟件的一部分或是一方面，但是沒有辦法代表軟件的全部。
在敏捷方法論中，我們的每一個流程都是迅速進(jìn)行、不斷改進(jìn)的。架構(gòu)設(shè)計也是一樣，我們不可能在一次架構(gòu)設(shè)計上花費更多的時間。而團(tuán)隊決策總是傾向于較長的討論和權(quán)衡。
例2中的問題在架構(gòu)設(shè)計中時有發(fā)生，純技術(shù)的討論很容易上升稱為爭吵。這種情況幾乎沒有辦法完全避免。團(tuán)隊型的決策必然會發(fā)生觀念的沖突?？刂埔欢ǔ潭葍?nèi)的觀念的沖突對團(tuán)隊的決策是有益，但是如果超出了這個程度就意味著失控了，需要團(tuán)隊領(lǐng)導(dǎo)者的調(diào)節(jié)。而更重要的，我們需要注意溝通的技巧：
團(tuán)隊溝通
團(tuán)隊進(jìn)行架構(gòu)設(shè)計的時候溝通是一個非常需要注意的問題，上述的情境在軟件組織中是經(jīng)常發(fā)生的，因為技術(shù)人員很自然認(rèn)為自己的技術(shù)比別人的好，如果自己的技術(shù)受到質(zhì)疑，那怕對方是抱著討論的態(tài)度，也無異于自身的權(quán)威受到了挑戰(zhàn)，面子是無論如何都需要捍衛(wèi)的。而溝通如果帶上了這樣一層主觀色彩，那么溝通信息的受眾就會潛意識的拒絕接受信息。相反，他會找出對方話語中的漏洞，準(zhǔn)備進(jìn)行反擊。因此，我們要注意培養(yǎng)一種良好的溝通氛圍。
在實際的觀察中，我發(fā)現(xiàn)團(tuán)隊溝通中存在兩種角色，一種是建議者，他們經(jīng)常能夠提出建議。一種是質(zhì)疑者，他們對建議提出否定性的看法。這兩種角色是可能互換的，現(xiàn)在的建議者可能就是剛才的質(zhì)疑者。質(zhì)疑者的發(fā)言是很能打擊建議者的積極性的，而在一個腦力激蕩的會議中，最好是大家都能夠扮演建議者的角色，這就要求溝通會議的主持者能夠掌握好這一點，對建議給予肯定的評價，并鼓勵大家提出新的建議。
良好的溝通有助于架構(gòu)設(shè)計工作的開展。一個成員的能力平平的團(tuán)隊，可以藉由良好的溝通，設(shè)計出優(yōu)秀的架構(gòu)，而一個擁有一個優(yōu)秀成員的團(tuán)隊，如果缺乏溝通，最后可能連設(shè)計都出不來。這種例子現(xiàn)實中可以找到很多。
標(biāo)準(zhǔn)和風(fēng)格
我們總是在不知不覺之中使用各種各樣的標(biāo)準(zhǔn)和風(fēng)格。在團(tuán)隊設(shè)計中，我們?yōu)榱颂岣邲Q策的效率，可以考慮使用統(tǒng)一的標(biāo)準(zhǔn)和風(fēng)格。統(tǒng)一的標(biāo)準(zhǔn)和風(fēng)格并不是一朝一夕形成的。因為每個人都有自己不同的習(xí)慣和經(jīng)歷，強(qiáng)制性的要求開發(fā)人員使用統(tǒng)一的標(biāo)準(zhǔn)（風(fēng)格）容易引起開發(fā)人員的不滿。因此在操作上需要注意技巧。對架構(gòu)設(shè)計而言，比較重要的標(biāo)準(zhǔn)（風(fēng)格）包括以下的這些類別：
a. 界面設(shè)計
b. 流程設(shè)計
c. 建模規(guī)范
d. 編碼規(guī)范
e. 持久層設(shè)計
f. 測試數(shù)據(jù)
在我的經(jīng)驗中，有一些組織平時并不注意標(biāo)準(zhǔn)（風(fēng)格）的積累，認(rèn)為這種積累屬于雕蟲小技，但正是這些小技，能夠非常有效的提高溝通的效率和降低開發(fā)人員的學(xué)習(xí)曲線。試想一下，如果一個團(tuán)隊中所有人寫出的代碼都是不同標(biāo)準(zhǔn)和風(fēng)格的，那么理解起來肯定會困難許多。當(dāng)然，我們沒有必要自己開發(fā)一套標(biāo)準(zhǔn)（風(fēng)格）出來，現(xiàn)實中有很多可以直接借用的資料。最好的標(biāo)準(zhǔn)是UML語言，我們可以從UML的官方網(wǎng)站下載到最新的規(guī)范，常用的編碼標(biāo)準(zhǔn)更是隨處可見。不過雖然有了統(tǒng)一的標(biāo)準(zhǔn)，如果風(fēng)格不統(tǒng)一，同樣會造成溝通的障礙。例如下圖顯示的類圖，雖然它們表示的是同一個類，但是由于版型、可視性、詳細(xì)程度的差別，看起來又很大的差別。而在其它的標(biāo)準(zhǔn)中，這種差別也是普遍存在的。因此，我們在使用了統(tǒng)一的標(biāo)準(zhǔn)之后，還應(yīng)該使用同樣的風(fēng)格。Scott W. Ambler專門成立了一個網(wǎng)站討論UML的建模風(fēng)格的相關(guān)問題，有興趣的讀者可以做額外的閱讀。
在統(tǒng)一的風(fēng)格的基礎(chǔ)上更進(jìn)一步的是使用術(shù)語。使用溝通雙方都了解專門的術(shù)語，可以代表大量的信息。最好的術(shù)語的范例就是設(shè)計模式的模式名。如果溝通的雙方都了解設(shè)計模式，那么一方只需要說這部分的設(shè)計可以使用工廠模式，另一方就能夠理解，而不用再詳細(xì)的解釋設(shè)計的思路。這種的溝通方式是最高效的，但它所需要的學(xué)習(xí)曲線也會比較陡。
團(tuán)隊設(shè)計的四明確
為了最大程度的提高團(tuán)隊設(shè)計的高效性，可以從4個方面來考慮：
1、明確目標(biāo)
泛泛的召開架構(gòu)討論會議是沒有什么意義的，一個沒有鮮明主題的會議也不會有什么結(jié)果。在源自需求的模式中，我們談到說可以有非功能需求的架構(gòu)，可以有功能需求的架構(gòu)。因此，在進(jìn)行團(tuán)隊設(shè)計之前，我們首先也需要確定，此次要解決什么問題，是討論業(yè)務(wù)邏輯的架構(gòu)，還是技術(shù)架構(gòu)；是全局性的架構(gòu)，還是各模塊的架構(gòu)。
2、明確分工
我們之所以重視團(tuán)隊，很重要的額一個原因就是不同的成員有不同的擅長的區(qū)域。有些成員可能擅長于業(yè)務(wù)邏輯的建模，有的擅長于原型設(shè)計，有的擅長于數(shù)據(jù)庫設(shè)計，有的則擅長于Web編程。你能夠想象一個軟件沒有界面嗎？（有些軟件可能是這種情況）你能夠想象一個軟件只有數(shù)據(jù)庫，而沒有處理邏輯嗎？因此，架構(gòu)設(shè)計就需要綜合的考慮各個方面，充分利用成員的優(yōu)勢。這就要求團(tuán)隊的各個成員都能夠明確自己的分工。
3、明確責(zé)權(quán)
除了明確自己的分工，每位成員都需要清楚自己的責(zé)任。沒有責(zé)任，分工就不會有任何的效力。每位成員都需要明確自己要做些什么。當(dāng)然，和責(zé)任相對的，每位成員還需要知道自己的權(quán)力是什么。這些清楚了，進(jìn)行高效的溝通的前提就具備了。每次架構(gòu)的討論下來，每個人都清楚，自己要做些什么，自己需要要求其他人做些什么，自己該對誰負(fù)責(zé)。如果這些問題回答不了，那這次的討論就白費了。
4、明確溝通方式
這里使用溝通方式可能有一點點不恰當(dāng)，為了明確的表達(dá)意思，大家可以考慮信息流這個詞。一個完整架構(gòu)包括幾個方面，分別都由那些人負(fù)責(zé)，如何產(chǎn)生，產(chǎn)生的整個過程應(yīng)該是什么樣的？這樣的一個信息流程，囊括了上面提到的三個明確。如果團(tuán)隊的每一個人都能夠為架構(gòu)的產(chǎn)生而努力，并順利的設(shè)計出架構(gòu)，那么這樣的流程是完美的。如果你發(fā)現(xiàn)其中的一些人不知道做些什么，那么，這就是流程出問題的現(xiàn)象了。完美的流程還會有一個額外的副產(chǎn)品，架構(gòu)產(chǎn)生之后，團(tuán)隊對于軟件的設(shè)計已經(jīng)是非常的清晰了。因為我們提倡的是盡可能多的開發(fā)人員參與架構(gòu)的設(shè)計。
不僅僅是架構(gòu)
討論到這里，其實有很多的內(nèi)容已經(jīng)脫離了架構(gòu)設(shè)計了。也就是說，很多的原則和技巧都是可以用于軟件開發(fā)的其它活動的。至于哪一些活動能夠利用這些方法呢？大家可以結(jié)合自己的實際情況，來思考這個問題。提示一點，關(guān)鍵的入手處在于目前效率較低之處。
林星，辰訊軟件工作室項目管理組資深項目經(jīng)理，有多年項目實施經(jīng)驗。辰訊軟件工作室致力于先進(jìn)軟件思想、軟件技術(shù)的應(yīng)用，主要的研究方向在于軟件過程思想、Linux集群技術(shù)、OO技術(shù)和軟件工廠模式。您可以通過電子郵件
iamlinx@21cn.com和他聯(lián)系。
