在敏捷開發(fā)中使用演進(jìn)式架構(gòu)設(shè)計(jì)

申請免費(fèi)試用、咨詢電話：400-8352-114

在敏捷開發(fā)過程中，我們還需要對系統(tǒng)架構(gòu)進(jìn)行設(shè)計(jì)嗎？事實(shí)上，Martin Fowler在《Is Design Dead?》一文中已經(jīng)給出了答案，那就是我們同樣不能忽略對系統(tǒng)架構(gòu)的設(shè)計(jì)。與計(jì)劃性的設(shè)計(jì)（Planned Design）不同，我們需要演進(jìn)式的設(shè)計(jì)（Evolutionary Design）。在敏捷開發(fā)的生命周期中，我們通過每一次迭代來豐富與更新我們的設(shè)計(jì)方案，以使其最大限度地符合客戶對系統(tǒng)的需求。這里所指的需求，包括功能性需求和非功能性需求。

在Agile Journal四月刊中，IBM's Methods Group的敏捷專家Scott W. Ambler詳細(xì)地闡述了在敏捷語境中的架構(gòu)設(shè)計(jì)方法，他提出了所謂“架構(gòu)預(yù)測（Architectural Envisioning）”的方法，以應(yīng)對敏捷開發(fā)中逐步演進(jìn)的架構(gòu)設(shè)計(jì)過程。

Scott指出，敏捷模型驅(qū)動(dòng)開發(fā)（Agile Model Driven Development，AMDD）明確地包括了初始需求分析與架構(gòu)建模，這個(gè)過程發(fā)生在敏捷項(xiàng)目開發(fā)的第0次迭代中。所謂第0次迭代，就相當(dāng)于項(xiàng)目的熱身活動(dòng)，是項(xiàng)目得以啟動(dòng)的基礎(chǔ)。在此迭代期間，團(tuán)隊(duì)需要充分地理解項(xiàng)目的范圍，甄別可行地技術(shù)策略。這個(gè)階段所能夠收集到的信息將有助于你對整個(gè)項(xiàng)目最初的粗略估計(jì)，以制定合適的項(xiàng)目計(jì)劃，從而獲得啟動(dòng)項(xiàng)目的資金與足夠的支持。

敏捷模型驅(qū)動(dòng)開發(fā)的生命周期如下圖所示：

根據(jù)圖中所示，在每次迭代的初期，制定的迭代計(jì)劃都應(yīng)該包括建模的工作。在此期間，可以召開建模的頭腦風(fēng)暴會(huì)議，討論系統(tǒng)的功能特征，并思考實(shí)現(xiàn)這些特征的高層設(shè)計(jì)策略。大多數(shù)敏捷團(tuán)隊(duì)都會(huì)通過測試驅(qū)動(dòng)開發(fā)（TDD）確定需求與設(shè)計(jì)的細(xì)節(jié)。

通過對架構(gòu)的預(yù)測，可以在項(xiàng)目早期進(jìn)行一些高層次的架構(gòu)建模，以助于團(tuán)隊(duì)與關(guān)鍵利益相關(guān)人商討系統(tǒng)采取的技術(shù)策略。這一行為的關(guān)鍵目標(biāo)是識(shí)別出架構(gòu)策略，而不是撰寫如山一般堆積的文檔，從而使得你能夠快速完成架構(gòu)建模。其中的竅門就是盡量保持簡單。開發(fā)者不需要對大量的細(xì)節(jié)進(jìn)行建模，而只需要足夠即可。如果你正在編寫用例，意味著你只需要以標(biāo)注形式列出用例的要點(diǎn)就足夠好了。如果你正在對領(lǐng)域建模，可以直接在白板上繪圖，或者使用CRC卡片。你的目的在于對信息的共享與交流，而不是編寫細(xì)致的文檔。

如果采用架構(gòu)預(yù)測的方式，你需要對哪些內(nèi)容進(jìn)行建模呢？Scott在文中指出有如下四部分內(nèi)容需要建模：

1. 技術(shù)圖表。例如UML部署圖。這些圖表有助于開發(fā)者預(yù)測主要的軟件和硬件組件，包括你需要訪問的舊系統(tǒng)和數(shù)據(jù)庫，系統(tǒng)有可能會(huì)與它們進(jìn)行交互。

2. 用戶交互流程圖。通過分析用戶交互的主要頁面/外觀和報(bào)告，對系統(tǒng)的UI進(jìn)行架構(gòu)設(shè)計(jì)。如果在進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候不考慮用戶交互界面，就可能存在潛在危機(jī)，那就是你構(gòu)建的系統(tǒng)不是利益相關(guān)人所希望看到的。請記住，UI才是最終用戶使用的系統(tǒng)。

3. 領(lǐng)域圖。在最初的架構(gòu)建模中，一個(gè)重要的組成部分是對領(lǐng)域的高層建模。模型可以非常微小，只需要捕獲主要的業(yè)務(wù)實(shí)體，以及它們之間的關(guān)系。有的人可能認(rèn)為領(lǐng)域模型應(yīng)該屬于需求建模的一部分，而不是架構(gòu)建模。但正如上圖所示，這兩者在第0次迭代中是并發(fā)進(jìn)行的。

