通過上一章的介紹，我們對敏捷和方法有了一個大致的了解，從這一章起，我們開始對軟件開發過程中架構設計的研究。記住一點，我們并不是為了架構設計而研究架構設計，我們的目的在于敏捷方法學的應用。
架構設計是一種權衡（trade-off）。一個問題總是有多種的解決方案。而我們要確定唯一的架構設計的解決方案，就意味著我們要在不同的矛盾體之間做出一個權衡。我們在設計的過程總是可以看到很多的矛盾體：開放和整合，一致性和特殊化，穩定性和延展性等等。任何一對矛盾體都源于我們對軟件的不同期望�？墒�，要滿足我們希望軟件穩定運行的要求，就必然會影響我們對軟件易于擴展的期望。我們希望軟件簡單明了，卻增加了我們設計的復雜度。沒有一個軟件能夠滿足所有的要求，因為這些要求之間帶有天生的互斥性。而我們評價架構設計的好壞的依據，就只能是根據不同要求的輕重緩急，在其間做出權衡的合理性。
目標
我們希望一個好的架構能夠：
重用：為了避免重復勞動，為了降低成本，我們希望能夠重用之前的代碼、之前的設計。重用是我們不斷追求的目標之一，但事實上，做到這一點可沒有那么容易。在現實中，人們已經在架構重用上做了很多的工作，工作的成果稱為框架（Framework），比如說Windows的窗口機制、J2EE平臺等。但是在企業商業建模方面，有效的框架還非常的少。
透明：有些時候，我們為了提高效率，把實現的細節隱藏起來，僅把客戶需求的接口呈現給客戶。這樣，具體的實現對客戶來說就是透明的。一個具體的例子是我們使用JSP的tag技術來代替JSP的嵌入代碼，因為我們的HTML界面人員更熟悉tag的方式。
延展：我們對延展的渴求源于需求的易變。因此我們需要架構具有一定的延展性，以適應未來可能的變化�？墒�，如上所說，延展性和穩定性，延展性和簡單性都是矛盾的。因此我們需要權衡我們的投入/產出比。以設計出具有適當和延展性的架構。
簡明：一個復雜的架構不論是測試還是維護都是困難的。我們希望架構能夠在滿足目的的情況下盡可能的簡單明了。但是簡單明了的含義究竟是什么好像并沒有一個明確的定義。使用模式能夠使設計變得簡單，但這是建立在我熟悉設計模式的基礎上。對于一個并不懂設計模式的人，他會認為這個架構很復雜。對于這種情況，我只能對他說，去看看設計模式。
高效：不論是什么系統，我們都希望架構是高效的。這一點對于一些特定的系統來說尤其重要。例如實時系統、高訪問量的網站。這些值的是技術上的高效，有時候我們指的高效是效益上的高效。例如，一個只有幾十到一百訪問量的信息系統，是不是有必要使用EJB技術，這就需要我們綜合的評估效益了。
安全：安全并不是我們文章討論的重點，卻是架構的一個很重要的方面。
規則
為了達到上述的目的，我們通常需要對架構設計制定一些簡單的規則：
功能分解
顧名思義，就是把功能分解開來。為什么呢？我們之所以很難達到重用目標就是因為我們編寫的程序經常處于一種好像是重復的功能，但又有輕微差別的狀態中。我們很多時候就會經不住誘惑，用拷貝粘貼再做少量修改的方式完成一個功能。這種行為在XP中是堅決不被允許的。XP提倡"Once and only once"，目的就是為了杜絕這種拷貝修改的現象。為了做到這一點，我們通常要把功能分解到細粒度。很多的設計思想都提倡小類，為的就是這個目的。
所以，我們的程序中的類和方法的數目就會大大增長，而每個類和方法的平均代碼卻會大大的下降�？墒�，我們怎么知道這個度應該要如何把握呢，關于這個疑問，并沒有明確的答案，要看個人的功力和具體的要求，但是一般來說，我們可以用一個簡單的動詞短語來命名類或方法的，那就會是比較好的分類方法。
我們使用功能分解的規則，有助于提高重用性，因為我們每個類和方法的精度都提高了。這是符合大自然的原則的，我們研究自然的主要的一個方向就是將物質分解。我們的思路同樣可以應用在軟件開發上。除了重用性，功能分解還能實現透明的目標，因為我們使用了功能分解的規則之后，每個類都有自己的單獨功能，這樣，我們對一個類的研究就可以集中在這個類本身，而不用牽涉到過多的類。
根據實際情況決定不同類間的耦合度
雖然我們總是希望類間的耦合度比較低，但是我們必須客觀的評價耦合度。系統之間不可能總是松耦合的，那樣肯定什么也做不了。而我們決定耦合的程度的依據何在呢？簡單的說，就是根據需求的穩定性，來決定耦合的程度。對于穩定性高的需求，不容易發生變化的需求，我們完全可以把各類設計成緊耦合的（我們雖然討論類之間的耦合度，但其實功能塊、模塊、包之間的耦合度也是一樣的），因為這樣可以提高效率，而且我們還可以使用一些更好的技術來提高效率或簡化代碼，例如Java中的內部類技術�？墒�，如果需求極有可能變化，我們就需要充分的考慮類之間的耦合問題，我們可以想出各種各樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個抽象層次可以是具體的類，也可以是接口，或是一組的類（例如Beans）。我們可以借用Java中的一句話來概括降低耦合度的思想："針對接口編程，而不是針對實現編程。"
設計不同的耦合度有利于實現透明和延展。對于類的客戶（調用者）來說，他不需要知道過多的細節（實現），他只關心他感興趣的（接口）。這樣，目標類對客戶來說就是一個黑盒子。如果接口是穩定的，那么，實現再怎么擴展，對客戶來說也不會有很大的影響。以前那種牽一發而動全身的問題完全可以緩解甚至避免。
其實，我們仔細的觀察GOF的23種設計模式，沒有一種模式的思路不是從增加抽象層次入手來解決問題的。同樣，我們去觀察Java源碼的時候，我們也可以發現，Java源碼中存在著大量的抽象層次，初看之下，它們什么都不干，但是它們對系統的設計起著重大的作用。
夠用就好
我們在上一章中就談過敏捷方法很看重剛好夠用的問題，現在我們結合架構設計來看：在同樣都能夠滿足需要的情況下，一項復雜的設計和一項簡單的設計，哪一個更好。從敏捷的觀點來看，一定是后者。因為目前的需求只有10項，而你的設計能夠滿足100項的需求，只能說這是種浪費。你在設計時完全沒有考慮成本問題，不考慮成本問題，你就是對開發組織的不負責，對客戶的不負責。
應用模式
這篇文章的寫作思路很多來源于對模式的研究。因此，文章中到處都可以看到模式思想的影子。模式是一種整理、傳播思想的非常優秀的途徑，我們可以通過模式的方式學習他人的經驗。一個好的模式代表了某個問題研究的成果，因此我們把模式應用在架構設計上，能夠大大增強架構的穩定性。
抽象
架構的本質在于其抽象性。它包括兩個方面的抽象：業務抽象和技術抽象。架構是現實世界的一個模型，所以我們首先需要對現實世界有一個很深的了解，然后我們還要能夠熟練的應用技術來實現現實世界到模型的映射。因此，我們在對業務或技術理解不夠深入的情況下，就很難設計出好的架構。當然，這時候我們發現一個問題：怎樣才能算是理解足夠深入呢。我認為這沒有一個絕對的準則。
一次，一位朋友問我：他現在做的系統有很大的變化，原先設計的工作流架構不能滿足現在的要求。他很希望能夠設計出足夠好的工作流架構，以適應不同的變化。但是他發現這樣做無異于重新開發一個lotus notes。我聽了他的疑問之后覺得有兩點問題：
首先，他的開發團隊中并沒有工作流領域的專家。他的客戶雖然了解自己的工作流程，但是缺乏足夠的理論知識把工作流提到抽象的地步。顯然，他本身雖然有技術方面的才能，但就工作流業務本身，他也沒有足夠的經驗。所以，設計出象notes那樣的系統的前提條件并不存在。
其次，開發一個工作流系統的目的是什么。原先的工作流系統運作的不好，其原因是有變化發生。因此才有改進工作流系統的動機出現�？墒�，畢竟notes是為了滿足世界上所有的工作流系統而開發的，他目前的應用肯定達不到這個層次。
因此，雖然做不到最優的業務抽象，但是我們完全可以在特定目的下，特定范圍內做到最優的業務抽象。比如說，我們工作流可能的變化是工組流路徑的變化。我們就完全可以把工作流的路徑做一個抽象，設計一個可以動態改變路徑的工作流架構。
有些時候，我們雖然在技術上和業務上都有所欠缺，沒有辦法設計出好的架構。但是我們完全可以借鑒他人的經驗，看看類似的問題別人是如何解決的。這就是我們前面提到的模式。我們不要把模式看成是一個硬性的解決方法，它只是一種解決問題的思路。Martin Fowler曾說："模式和業務組件的區別就在于模式會引發你的思考。"
在《分析模式》一書中，Martin Fowler提到了分析和設計的區別。分析并不僅僅只是用用例列出所有的需求，分析還應該深入到表面需求的的背后，以得到關于問題本質的Mental Model。然后，他引出了概念模型的概念。概念模型就類似于我們在討論的抽象。Martin Fowler提到了一個有趣的例子，如果要開發一套軟件來模擬桌球游戲，那么，用用例來描述各種的需求，可能會導致大量的運動軌跡的出現。如果你沒有了解表面現象之后隱藏的運動定律的本質，你可能永遠無法開發出這樣一個系統。
關于架構和抽象的問題，在后面的文章中有一個測量模式的案例可以很形象的說明這個問題。
架構的一些誤解
我們花了一些篇幅來介紹架構的一些知識�，F在回到我們的另一個主題上來。對于一個敏捷開發過程，架構意味著什么，我們該如何面對架構。這里我們首先要澄清一些誤解：
誤解1：架構設計需要很強的技術能力。從某種程度來說，這句話并沒有很大的錯誤。畢竟，你的能力越強，設計出優秀架構的幾率也會上升。但是能力和架構設計之間并沒有一個很強的聯系。即使是普通的編程人員，他一樣有能力設計出能實現目標的架構。
誤解2：架構由專門的設計師來設計，設計出的藍圖交由程序員來實現。我們之所以會認為架構是設計師的工作，是因為我們喜歡把軟件開發和建筑工程做類比。但是，這兩者實際上是有著很大的區別的。關鍵之處在于，建筑設計已經有很長的歷史，已經發展出完善的理論，可以通過某些理論（如力學原理）來驗證設計藍圖�？墒�，對軟件開發而言，驗證架構設計的正確性，只能夠通過寫代碼來驗證。因此，很多看似完美的架構，往往在實現時會出現問題。
誤解3：在一開始就要設計出完善的架構。這種方式是最傳統的前期設計方式。這也是為XP所摒棄的一種設計方式。主要的原因是，在一開始設計出完美的架構根本就是在自欺欺人。因為這樣做的基本假設就是需求的不變性。但需求是沒有不變的（關于需求的細節討論，請參看拙作『需求的實踐』）。這樣做的壞處是，我們一開始就限制了整個的軟件的形狀。而到實現時，我們雖然發現原來的設計有失誤之處，但卻不愿意面對現實。這使得軟件畸形的生長。原本一些簡單的問題，卻因為別扭的架構，變得非常的復雜。這種例子我們經�？梢钥吹�，例如為兼容前個版本而導致的軟件復雜性。而2000年問題，TCP/IP網絡的安全性問題也從一個側面反映了這個問題的嚴重性。
誤解4：架構藍圖交給程序員之后，架構設計師的任務就完成了。和誤解2一樣，我們借鑒了建筑工程的經驗。我們看到建筑設計師把設計好的藍圖交給施工人員，施工人員就會按照圖紙建造出和圖紙一模一樣的大廈。于是，我們也企圖在軟件開發中使用這種模式。這是非常要命的。軟件開發中缺乏一種通用的語言，能夠充分的消除設計師和程序員的溝通隔閡。有人說，UML不可以嗎？UML的設計理念是好的，可以減輕溝通障礙問題�？墒且胪耆鉀Q這個問題，UML還做不到。首先，程序員都具有個性化的思維，他會以自己的思維方式去理解設計，因為從設計到實現并不是一項機械的勞動，還是屬于一項知識性的勞動（這和施工人員的工作是不同的）。此外，對于程序員來說，他還極有可能按照自己的想法對設計圖進行一定的修改，這是非常正常的一項舉動。更糟的是，程序員往往都比較自負，他們會潛意識的排斥那些未經過自己認同的設計。
架構設計的過程模式
通常我們認為模式都是用在軟件開發、架構設計上的。其實，這只是模式的一個方面。模式的定義告訴我們，模式描述了一個特定環境的解決方法，這個特定環境往往重復出現，制定出一個較好的解決方法有利于我們在未來能有效的解決類似的問題。其實，在管理學上，也存在這種類似的這種思維。稱為結構性問題的程序化解決方法。所以呢，我們完全可以把模式的思想用在其它的方面，而目前最佳的運用就是過程模式和組織模式。在我們的文章中，我們僅限于討論過程模式。
我們討論的過程僅限于面向對象的軟件開發過程。我們稱之為OOSP（object-oriented software process ）。因為我們的過程需要面向對象特性的支持。當然，我們的很多做法一樣可以用在非OO的開發過程中，但是為了達到最佳的效果，我建議您使用OO技術。
那么，我們應該如何避開這些誤區呢，或者，換句話說，敏捷軟件開發是如何做架構設計的。這里有幾種過程模式：
圖 2. 敏捷架構過程模式概覽（High-Level）
在接下去的篇幅中，我們會逐一對各種過程模式進行介紹。然后再站在全局的角度分析各個模式之間的關系，并將之歸納為架構設計的模式。
敏捷型架構設計
我們說我們這里列出的過程模式是敏捷型的，關于這一點我們會在接下去的各個章節中驗證這一點。我們列出的各個過程模式并不是完全照搬敏捷型方法，因為在各種敏捷型方法中，某些技巧適合架構設計，某些方法則不適合架構設計。因此，我們在采用一種方法和技術前，我們會問自己幾個簡單的問題：
該方法/技巧有什么價值？
該方法/技巧需要多大的投入？從創建、維護、培訓等多方面估計。
比較該方法/技巧的投入和價值，它還值得我們采用嗎？
是否還有其它價值/投入比更高的方法/技巧呢？
在我們的文章中，每一種方法/技巧的討論都回答了前三個問題，至于第四個問題，希望有同行能夠告訴我。
(待續)
作者簡介：
林星，辰訊軟件工作室項目管理組資深項目經理，有多年項目實施經驗。辰訊軟件工作室致力于先進軟件思想、軟件技術的應用，主要的研究方向在于軟件過程思想、Linux集群技術、OO技術和軟件工廠模式。您可以通過電子郵件 iamlinx@21cn.com 和他聯系。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
