為了理解敏捷和架構(gòu)的關(guān)系，我們繼續(xù)討論第1部分曾經(jīng)討論的3個主要的方法：XP、Scrum和RUP。

1,極限編程：架構(gòu)形成

XP是以程序員為中心的開發(fā)，其中沒有一個核心實踐明確討論了軟件架構(gòu)，然而，這并不是說XP項目和XP團(tuán)隊不用或不理解架構(gòu)在軟件開發(fā)中的作用。Beck［2000］提到：“架構(gòu)在XP項目中和在其他軟件項目中一樣重要”。因此，我們在概念上從XP方法入手是一個好的開端。接著Beck繼續(xù)解釋架構(gòu)是如何形成的。

首次迭代，先挑選一些簡單的和基本的故事，這些故事可以支持你創(chuàng)建整個架構(gòu)。接下來，縮小范圍，用最簡單有效的方法實現(xiàn)這些故事。這個過程一旦結(jié)束，你就擁有了架構(gòu)。

這些評論在XP的視角上提供了附加的解釋。如果一個范圍適度的系統(tǒng)，通過少量故事的一兩次迭代展現(xiàn)出一個合理的架構(gòu)基線，那么這種方法可能非常有效，使用這種模型就可能形成相當(dāng)好的架構(gòu)。并且，由于XP主要被推薦和應(yīng)用于小團(tuán)隊，其有關(guān)團(tuán)隊大小和架構(gòu)策略的觀點是一致的。

此外，如果時間證明形成的系統(tǒng)架構(gòu)不能支持系統(tǒng)繼續(xù)演化，那么系統(tǒng)也可以較快地改寫或者重構(gòu)。事實上，重構(gòu)代碼是XP這個快速開發(fā)方法的關(guān)鍵組成部分，也是XP的特色。正如Beck［2000］所提到的：XP熱中于重做，而不是減少重做的頻率。對XP程序員來說，沒有重構(gòu)的日子就像沒有陽光的日子一樣。

在一個重構(gòu)課堂上，Highsmith講述了一個敏捷項目第一次發(fā)布的情況，項目是由一個10人小團(tuán)隊花費了大約7個月的時間后交付的。這次交付足以使公司在一個新興市場穩(wěn)坐頭把交椅，并通過產(chǎn)品用戶的客觀反饋，更好地理解產(chǎn)品到底需要做什么。Highsmith接著講述了一個大約60天的重構(gòu)階段，團(tuán)隊重新改寫了系統(tǒng)以前實現(xiàn)的一個重要部分，把這部分加入到更好的結(jié)構(gòu)基線中，并實現(xiàn)了新出現(xiàn)的需求。

由于僅花費兩個月來重新開發(fā)系統(tǒng)，嘗試早期交付過程的確是獲取需求和形成架構(gòu)的高效方法，并且能夠很快推出滿足新興市場需求的產(chǎn)品，而盡早交付是XP方法的基本原則。因此，該重構(gòu)模型在此環(huán)境中非常有效。

2, Scrum

我們在第1部分中提到，Scrum是一個敏捷軟件項目管理過程，其特征是面向團(tuán)隊和授權(quán)、固定周期的評審和調(diào)整，以及驅(qū)動組織變更以實現(xiàn)提高軟件生產(chǎn)率的目標(biāo)的過程。

雖然Scrum并沒有描述軟件工程實踐本身，[9]但是許多Scrum領(lǐng)導(dǎo)者認(rèn)為XP是合適的開發(fā)過程，并且許多Scrum主管推薦把XP作為Scrum的同伴過程。例如，Sutherland［2005b］在PatientKeeper公司把XP實踐應(yīng)用于系統(tǒng)開發(fā)，以及Scrum和高級Scrum持續(xù)改進(jìn)中。此外，Scrum中的３個角色（開發(fā)者，產(chǎn)品主管和Scrum主管）都不承擔(dān)特定的架構(gòu)職責(zé)。相反，Scrum依賴于一條久經(jīng)考驗的敏捷宣言原則“最好的架構(gòu)、需求和設(shè)計來自于自組織的團(tuán)隊”。因此，正如其言，Scrum沒有多少關(guān)于軟件架構(gòu)的內(nèi)容，我們需要在其他地方尋找敏捷架構(gòu)指南。

3,在FDD中的架構(gòu)

