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