敏捷思維－ 架構設計中的方法學(xué)(7)

組合使用模式

級別: 初級

林星, 項目經(jīng)理, 辰訊軟件工作室

2003 年 3 月 01 日

我們已經(jīng)討論了敏捷架構設計的4種過(guò)程模式，在這一章中，我們對這四種過(guò)程模式做一個(gè)小結，并討論4者間的關(guān)系以及體現在模式中的敏捷方法論特色。通過(guò)這一章的描述，大家能夠對前面的內容有更進(jìn)一步的了解。

四種模式的著(zhù)重點(diǎn)

我把源自需求、團隊設計、簡(jiǎn)單設計、迭代設計這4種過(guò)程模式歸類(lèi)為架構設計的第一層次，這4種模式能夠確定架構設計過(guò)程的框架。這里需要對框架的含義進(jìn)行澄清：架構設計的框架并不是說(shuō)你要嚴格的按照文中介紹的內容來(lái)進(jìn)行架構設計，在文章的一開(kāi)始我們就指出，模式能夠激發(fā)思考。因此，這一框架是需要結合實(shí)際，進(jìn)行改造的。實(shí)際，我們在這一個(gè)部分中介紹的，比較偏向于原則，我們花了很大的時(shí)間來(lái)討論原則的來(lái)龍去脈，而原則的度，則要大家自己去把握。為什么我們不討論原則的度呢？這里有兩個(gè)原因，一個(gè)是軟件開(kāi)發(fā)團隊各有特色，很難定義出一個(gè)通用的度。第二個(gè)原因是我的水平不夠，實(shí)踐經(jīng)驗也不夠豐富。

前面提到的四種模式其實(shí)是從四個(gè)側面討論了架構設計中的方法問(wèn)題。源自需求提供了架構設計的基礎。在軟件過(guò)程中，架構設計是承接于需求分析的，如果沒(méi)有良好的需求分析活動(dòng)的支持，再好的架構設計也沒(méi)有用。因此我們把這一模式放在首位，做為架構設計的目標。

有了確定的目標，還需有組織的保證，這也就是第二種模式――團隊設計的由來(lái)。敏捷方法提倡優(yōu)秀的溝通，因此團隊設計是必要且有效的。而團隊設計的另一個(gè)意圖，是保證架構設計的下游活動(dòng)得以順利的進(jìn)行，例如詳細設計、編碼、測試等。由于開(kāi)發(fā)團隊中的人大都加入了架構設計，因此最大程度的減小了不同的活動(dòng)間的信息損耗和溝通效率低下的問(wèn)題。如果說(shuō)源自需求模式是起承上的作用，那么團隊設計模式則是扮演了啟下的角色。

在軟件設計的過(guò)程中，溝通往往扮演著(zhù)非常重要的角色。從團隊設計開(kāi)始的幾種模式所要解決的都是溝通的問(wèn)題。團隊設計對溝通的貢獻在于它能夠把設計意圖以最小的代價(jià)傳播到開(kāi)發(fā)團隊的每個(gè)角落。這樣，設計和下游的活動(dòng)間由于溝通不暢產(chǎn)生的問(wèn)題就能夠得到緩解。一般而言，設計到編碼會(huì )經(jīng)歷一個(gè)信息損失的過(guò)程，編碼人員無(wú)法正確理解設計人員的意圖，設計人員卻往往無(wú)法考慮到一些編碼的細節。雖然我們可以通過(guò)共通的設計符號來(lái)提高溝通的質(zhì)量，例如UML。但是實(shí)踐證明，只要能夠保證暢通的溝通，即便沒(méi)有優(yōu)秀的開(kāi)發(fā)方法，項目成功的概率依然很高。因此對于單個(gè)的項目來(lái)說(shuō)，最關(guān)鍵的問(wèn)題還是在于溝通。只要組織得當，團隊設計是一個(gè)值得應用的模式。當然，配合以UML為代表的建模語(yǔ)言，更能夠提高溝通的效果。

在設計中，我們發(fā)現，當設計信息轉換為編碼信息需要一定的時(shí)間，這個(gè)時(shí)間包括設計的組織時(shí)間，設計被理解的時(shí)間。如果設計比較復雜，或者說(shuō)設計的文檔比較復雜，編碼人員花在理解上的時(shí)間就會(huì )大大增加。因此，權衡后的結果是，相對于詳細的設計說(shuō)明書(shū)而言，簡(jiǎn)單的設計說(shuō)明書(shū)再配合一定程度的面對面溝通能夠起到更好的效果。"簡(jiǎn)單要比復雜有效"，這就是簡(jiǎn)單設計模式的基本思路。