4. 變更情形。就是在架構(gòu)級(jí)需求中描述可能的技術(shù)或業(yè)務(wù)變更，而這些變更需要在未來能夠提供支持。變更情形要求你考慮架構(gòu)的擴(kuò)展能力，但并不是過度構(gòu)建你的系統(tǒng)。因?yàn)槟阒皇且紤]由于變更所造成的影響，以確保你構(gòu)建的系統(tǒng)還能夠正常工作。

架構(gòu)建模是貫穿于整個(gè)項(xiàng)目周期的，因此這些圖表就是在項(xiàng)目結(jié)束時(shí)形成的整體文檔的基礎(chǔ)。由于你事先明確架構(gòu)是演進(jìn)的，因此就不必承擔(dān)架構(gòu)設(shè)計(jì)在項(xiàng)目早期必須“正確無誤”的壓力，而只需要在當(dāng)前形勢下保證足夠好就可以了。Scott建議使用白板和草稿紙等簡便工具，勾勒出這些模型的初始版本。當(dāng)然，如果團(tuán)隊(duì)成員具有熟練的建模技巧，也可以使用專門的建模工具。這一建議足以體現(xiàn)架構(gòu)設(shè)計(jì)的敏捷性，與長篇累牘的傳統(tǒng)架構(gòu)設(shè)計(jì)方式迥然不同。

對于這樣一種架構(gòu)設(shè)計(jì)方式，熟悉傳統(tǒng)架構(gòu)設(shè)計(jì)方式的架構(gòu)師普遍不以為然。Scott對這一看法給與了強(qiáng)有力的反駁。他將架構(gòu)設(shè)計(jì)場景分為三種類型。第一種是架構(gòu)師熟悉系統(tǒng)架構(gòu)設(shè)計(jì)所必需的技能與經(jīng)驗(yàn)。既然你已經(jīng)熟悉了這些內(nèi)容，當(dāng)然就沒有必要作出完整的設(shè)計(jì)了。你只需要在白板上體現(xiàn)你的架構(gòu)設(shè)計(jì)，保證團(tuán)隊(duì)的每個(gè)人都能夠按照相同的體系架構(gòu)進(jìn)行實(shí)現(xiàn)就可以了。

第二種場景是架構(gòu)師對相關(guān)技巧與經(jīng)驗(yàn)完全不知。此時(shí)，仍然只需要作少量的初始建模即可。因?yàn)槟闳狈ψ銐虻闹R(shí)來完成細(xì)致而又全面的架構(gòu)設(shè)計(jì)，反而會(huì)因?yàn)榱私獠粔蚨鴮?dǎo)致錯(cuò)誤，從而增加項(xiàng)目的風(fēng)險(xiǎn)，并且阻礙了項(xiàng)目的進(jìn)度。

第三種場景則是架構(gòu)師熟悉部分知識(shí)。這種情形也是團(tuán)隊(duì)開發(fā)中最常見的場景。在這種情況下，可以耗費(fèi)幾天時(shí)間作出一個(gè)初始的架構(gòu)建模，以驗(yàn)證系統(tǒng)可能存在的風(fēng)險(xiǎn)，并制定可能策略以減輕風(fēng)險(xiǎn)可能造成的后果。你可以實(shí)現(xiàn)一些可工作的代碼來驗(yàn)證架構(gòu)。建模在這種情況下是非常有意義的，因?yàn)樗沟媚憧梢远x一個(gè)一致的技術(shù)愿景，為團(tuán)隊(duì)成員所分享，并對系統(tǒng)的主要問題進(jìn)行思考。

當(dāng)你的團(tuán)隊(duì)成員是分散在各地時(shí)，或者當(dāng)團(tuán)隊(duì)非常龐大，下面分為多個(gè)小組時(shí)，這種初始的架構(gòu)建模就能夠帶來無與倫比的價(jià)值。它有助于在團(tuán)隊(duì)成員之間建立一個(gè)公共的愿景，更重要的是它能夠識(shí)別出分離的組件/子系統(tǒng)，以及這些組件的初始接口。一旦識(shí)別出這些耦合度較低的組件或子系統(tǒng)，就能夠合理地對團(tuán)隊(duì)進(jìn)行分組，并保證小組之間設(shè)計(jì)與實(shí)現(xiàn)的一致性。

Scott指出，所謂的“架構(gòu)預(yù)測”能夠提供如下價(jià)值：

1. 提高生產(chǎn)力

2. 降低技術(shù)風(fēng)險(xiǎn)

3. 減少開發(fā)時(shí)間

4. 增強(qiáng)溝通

5. 可伸縮的敏捷軟件開發(fā)。

需要明確的是，這樣的一種架構(gòu)預(yù)測方式，正好符合敏捷開發(fā)迭代的需要。在項(xiàng)目開發(fā)早期，對系統(tǒng)整體進(jìn)行一次高層次的概覽，并對關(guān)鍵業(yè)務(wù)需求進(jìn)行甄別與分析，劃分合理的系統(tǒng)模塊，有助于在迭代開發(fā)中為團(tuán)隊(duì)成員建立一個(gè)統(tǒng)一的標(biāo)準(zhǔn)與目標(biāo)。而在每次迭代過程中，團(tuán)隊(duì)就可以對本次迭代期間的功能進(jìn)行深入的架構(gòu)建模，然后通過TDD充分理解需求，對模塊的細(xì)節(jié)進(jìn)行設(shè)計(jì)與實(shí)現(xiàn)。這是敏捷架構(gòu)設(shè)計(jì)的核心操作原理，它與敏捷開發(fā)原則是一脈相承的。（CIO時(shí)代網(wǎng)）