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

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

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

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

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

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

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

通過對架構(gòu)的預(yù)測，可以在項目早期進(jìn)行一些高層次的架構(gòu)建模，以助于團(tuán)隊與關(guān)鍵利益相關(guān)人商討系統(tǒng)采取的技術(shù)策略。這一行為的關(guān)鍵目標(biāo)是識別出架構(gòu)策略，而不是撰寫如山一般堆積的文檔，從而使得你能夠快速完成架構(gòu)建模。其中的竅門就是盡量保持簡單。開發(fā)者不需要對大量的細(xì)節(jié)進(jìn)行建模，而只需要足夠即可。如果你正在編寫用例，意味著你只需要以標(biāo)注形式列出用例的要點就足夠好了。如果你正在對領(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)有可能會與它們進(jìn)行交互。

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

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

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

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

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

第二種場景是架構(gòu)師對相關(guān)技巧與經(jīng)驗完全不知。此時，仍然只需要作少量的初始建模即可。因為你缺乏足夠的知識來完成細(xì)致而又全面的架構(gòu)設(shè)計，反而會因為了解不夠而導(dǎo)致錯誤，從而增加項目的風(fēng)險，并且阻礙了項目的進(jìn)度。

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

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

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

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

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

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

4. 增強(qiáng)溝通

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

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