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

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

XP是以程序員為中心的開發(fā)，其中沒(méi)有一個(gè)核心實(shí)踐明確討論了軟件架構(gòu)，然而，這并不是說(shuō)XP項(xiàng)目和XP團(tuán)隊(duì)不用或不理解架構(gòu)在軟件開發(fā)中的作用。Beck［2000］提到：“架構(gòu)在XP項(xiàng)目中和在其他軟件項(xiàng)目中一樣重要”。因此，我們?cè)诟拍钌蠌腦P方法入手是一個(gè)好的開端。接著Beck繼續(xù)解釋架構(gòu)是如何形成的。

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

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

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

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

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

2, Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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