四種模式的著重點
我把源自需求、團隊設計、簡單設計、迭代設計這4種過程模式歸類為架構設計的第一層次，這4種模式能夠確定架構設計過程的框架。這里需要對框架的含義進行澄清：架構設計的框架并不是說你要嚴格的按照文中介紹的內容來進行架構設計，在文章的一開始我們就指出，模式能夠激發思考。因此，這一框架是需要結合實際，進行改造的。實際，我們在這一個部分中介紹的，比較偏向于原則，我們花了很大的時間來討論原則的來龍去脈，而原則的度，則要大家自己去把握。為什么我們不討論原則的度呢？這里有兩個原因，一個是軟件開發團隊各有特色，很難定義出一個通用的度。第二個原因是我的水平不夠，實踐經驗也不夠豐富。
前面提到的四種模式其實是從四個側面討論了架構設計中的方法問題。源自需求提供了架構設計的基礎。在軟件過程中，架構設計是承接于需求分析的，如果沒有良好的需求分析活動的支持，再好的架構設計也沒有用。因此我們把這一模式放在首位，做為架構設計的目標。
有了確定的目標，還需有組織的保證，這也就是第二種模式――團隊設計的由來。敏捷方法提倡優秀的溝通，因此團隊設計是必要且有效的。而團隊設計的另一個意圖，是保證架構設計的下游活動得以順利的進行，例如詳細設計、編碼、測試等。由于開發團隊中的人大都加入了架構設計，因此最大程度的減小了不同的活動間的信息損耗和溝通效率低下的問題。如果說源自需求模式是起承上的作用，那么團隊設計模式則是扮演了啟下的角色。
在軟件設計的過程中，溝通往往扮演著非常重要的角色。從團隊設計開始的幾種模式所要解決的都是溝通的問題。團隊設計對溝通的貢獻在于它能夠把設計意圖以最小的代價傳播到開發團隊的每個角落。這樣，設計和下游的活動間由于溝通不暢產生的問題就能夠得到緩解。一般而言，設計到編碼會經歷一個信息損失的過程，編碼人員無法正確理解設計人員的意圖，設計人員卻往往無法考慮到一些編碼的細節。雖然我們可以通過共通的設計符號來提高溝通的質量，例如UML。但是實踐證明，只要能夠保證暢通的溝通，即便沒有優秀的開發方法，項目成功的概率依然很高。因此對于單個的項目來說，最關鍵的問題還是在于溝通。只要組織得當，團隊設計是一個值得應用的模式。當然，配合以UML為代表的建模語言，更能夠提高溝通的效果。
在設計中，我們發現，當設計信息轉換為編碼信息需要一定的時間，這個時間包括設計的組織時間，設計被理解的時間。如果設計比較復雜，或者說設計的文檔比較復雜，編碼人員花在理解上的時間就會大大增加。因此，權衡后的結果是，相對于詳細的設計說明書而言，簡單的設計說明書再配合一定程度的面對面溝通能夠起到更好的效果。"簡單要比復雜有效"，這就是簡單設計模式的基本思路。
同樣，簡單的思路還會用在軟件開發的各個方面，例如文檔、設計、流程。堅持簡單的原則，并不斷的加以改進，是降低軟件開發成本的一種很有效的做法。
在有了以上的思路之后，我們還需要面對兩個現實的問題。需求的變化將會導致設計的不穩定，而需求的復雜性又會導致簡單架構設計的困難。為了解決這個問題，我們引入了迭代的方法，將問題分割為多個子問題（把一個復雜的問題分解為多個較簡單的子問題是計算機領域最常見的處理方法）。這樣，問題的范圍和難度都大大降低了。而更關鍵的是，由于對用戶需求理解不充分或用戶表達需求有錯導致的設計風險被降到最低點。迭代和前面幾個模式都有關系。
需求和迭代
源自需求模式是架構設計中的起手式，沒有這一模式的支持，架構設計只能是空中樓閣。其實，源自需求模式嚴格意義上并不能算是敏捷方法論的特色，而應該算是軟件開發的天然特性。不幸的是，就是這么一個基本的原則，卻沒能夠引起開發者足夠的重視。
敏捷方法論中把需求擺在一個非常重要的位置，我們把源自需求模式作為架構設計的第一個模式，主要的目的是承接架構設計的上游工作――需求。需求決定架構，因此，我們在經典的瀑布模型中可以看到需求到設計的嚴格的分界線，但是在實際的開發中，按照瀑布模型的理論往往會遇到很多的問題，所以，我們嘗試著把需求和（架構）設計之間的界限打破，形成一個重疊的地帶，從而提高軟件開發的速度。因此，我們在源自需求模型中指出，架構設計是緊隨著需求開始的。
需求對軟件開發最具影響就是需求的不穩定性。我們都非常的清楚軟件開發的曲線，越到軟件開發的后期，修改軟件的成本越高。因此，在軟件開發上游的需求的變動將會對軟件開發的下游產生天翻地覆的影響。為了協調這一矛盾，軟工理論提出了螺旋開發模型，這就是我們在迭代開發模式中的討論的理論基礎。把軟件開發過程分為多個的迭代周期，每一次的迭代周期最后都將生成一個可交付的軟件，用戶在每一次的迭代結束后，可以試用軟件，提出下一步的需求或是改變原先的需求。通過這樣的方式，把客戶、開發商的風險降到一個可以接受的水平上。
請注意迭代的前提：需求的易變性。因此，對于那些需求容易發生變化的項目，我們就可以使用迭代式的開發過程，雖然我們會付出一些額外的成本（剛開始這個成本會比較大，但可以用較長的迭代周期來降低這種成本），但是風險減小了。而對于需求比較固定的項目，是不是有必要使用迭代的方法，就要看具體的環境了。因此，我們是根據實際的情況選用開發方法，而不是因為先進或是流行的原因。
實際上，由于現代社會的特性，大部分的項目都是可以采用迭代方法。因此，我們的選擇就變成了了迭代周期應該要多長。迭代周期在理論上應該是越短越好，但是并沒有一個絕對的數值，時間的跨度一般從幾周到幾個月。一般來說，迭代周期會受到幾個因素的影響：
各模塊的關聯程度。在軟件開發中，我們有時候很難把一些模塊分離開來，要開發模塊A，就需要模塊B，而模塊B又需要模塊C。各模塊的關聯程度越高，迭代周期越長。當然，也相應的解決方法，我們可以在各模塊的功能中選取出一些關鍵點，作為里程碑，以里程碑作為迭代完成點。
人員技能、經驗的平均程度。團隊中成員的開發能力、開發經驗良莠不齊，這也是造成迭代周期延長的一個原因。能力低、經驗少的開發人員會拖后每一次迭代的時間。針對這種情況，做好統籌規劃就顯得非常的重要，可以通過一兩次的迭代，找出隊伍中的瓶頸人員，安排相應的對策。
工具的缺乏。迭代周期越短，就意味著build、發布的次數越多，客戶也就有更多的機會來修改需求。這要求有相關的工具來幫助開發人員控制軟件。最重要的工具是回歸測試工具。每一次迭代都需要增加新的功能，或是對原先的功能進行改動，這就有可能引入新的bug，如果沒有回歸測試，開發人員就需要花費時間重新測試原先的功能。
計劃、控制的能力。迭代周期越短，所需要的計劃、控制的能力就越強。因為短時間內的計劃制定和實施需要高度的細分，這就要求開發團隊的管理者對開發能力、工作量、任務分配有很強的認識，才能做好這項工作。不過，迭代周期越短，同樣開發時間的迭代次數就越多，而團隊調整、改進計劃控制的機會就越多。因此，后期的迭代一般都能夠做到比較精確的控制。而這樣的做法，要比問題堆積到軟件交付日才爆發出來要好的多。沒有突然落后的軟件，只有每天都在落后的軟件。
簡單和迭代
簡單和迭代關系是雙向的。
在現實設計我們很難界定出簡單設計的程度。怎樣的架構設計才算是簡單？按照我們在簡單設計模式中的討論，剛好滿足目前的需求的架構設計就算是簡單的設計。但是，從另外一個方面考慮，需求的易變性限制我們做出簡單的設計，因為我們不能夠肯定目前的需求將來會發生什么樣的變化。因此，為了克服對未知的恐懼，我們花了很大的力氣設計一些靈活的、能夠適應變化的架構。這是源自需求模式對簡單設計模式的影響。
源自需求和迭代設計的關系的討論建議我們把需求分為多個迭代周期來實現。那么，相應的架構設計也被分在多個迭代周期中。這樣的方法可以降低架構設計的復雜程度。因為設計人員不需要考慮軟件的全部需求，而只需要考慮當前迭代周期的需求。復雜性的降低將會有助于架構設計的簡單化，從而達到簡單設計的一系列的好處（參見簡單設計）。
我們從迭代設計中的最后一個例子可以清楚的看到迭代設計是如何把復雜的需求給簡單化的。把握迭代設計有助于我們避免過分設計的毛病。這是個技術人員經常犯的毛病。我所在的團隊很多時候也無法避免。例如，在很多的項目中，我們都會花費大量的時間來設計數據庫到業務實體的映射。諸如此類的技術問題對開發人員的吸引程度是不言而喻的，但是必須看到，這種的設計會導致開發成本的大幅度上升。更為糟糕的是，除非有豐富的經驗，這種類型的設計給開發工作帶來的價值往往無法超過其成本。
因此，我們需要學會權衡利弊，是否有必要投入大量的資源來開發其實并沒有那么有用的功能。因此，迭代設計和簡單設計的結合有助于我們擺脫過度設計的困擾，把精力集中在真正重要的功能之上。
此外，簡單的設計并不等同于較少的付出。簡單的設計往往需要對現實世界的抽象，回憶我們在簡單設計中討論的測量模式的例子，它看似簡單，但實現起來卻需要大量的業務知識、很強的設計能力。因此，做到簡單是程序員不斷追尋的目標之一。
在很多的方法論中，一般并不過分注意代碼重復的問題，要么是不關注，要么認為適當的代碼重復是允許的。而XP卻把代碼重復視為良好代碼的大敵。"只要存在重復代碼，就說明代碼仍有Refactoring的可能。"這種觀點看起來非常的絕對，這可能也正是其名字中Extreme的來歷（英文中的Extreme屬于語氣非常重的一個單詞）。從實踐的角度上來看，追求不重復的代碼雖然很難做到，但是其過程卻可以有效的提高開發團隊代碼的寫作質量，因為它逼迫著你在每次迭代重對代碼進行改進，不能有絲毫的怠惰。而這種迭代的特性，促進了簡單的實現。
團隊和簡單
我們在簡單設計中提過簡單設計需要全面的設計師。除此之外，它還需要團隊的配合。簡單意味著不同活動間交付工件的簡單化。也就是說，類似于需求說明書、設計文檔之類的東西都將會比較簡單。正因為如此，我們很難想象一個地理上分布在不同地點的開發團隊或一個超過50人的大團隊能夠利用這種簡單的文檔完成開發任務。
因此，簡單的設計是需要團隊的組織結構來保證的。簡單的設計要求團隊的相互溝通能夠快速的進行。架構設計完成后，架構的設計思路傳達給所有的編碼人員的速度要塊，同樣，編碼中發現問題，回饋給設計者，設計者經過改進之后再傳達給收到影響的編碼人員的速度也要快。象這樣高效率的傳播我們可以稱之為"Hot Channel"。
為了保證"Hot Channel"的高溝通效率，最好的組織單位是開發人員在3到6人之間，并處于同間工作室中。這樣的結構可以保證訊息的交互速度達到最高，不需要付出額外的溝通成本，也不需要過于復雜的版本控制工具或權限分配。根據我的經驗，一個共享式的小型版本控制工具、網絡共享、再加上一個簡單的網絡數據庫就能夠解決大部分的問題了。
在理論上，我們說只要分配得當，大型的團隊同樣可以組織為金字塔式的子團隊，以提高大型團隊的工作效率。但是實際中，隨著團隊的人數的增加，任務的正確分配的難度也隨之加大，溝通信息上傳下達的效率開始下降，子團隊間的隔閡開始出現，各種因素的累加導致敏捷方法并不一定適合于大型的團隊，因此我們討論的敏捷方法都將受到團隊的特性的限制。
模式的源頭
如果你對XP有一定的了解的話，那么你可能會感覺到我們討論的模式中應用了XP的實踐。確實如此，XP中有很多優秀的實踐，如果組織得當的話，這些微小的實踐將會組合成為一套了不起的開發方法。不過，目前的軟件開發混亂的現狀阻止了先進的軟件方法的應用，對一個身體虛弱的病人施以補藥只會適得其反。因此，在前面討論的模式中，我們應用了一些容易應用、效果明顯的實踐方法。在實踐中適當的應用這些方法，并不需要額外的投入，卻能夠有很好的效果，同時還會為你的團隊打下一個良好的基礎。
(待續)
作者簡介：
林星，辰訊軟件工作室項目管理組資深項目經理，有多年項目實施經驗。辰訊軟件工作室致力于先進軟件思想、軟件技術的應用，主要的研究方向在于軟件過程思想、Linux集群技術、OO技術和軟件工廠模式。您可以通過電子郵件 iamlinx@21cn.com 和他聯系。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