同樣，簡(jiǎn)單的思路還會(huì )用在軟件開(kāi)發(fā)的各個(gè)方面，例如文檔、設計、流程。堅持簡(jiǎn)單的原則，并不斷的加以改進(jìn)，是降低軟件開(kāi)發(fā)成本的一種很有效的做法。

在有了以上的思路之后，我們還需要面對兩個(gè)現實(shí)的問(wèn)題。需求的變化將會(huì )導致設計的不穩定，而需求的復雜性又會(huì )導致簡(jiǎn)單架構設計的困難。為了解決這個(gè)問(wèn)題，我們引入了迭代的方法，將問(wèn)題分割為多個(gè)子問(wèn)題（把一個(gè)復雜的問(wèn)題分解為多個(gè)較簡(jiǎn)單的子問(wèn)題是計算機領(lǐng)域最常見(jiàn)的處理方法）。這樣，問(wèn)題的范圍和難度都大大降低了。而更關(guān)鍵的是，由于對用戶(hù)需求理解不充分或用戶(hù)表達需求有錯導致的設計風(fēng)險被降到最低點(diǎn)。迭代和前面幾個(gè)模式都有關(guān)系。

需求和迭代

源自需求模式是架構設計中的起手式，沒(méi)有這一模式的支持，架構設計只能是空中樓閣。其實(shí)，源自需求模式嚴格意義上并不能算是敏捷方法論的特色，而應該算是軟件開(kāi)發(fā)的天然特性。不幸的是，就是這么一個(gè)基本的原則，卻沒(méi)能夠引起開(kāi)發(fā)者足夠的重視。

敏捷方法論中把需求擺在一個(gè)非常重要的位置，我們把源自需求模式作為架構設計的第一個(gè)模式，主要的目的是承接架構設計的上游工作――需求。需求決定架構，因此，我們在經(jīng)典的瀑布模型中可以看到需求到設計的嚴格的分界線(xiàn)，但是在實(shí)際的開(kāi)發(fā)中，按照瀑布模型的理論往往會(huì )遇到很多的問(wèn)題，所以，我們嘗試著(zhù)把需求和（架構）設計之間的界限打破，形成一個(gè)重疊的地帶，從而提高軟件開(kāi)發(fā)的速度。因此，我們在源自需求模型中指出，架構設計是緊隨著(zhù)需求開(kāi)始的。

需求對軟件開(kāi)發(fā)最具影響就是需求的不穩定性。我們都非常的清楚軟件開(kāi)發(fā)的曲線(xiàn)，越到軟件開(kāi)發(fā)的后期，修改軟件的成本越高。因此，在軟件開(kāi)發(fā)上游的需求的變動(dòng)將會(huì )對軟件開(kāi)發(fā)的下游產(chǎn)生天翻地覆的影響。為了協(xié)調這一矛盾，軟工理論提出了螺旋開(kāi)發(fā)模型，這就是我們在迭代開(kāi)發(fā)模式中的討論的理論基礎。把軟件開(kāi)發(fā)過(guò)程分為多個(gè)的迭代周期，每一次的迭代周期最后都將生成一個(gè)可交付的軟件，用戶(hù)在每一次的迭代結束后，可以試用軟件，提出下一步的需求或是改變原先的需求。通過(guò)這樣的方式，把客戶(hù)、開(kāi)發(fā)商的風(fēng)險降到一個(gè)可以接受的水平上。

請注意迭代的前提：需求的易變性。因此，對于那些需求容易發(fā)生變化的項目，我們就可以使用迭代式的開(kāi)發(fā)過(guò)程，雖然我們會(huì )付出一些額外的成本（剛開(kāi)始這個(gè)成本會(huì )比較大，但可以用較長(cháng)的迭代周期來(lái)降低這種成本），但是風(fēng)險減小了。而對于需求比較固定的項目，是不是有必要使用迭代的方法，就要看具體的環(huán)境了。因此，我們是根據實(shí)際的情況選用開(kāi)發(fā)方法，而不是因為先進(jìn)或是流行的原因。

實(shí)際上，由于現代社會(huì )的特性，大部分的項目都是可以采用迭代方法。因此，我們的選擇就變成了了迭代周期應該要多長(cháng)。迭代周期在理論上應該是越短越好，但是并沒(méi)有一個(gè)絕對的數值，時(shí)間的跨度一般從幾周到幾個(gè)月。一般來(lái)說(shuō)，迭代周期會(huì )受到幾個(gè)因素的影響：