我們在第6章中提到，域?qū)ο蠼Ｊ荈DD 8個最佳實踐之一（其他7個是按特征開發(fā)、私有代碼所有權(quán)、特征團(tuán)隊、審查、定期構(gòu)建、配置管理和結(jié)果的可視化）。域?qū)ο蠼Ｊ俏ㄒ簧婕跋到y(tǒng)架構(gòu)的最佳實踐，這樣，域?qū)ο蠼Ｔ谔囟艚輰嵺`中為架構(gòu)概念占據(jù)了重要的一席之地。

域?qū)ο蠼Ｊ菑膽?yīng)用系統(tǒng)支持的現(xiàn)實世界對象（實體）的視角創(chuàng)建系統(tǒng)模型的過程，是所有面向?qū)ο笤O(shè)計和架構(gòu)技術(shù)的關(guān)鍵原則，也是FDD的一項關(guān)鍵實踐。域?qū)ο竽Ｐ统硕x這些對象之外，還用于定義這些實體間的關(guān)系。這些關(guān)系可以是靜態(tài)的（通用性/特異性、多重性和依賴性），也可以是動態(tài)的（消息傳遞），這樣域模型就可以達(dá)到團(tuán)隊想要的足夠高（或足夠低）的建模深度。正如Palmer［Palmer和Felsing 2002］所提到的一樣。

當(dāng)分析師和開發(fā)者得知需求……他們開始在頭腦中形成待建系統(tǒng)的思維圖像。他們非常細(xì)心，并對這個想象中的設(shè)計做些假設(shè)。這些隱含的假設(shè)可能造成人們工作的不一致。開發(fā)全局的域模型會使這些假定暴露出來。

顯然，當(dāng)敏捷方法應(yīng)用于可伸縮系統(tǒng)時，任何這樣的誤解都會引起系統(tǒng)性能的不一致（實用程序或性能缺陷）和系統(tǒng)間接口的不一致（設(shè)計缺陷）。反過來，本來可以避免的一些重構(gòu)或重做工作就成為必須要做的事情了。因此，在可伸縮系統(tǒng)中必須保證有一些建模。

根據(jù)我們的經(jīng)驗，當(dāng)團(tuán)隊采用更多的敏捷開發(fā)實踐時，許多團(tuán)隊都很少依賴需求和架構(gòu)約定（和更具擴(kuò)展性的建模），這些需求和架構(gòu)約定可能是他們以前方法中的“生命周期”早期階段獲取的。然而，同時，這些團(tuán)隊會依賴于簡單卻高效的域模型的可視化展示，將其作為項目的原始架構(gòu)。我們也看到，許多敏捷團(tuán)隊不論在開始還是在開發(fā)過程中都相當(dāng)依賴這個關(guān)鍵制品。

4, RUP：以架構(gòu)為中心

我們在第1部分中提到過，RUP的根源在于開發(fā)一套支持面向?qū)ο箝_發(fā)方法的軟件過程。此外，RUP的大部分內(nèi)容融入了Rational公司技術(shù)領(lǐng)導(dǎo)在做咨詢時從應(yīng)用程序到大規(guī)模系統(tǒng)中所獲取的經(jīng)驗教訓(xùn)，這些技術(shù)領(lǐng)導(dǎo)有Grady Booch、Philippe Kruchten、Walker Royce和 Ivar Jacobson等人。綜合起來，形成RUP的實踐主要來自于針對面向?qū)ο箝_發(fā)方法的大規(guī)模系統(tǒng)的開發(fā)。的確，RUP已經(jīng)被一些公司（如Ericsson等公司）應(yīng)用于大規(guī)模系統(tǒng)的項目，在這樣的項目中同時有幾千名開發(fā)人員參與開發(fā)。

RUP的主要特點是“以架構(gòu)為中心和用例驅(qū)動”。Booch對“以架構(gòu)為中心”進(jìn)行了如下描述：

（1）架構(gòu)是可以命名和管理的東西；

（2）人們使用架構(gòu)容納用例，有意識地管理風(fēng)險，并且通過迭代和增量的方式完善架構(gòu)。

所以，作為高效大規(guī)模系統(tǒng)軟件開發(fā)的基礎(chǔ)實踐，RUP考慮架構(gòu)已經(jīng)很長時間了。Kruchten［2004］提出了可伸縮系統(tǒng)架構(gòu)的重要性的演變。

由于很多軟件系統(tǒng)并不復(fù)雜，架構(gòu)可以讓開發(fā)者保持相互理解。然而，為了適應(yīng)新的需求，隨著系統(tǒng)的演變和發(fā)展，情況就完全不同了，系統(tǒng)無法同步增長。集成新技術(shù)需要完全重建系統(tǒng)。此外，設(shè)計者也缺少判斷系統(tǒng)組成部分合理性的智能工具。所以，糟糕的架構(gòu)總是被列為軟件失敗的原因就不奇怪了。沒有架構(gòu)，或者使用糟糕的架構(gòu)是軟件項目的主要技術(shù)風(fēng)險。

那么，RUP擁有應(yīng)用于迭代和增量軟件過程條件下的架構(gòu)開發(fā)指南就不足為奇了。目前，RUP指南包括一組用于定義系統(tǒng)的架構(gòu)視圖，每個視圖都從架構(gòu)上反映了一個或多個重要利益相關(guān)者的視角。其中，有如下兩個強(qiáng)制的視圖。

用例視圖。每個系統(tǒng)只有一個用例視圖，用例視圖圖示了所有用例和場景，從架構(gòu)上包含了重要的系統(tǒng)行為、類或者技術(shù)風(fēng)險。

邏輯視圖。每個系統(tǒng)只有一個邏輯視圖，邏輯視圖圖示了關(guān)鍵的用例實現(xiàn)、子系統(tǒng)、包和類，從架構(gòu)上包含了重要的系統(tǒng)行為。

此外，RUP額外規(guī)定了4種可選的視圖，這4種視圖可以根據(jù)所配置系統(tǒng)類型等方面的重要性酌情使用。

進(jìn)程視圖。當(dāng)系統(tǒng)擁有多個控制線程，并且線程之間有交互或依賴時推薦使用該視圖。該視圖通過把類和子系統(tǒng)映射為進(jìn)程和線程說明了系統(tǒng)的進(jìn)程分解。

配置視圖。當(dāng)系統(tǒng)分布在多個結(jié)點之間并且結(jié)構(gòu)上存在牽連時，推薦使用該視圖。配置視圖圖示了處理系統(tǒng)中一組結(jié)點的分布，包含進(jìn)程和線程的物理分布。

實現(xiàn)視圖。當(dāng)實現(xiàn)不是嚴(yán)格由設(shè)計驅(qū)動時，即設(shè)計和實現(xiàn)模型中的相應(yīng)包之間的責(zé)任分布是不同的時，推薦使用該視圖。實現(xiàn)視圖在給個人或團(tuán)隊分配實現(xiàn)任務(wù)時非常有用。恰當(dāng)?shù)膶崿F(xiàn)結(jié)構(gòu)會支持高效的持續(xù)集成。

數(shù)據(jù)視圖。當(dāng)持續(xù)數(shù)據(jù)是系統(tǒng)的關(guān)鍵部分時，推薦使用該視圖，例如，包含數(shù)據(jù)模式、數(shù)據(jù)定義和算法等內(nèi)容的系統(tǒng)。

5,炫目的敏捷架構(gòu)師

在敏捷項目中，傳統(tǒng)架構(gòu)師的象牙塔已經(jīng)逐漸成為最薄弱的一環(huán)，而他們的許多工作職責(zé)也已經(jīng)被整個敏捷團(tuán)隊所分解。敏捷架構(gòu)師的出現(xiàn)，正符合了查爾斯•達(dá)爾文的“適者生存”理論。在一個團(tuán)隊中，敏捷架構(gòu)師角色的重要性是毋庸置疑的，而且許多敏捷團(tuán)隊都認(rèn)為他是任何敏捷軟件開發(fā)團(tuán)隊中最有價值的成員之一。

敏捷架構(gòu)師的目標(biāo)：

1. 以最優(yōu)質(zhì)量交付可用的解決方案。

2. 維護(hù)概念完整性

3. 與團(tuán)隊一起工作

4. 編寫系統(tǒng)級別的測試

5. 參與緊密的協(xié)作

6. 做堅定的指導(dǎo)者

7. 做熟練的協(xié)調(diào)者

8. 不做大型的預(yù)先建模

9. 尋找大規(guī)模重構(gòu)的機(jī)會

10. 敏捷架構(gòu)師是萬能膠

原文鏈接：http://www.cnblogs.com/bluedoctor/archive/2012/06/26/2563430.html