• 各模塊的關(guān)聯(lián)程度。在軟件開(kāi)發(fā)中，我們有時(shí)候很難把一些模塊分離開(kāi)來(lái)，要開(kāi)發(fā)模塊A，就需要模塊B，而模塊B又需要模塊C。各模塊的關(guān)聯(lián)程度越高，迭代周期越長(cháng)。當然，也相應的解決方法，我們可以在各模塊的功能中選取出一些關(guān)鍵點(diǎn)，作為里程碑，以里程碑作為迭代完成點(diǎn)。
• 人員技能、經(jīng)驗的平均程度。團隊中成員的開(kāi)發(fā)能力、開(kāi)發(fā)經(jīng)驗良莠不齊，這也是造成迭代周期延長(cháng)的一個(gè)原因。能力低、經(jīng)驗少的開(kāi)發(fā)人員會(huì )拖后每一次迭代的時(shí)間。針對這種情況，做好統籌規劃就顯得非常的重要，可以通過(guò)一兩次的迭代，找出隊伍中的瓶頸人員，安排相應的對策。
• 工具的缺乏。迭代周期越短，就意味著(zhù)build、發(fā)布的次數越多，客戶(hù)也就有更多的機會(huì )來(lái)修改需求。這要求有相關(guān)的工具來(lái)幫助開(kāi)發(fā)人員控制軟件。最重要的工具是回歸測試工具。每一次迭代都需要增加新的功能，或是對原先的功能進(jìn)行改動(dòng)，這就有可能引入新的bug，如果沒(méi)有回歸測試，開(kāi)發(fā)人員就需要花費時(shí)間重新測試原先的功能。
• 計劃、控制的能力。迭代周期越短，所需要的計劃、控制的能力就越強。因為短時(shí)間內的計劃制定和實(shí)施需要高度的細分，這就要求開(kāi)發(fā)團隊的管理者對開(kāi)發(fā)能力、工作量、任務(wù)分配有很強的認識，才能做好這項工作。不過(guò)，迭代周期越短，同樣開(kāi)發(fā)時(shí)間的迭代次數就越多，而團隊調整、改進(jìn)計劃控制的機會(huì )就越多。因此，后期的迭代一般都能夠做到比較精確的控制。而這樣的做法，要比問(wèn)題堆積到軟件交付日才爆發(fā)出來(lái)要好的多。沒(méi)有突然落后的軟件，只有每天都在落后的軟件。

簡(jiǎn)單和迭代

簡(jiǎn)單和迭代關(guān)系是雙向的。

在現實(shí)設計我們很難界定出簡(jiǎn)單設計的程度。怎樣的架構設計才算是簡(jiǎn)單？按照我們在簡(jiǎn)單設計模式中的討論，剛好滿(mǎn)足目前的需求的架構設計就算是簡(jiǎn)單的設計。但是，從另外一個(gè)方面考慮，需求的易變性限制我們做出簡(jiǎn)單的設計，因為我們不能夠肯定目前的需求將來(lái)會(huì )發(fā)生什么樣的變化。因此，為了克服對未知的恐懼，我們花了很大的力氣設計一些靈活的、能夠適應變化的架構。這是源自需求模式對簡(jiǎn)單設計模式的影響。

源自需求和迭代設計的關(guān)系的討論建議我們把需求分為多個(gè)迭代周期來(lái)實(shí)現。那么，相應的架構設計也被分在多個(gè)迭代周期中。這樣的方法可以降低架構設計的復雜程度。因為設計人員不需要考慮軟件的全部需求，而只需要考慮當前迭代周期的需求。復雜性的降低將會(huì )有助于架構設計的簡(jiǎn)單化，從而達到簡(jiǎn)單設計的一系列的好處（參見(jiàn)簡(jiǎn)單設計）。

我們從迭代設計中的最后一個(gè)例子可以清楚的看到迭代設計是如何把復雜的需求給簡(jiǎn)單化的。把握迭代設計有助于我們避免過(guò)分設計的毛病。這是個(gè)技術(shù)人員經(jīng)常犯的毛病。我所在的團隊很多時(shí)候也無(wú)法避免。例如，在很多的項目中，我們都會(huì )花費大量的時(shí)間來(lái)設計數據庫到業(yè)務(wù)實(shí)體的映射。諸如此類(lèi)的技術(shù)問(wèn)題對開(kāi)發(fā)人員的吸引程度是不言而喻的，但是必須看到，這種的設計會(huì )導致開(kāi)發(fā)成本的大幅度上升。更為糟糕的是，除非有豐富的經(jīng)驗，這種類(lèi)型的設計給開(kāi)發(fā)工作帶來(lái)的價(jià)值往往無(wú)法超過(guò)其成本。

因此，我們需要學(xué)會(huì )權衡利弊，是否有必要投入大量的資源來(lái)開(kāi)發(fā)其實(shí)并沒(méi)有那么有用的功能。因此，迭代設計和簡(jiǎn)單設計的結合有助于我們擺脫過(guò)度設計的困擾，把精力集中在真正重要的功能之上。

此外，簡(jiǎn)單的設計并不等同于較少的付出。簡(jiǎn)單的設計往往需要對現實(shí)世界的抽象，回憶我們在簡(jiǎn)單設計中討論的測量模式的例子，它看似簡(jiǎn)單，但實(shí)現起來(lái)卻需要大量的業(yè)務(wù)知識、很強的設計能力。因此，做到簡(jiǎn)單是程序員不斷追尋的目標之一。

在很多的方法論中，一般并不過(guò)分注意代碼重復的問(wèn)題，要么是不關(guān)注，要么認為適當的代碼重復是允許的。而XP卻把代碼重復視為良好代碼的大敵。"只要存在重復代碼，就說(shuō)明代碼仍有Refactoring的可能。"這種觀(guān)點(diǎn)看起來(lái)非常的絕對，這可能也正是其名字中Extreme的來(lái)歷（英文中的Extreme屬于語(yǔ)氣非常重的一個(gè)單詞）。從實(shí)踐的角度上來(lái)看，追求不重復的代碼雖然很難做到，但是其過(guò)程卻可以有效的提高開(kāi)發(fā)團隊代碼的寫(xiě)作質(zhì)量，因為它逼迫著(zhù)你在每次迭代重對代碼進(jìn)行改進(jìn)，不能有絲毫的怠惰。而這種迭代的特性，促進(jìn)了簡(jiǎn)單的實(shí)現。

團隊和簡(jiǎn)單

我們在簡(jiǎn)單設計中提過(guò)簡(jiǎn)單設計需要全面的設計師。除此之外，它還需要團隊的配合。簡(jiǎn)單意味著(zhù)不同活動(dòng)間交付工件的簡(jiǎn)單化。也就是說(shuō)，類(lèi)似于需求說(shuō)明書(shū)、設計文檔之類(lèi)的東西都將會(huì )比較簡(jiǎn)單。正因為如此，我們很難想象一個(gè)地理上分布在不同地點(diǎn)的開(kāi)發(fā)團隊或一個(gè)超過(guò)50人的大團隊能夠利用這種簡(jiǎn)單的文檔完成開(kāi)發(fā)任務(wù)。

因此，簡(jiǎn)單的設計是需要團隊的組織結構來(lái)保證的。簡(jiǎn)單的設計要求團隊的相互溝通能夠快速的進(jìn)行。架構設計完成后，架構的設計思路傳達給所有的編碼人員的速度要塊，同樣，編碼中發(fā)現問(wèn)題，回饋給設計者，設計者經(jīng)過(guò)改進(jìn)之后再傳達給收到影響的編碼人員的速度也要快。象這樣高效率的傳播我們可以稱(chēng)之為"Hot Channel"。

為了保證"Hot Channel"的高溝通效率，最好的組織單位是開(kāi)發(fā)人員在3到6人之間，并處于同間工作室中。這樣的結構可以保證訊息的交互速度達到最高，不需要付出額外的溝通成本，也不需要過(guò)于復雜的版本控制工具或權限分配。根據我的經(jīng)驗，一個(gè)共享式的小型版本控制工具、網(wǎng)絡(luò )共享、再加上一個(gè)簡(jiǎn)單的網(wǎng)絡(luò )數據庫就能夠解決大部分的問(wèn)題了。

在理論上，我們說(shuō)只要分配得當，大型的團隊同樣可以組織為金字塔式的子團隊，以提高大型團隊的工作效率。但是實(shí)際中，隨著(zhù)團隊的人數的增加，任務(wù)的正確分配的難度也隨之加大，溝通信息上傳下達的效率開(kāi)始下降，子團隊間的隔閡開(kāi)始出現，各種因素的累加導致敏捷方法并不一定適合于大型的團隊，因此我們討論的敏捷方法都將受到團隊的特性的限制。

模式的源頭

如果你對XP有一定的了解的話(huà)，那么你可能會(huì )感覺(jué)到我們討論的模式中應用了XP的實(shí)踐。確實(shí)如此，XP中有很多優(yōu)秀的實(shí)踐，如果組織得當的話(huà)，這些微小的實(shí)踐將會(huì )組合成為一套了不起的開(kāi)發(fā)方法。不過(guò)，目前的軟件開(kāi)發(fā)混亂的現狀阻止了先進(jìn)的軟件方法的應用，對一個(gè)身體虛弱的病人施以補藥只會(huì )適得其反。因此，在前面討論的模式中，我們應用了一些容易應用、效果明顯的實(shí)踐方法。在實(shí)踐中適當的應用這些方法，并不需要額外的投入，卻能夠有很好的效果，同時(shí)還會(huì )為你的團隊打下一個(gè)良好的基礎。