聲明原文地址不詳，分享。
當(dāng)架構(gòu)模型進(jìn)行迭代的過(guò)程中，必然伴隨著對(duì)模型進(jìn)行修改和改進(jìn)。我們?nèi)绾畏乐箤?duì)模型的修改，又如何保證對(duì)模型進(jìn)行正確的改進(jìn)？
Context
架構(gòu)模型通過(guò)精化、合并等活動(dòng)之后，將會(huì)直接用于指導(dǎo)代碼。而這個(gè)時(shí)候，往往就會(huì)暴露出一些問題出來(lái)，通常在實(shí)際編碼中，發(fā)現(xiàn)架構(gòu)存在或大或小的問題和錯(cuò)誤，導(dǎo)致編碼活動(dòng)無(wú)法繼續(xù)。這時(shí)候我們就需要對(duì)架構(gòu)模型進(jìn)行修改了。而架構(gòu)設(shè)計(jì)的過(guò)程本身是一個(gè)迭代的過(guò)程，這就意味著在每一次的迭代周期中，都需要對(duì)架構(gòu)進(jìn)行改進(jìn)。
Problem
我們?nèi)绾伪苊鈱?duì)架構(gòu)模型進(jìn)行修改？又如何保證架構(gòu)進(jìn)行正確的改進(jìn)？
Solution
我們從XP中借用了一個(gè)詞來(lái)形容架構(gòu)模型的修改過(guò)程――Refactoring，中文可以譯作重構(gòu)。這個(gè)詞原本是形容對(duì)代碼進(jìn)行修改的。它指的是在不改變代碼外部行為（可觀察行為）的情況下對(duì)代碼進(jìn)行修改。我們把這個(gè)詞用在架構(gòu)模型上，因?yàn)榻?jīng)過(guò)精化和合并之后的架構(gòu)模型往往由很多個(gè)粗粒度組件構(gòu)成。這些組件之間存在一定的耦合度（雖然我們可以令耦合度盡可能的低，但是耦合度一定是存在的），任何一個(gè)組件的重構(gòu)行為都會(huì)使變化擴(kuò)散到系統(tǒng)中的其它組件。這取決于被重構(gòu)的組件和其它組件之間的相對(duì)關(guān)系。如果被重構(gòu)的組件屬于層次較低的工具層上，那么這次的修改就可以引起模型很大的變動(dòng)。
在精化和合并模式中，我們提到了改變和改進(jìn)的區(qū)別，因此，我們的對(duì)策主要分為兩種：如何防止改變的發(fā)生，以及，使用重構(gòu)來(lái)改進(jìn)軟件架構(gòu)。
防止改變的發(fā)生
在任何時(shí)候，需求的變更總是對(duì)架構(gòu)及軟件有著最大的傷害。而需求變更中最大問題是需求蔓延。很多人都有這樣的感覺，項(xiàng)目完成之后，發(fā)現(xiàn)初期的計(jì)劃顯得那么陌生。在項(xiàng)目早期對(duì)需求進(jìn)行控制是重要的，但并不是該模式談?wù)摰闹攸c(diǎn)。我們更關(guān)注在項(xiàng)目中期的需求蔓延問題和晚期的需求控制問題。關(guān)于這方面的詳細(xì)討論，請(qǐng)參見穩(wěn)定化模式。在項(xiàng)目中期，尤其是編碼工作已經(jīng)開始之后，要盡可能避免出現(xiàn)需求蔓延的情況。需求蔓延是經(jīng)常發(fā)生的，可能是因?yàn)橛脩粝Ｍ尤腩~外的功能，或是隨著用戶對(duì)軟件了解的加深，發(fā)現(xiàn)原有的需求存在一定的不足。完全防止需求蔓延是無(wú)法做到的，但是需要對(duì)其進(jìn)行必要的控制。例如，有效的估計(jì)變更對(duì)開發(fā)、測(cè)試、文檔、管理、組織等各個(gè)方面帶來(lái)的影響。
避免發(fā)生改變的另一個(gè)有效的辦法是從軟件過(guò)程著手。迭代法或漸進(jìn)交付法都是可用的方法。一個(gè)軟件的架構(gòu)設(shè)計(jì)往往是相對(duì)復(fù)雜的，其中涉及到整體結(jié)構(gòu)、具體技術(shù)等問題。一次性考慮全部的要素，就很容易發(fā)生考慮不周詳?shù)那闆r。人的腦容量并沒有我們想象的那么大。將架構(gòu)設(shè)計(jì)分為多個(gè)迭代周期來(lái)進(jìn)展，可以減少單次迭代周期中需要建模的架構(gòu)數(shù)量，因此可以減少錯(cuò)誤的發(fā)生。另一方面，迭代次數(shù)的增多的直接結(jié)果是時(shí)間的延長(zhǎng)，此外還有一個(gè)潛在的問題，如果由于設(shè)計(jì)師的失誤，在后期的迭代中出現(xiàn)問題，必然會(huì)導(dǎo)致大量的返工。因?yàn)橹暗哪Ｐ鸵呀?jīng)實(shí)現(xiàn)了。在得與失之間，我們?nèi)绾握业竭m當(dāng)?shù)钠胶恻c(diǎn)呢？
迭代次數(shù)應(yīng)該根據(jù)不同軟件組織的特點(diǎn)來(lái)制定，對(duì)于初期的迭代周期而言，它的主要任務(wù)應(yīng)該是制定總原則（使用架構(gòu)愿景模式）、定義層結(jié)構(gòu)和各層的職責(zé)（使用分層模式）、解決主要的技術(shù)問題上。在這個(gè)過(guò)程中，可以列出設(shè)計(jì)中可能會(huì)遇到的風(fēng)險(xiǎn)，并根據(jù)風(fēng)險(xiǎn)發(fā)生的可能性和危害性來(lái)排定優(yōu)先級(jí)，指定專人按次序解決這些問題。除此之外，在初期參考前一個(gè)項(xiàng)目的經(jīng)驗(yàn)，讓團(tuán)隊(duì)進(jìn)行設(shè)計(jì)（參見團(tuán)隊(duì)設(shè)計(jì)模式），這些組織保證也是很重要。初期的迭代過(guò)程是防止改變的最重要的活動(dòng)。
請(qǐng)注意需求中的非功能需求。如果說(shuō)功能需求定義了架構(gòu)設(shè)計(jì)的目標(biāo)的話，非功能需求就對(duì)如何到達(dá)這個(gè)目標(biāo)做出了限制。例如，對(duì)于實(shí)現(xiàn)一個(gè)報(bào)表有著多種的操作方法，但是如果用戶希望新系統(tǒng)和舊系統(tǒng)進(jìn)行有效的融合，那么實(shí)現(xiàn)的方式就需要好好的規(guī)劃了。請(qǐng)從初期的迭代過(guò)程就開始注意非功能需求，因?yàn)槿绻雎运鼈儯诤笃谛枰ㄙM(fèi)很大的精力來(lái)調(diào)整架構(gòu)模型。試想一下，如果在項(xiàng)目晚期的壓力測(cè)試中，發(fā)現(xiàn)現(xiàn)有的數(shù)據(jù)庫(kù)訪問方法無(wú)法滿足用戶基本的速度要求，那對(duì)項(xiàng)目進(jìn)行將會(huì)造成多么大的影響。
注意架構(gòu)的穩(wěn)定性。在精化和合并模式中，我們提到了一些模式，能夠降低不同組件之間的耦合度。并向調(diào)用者隱藏具體的實(shí)現(xiàn)。接口和實(shí)現(xiàn)分離是設(shè)計(jì)模式最大的特點(diǎn)，請(qǐng)善用這一點(diǎn)。
盡可能的推延正式文檔的編寫。在設(shè)計(jì)的初期，修飾模型和編寫文檔通常都沒有太大的意義。因?yàn)榇藭r(shí)的模型還不穩(wěn)定，需要不斷的修改。如果這時(shí)候開始投入精力開發(fā)文檔，這就意味著后續(xù)的迭代周期中將會(huì)增加一項(xiàng)維護(hù)文檔一致性的工作了。而這時(shí)候的文檔卻無(wú)法發(fā)揮出它真正的作用。但是，延遲文檔的編寫并不等于什么都不做，無(wú)論什么時(shí)候進(jìn)行設(shè)計(jì)，都需要隨手記錄設(shè)計(jì)的思路。這樣在需要的時(shí)候，我們就能夠有充分的資料對(duì)設(shè)計(jì)進(jìn)行文檔化的工作。
對(duì)軟件架構(gòu)進(jìn)行重構(gòu)
Martin Fowler的Refactoring一書為我們列舉了一系列的對(duì)代碼進(jìn)行重構(gòu)方法。架構(gòu)也是類似的。
重構(gòu)到模式
Joshua Kerievsky在《Refactoring to Patterns》一書中這樣描述重構(gòu)和模式的關(guān)系：
Patterns are a cornerstone of object-oriented design, while test-first programming and merciless refactoring are cornerstones of evolutionary design
（模式是面向?qū)ο笤O(shè)計(jì)的基石，而測(cè)試優(yōu)先編程和無(wú)情的重構(gòu)則是設(shè)計(jì)演進(jìn)的基石）。作者在文中著重強(qiáng)調(diào)了保持適度設(shè)計(jì)的重要性。
在作者看來(lái)，模式常常扮演著過(guò)度設(shè)計(jì)的角色。而在解決這個(gè)問題的同時(shí)又利用模式的優(yōu)點(diǎn)的解決方法是避免在一開始使用模式，而是在設(shè)計(jì)演進(jìn)中重構(gòu)到模式。這種做法非常的有效，因?yàn)樵诔跏荚O(shè)計(jì)中使用模式的話，你的注意力將會(huì)集中到如何使用模式上，而不是集中在如何滿足需求上。這樣就會(huì)導(dǎo)致不恰當(dāng)?shù)脑O(shè)計(jì)（過(guò)度設(shè)計(jì)或是設(shè)計(jì)不充分）。因此，在初始設(shè)計(jì)中，除非非常有把握（之前有類似的經(jīng)驗(yàn)），否則我們應(yīng)當(dāng)把精力放在如何滿足需求上。在初始模型完成后（參見精化和合并模式中的例子），我們會(huì)對(duì)架構(gòu)進(jìn)行重構(gòu)，而隨著迭代的演進(jìn)，需求的演進(jìn)，架構(gòu)也需要演進(jìn)，這時(shí)候也需要重構(gòu)行為。在這些過(guò)程中，如果發(fā)現(xiàn)某些部分的設(shè)計(jì)需要額外的靈活性來(lái)滿足需求，那么這時(shí)候就需要引入模式了。
在軟件開發(fā)過(guò)程中，我們更常的是遇見設(shè)計(jì)不充分的情況，例如組件之間耦合度過(guò)高，業(yè)務(wù)層向客戶端暴露了過(guò)多的方法等等。很多的時(shí)候，產(chǎn)生這種現(xiàn)象是由于不切實(shí)際的計(jì)劃而導(dǎo)致的。開發(fā)人員不得不為了最終期限而趕工，所有的時(shí)間都花費(fèi)在新功能上，而完成的軟件則被仍在一邊。這樣產(chǎn)出的軟件是無(wú)法保證其質(zhì)量的。對(duì)于這種情況，我們也需要對(duì)設(shè)計(jì)進(jìn)行重構(gòu)，當(dāng)然，合理的計(jì)劃是大前提所在。團(tuán)隊(duì)的領(lǐng)導(dǎo)者必須向高層的管理者說(shuō)明，現(xiàn)在的這種做法只會(huì)導(dǎo)致未來(lái)的返工，目前的高速開發(fā)是以犧牲未來(lái)的速度為代價(jià)的。因?yàn)榈土拥脑O(shè)計(jì)需要的高成本的維護(hù)，這將抵消前期節(jié)省的成本。如果軟件團(tuán)隊(duì)需要可持續(xù)的發(fā)展，那么請(qǐng)避免這種殺雞取卵的行為。
因此，使用模式來(lái)幫助重構(gòu)行為，以實(shí)現(xiàn)恰當(dāng)?shù)脑O(shè)計(jì)。
測(cè)試行為
重構(gòu)的前提是測(cè)試優(yōu)先，測(cè)試優(yōu)先是XP中很重要的一項(xiàng)實(shí)踐。對(duì)于編碼來(lái)說(shuō)，測(cè)試優(yōu)先的過(guò)程是先寫測(cè)試用例，再編寫代碼來(lái)完成通過(guò)測(cè)試用例（過(guò)程細(xì)節(jié)不只如此，請(qǐng)參看XP的相關(guān)書籍）。但是對(duì)于架構(gòu)設(shè)計(jì)來(lái)說(shuō)，測(cè)試行為是發(fā)生在設(shè)計(jì)之后的，即在設(shè)計(jì)模型完成后，產(chǎn)出相應(yīng)的測(cè)試用例，然后再編碼實(shí)現(xiàn)。這時(shí)候，測(cè)試用例就成為聯(lián)系架構(gòu)設(shè)計(jì)和編碼活動(dòng)的紐帶。
另一方面，在設(shè)計(jì)進(jìn)行重構(gòu)時(shí)，相應(yīng)的測(cè)試用例也由很大的可能性發(fā)生改變。此時(shí)往往會(huì)發(fā)生需要改變的測(cè)試代碼超出普通代碼的情況。避免這種情況一種做法是令你的設(shè)計(jì)模型的接口和實(shí)現(xiàn)相分離，并使測(cè)試用例針對(duì)接口，而不是實(shí)現(xiàn)。在精化和合并模式中，我們提到了一些模式，能夠有助于穩(wěn)定設(shè)計(jì)和測(cè)試用例。Martin Fowler在他的Application Facade一文中，提到使用Facade模式來(lái)分離不同的設(shè)計(jì)部分，而測(cè)試則應(yīng)當(dāng)針對(duì)facade來(lái)進(jìn)行，其思路也是如此。
考慮一個(gè)用戶轉(zhuǎn)帳的用例。銀行需要先對(duì)用戶進(jìn)行權(quán)限的審核，在審核通過(guò)之后才允許進(jìn)行轉(zhuǎn)帳（處于簡(jiǎn)便起見，圖中忽略了對(duì)象的創(chuàng)建過(guò)程和調(diào)用參數(shù)）：
需要分別針對(duì)三個(gè)類編寫測(cè)試用例，設(shè)計(jì)模型一旦發(fā)生變化，測(cè)試用例也將需要重新編寫。再考慮下面的一種情況：
現(xiàn)在的設(shè)計(jì)引入了TransferFacade對(duì)象，這樣我們的測(cè)試用例就可以針對(duì)TransferFacade來(lái)編寫了，而轉(zhuǎn)帳的業(yè)務(wù)邏輯是相對(duì)比較穩(wěn)定的。使用這種測(cè)試思路的時(shí)候，要注意兩點(diǎn)：首先，這并不是說(shuō)其它的類就不需要測(cè)試用例了，這種測(cè)試思路僅僅是把測(cè)試的重點(diǎn)放在外觀類上，因?yàn)槿魏螘r(shí)候充分的測(cè)試都是不可能的。但其它類的測(cè)試也是必要的，對(duì)于外觀類來(lái)說(shuō)，任何一個(gè)業(yè)務(wù)方法的錯(cuò)誤都會(huì)導(dǎo)致最終的測(cè)試失敗。其次，當(dāng)外觀類的測(cè)試無(wú)法達(dá)到穩(wěn)定測(cè)試用例的效果時(shí)，就沒有必要使用外觀類了。
只針對(duì)有需要的設(shè)計(jì)進(jìn)行重構(gòu)。
任何時(shí)候，請(qǐng)確保重構(gòu)行為僅僅對(duì)那些有重構(gòu)需要的設(shè)計(jì)。重構(gòu)需要花費(fèi)時(shí)間和精力，而無(wú)用的重構(gòu)除了增大設(shè)計(jì)者的虛榮心之外，并不能夠?yàn)檐浖黾觾r(jià)值。重構(gòu)的需要來(lái)源于兩點(diǎn)：一是需求的變更。目前的設(shè)計(jì)可能無(wú)法滿足新的需求，因此需要重構(gòu)。二是對(duì)設(shè)計(jì)進(jìn)行改進(jìn)，以得到優(yōu)秀簡(jiǎn)潔的設(shè)計(jì)。除了這兩種情況，我們不應(yīng)該對(duì)設(shè)計(jì)模型進(jìn)行重構(gòu)。
使用文檔記錄重構(gòu)的模式。
應(yīng)該承認(rèn)，模式為設(shè)計(jì)提供了充分的靈活性。而這些設(shè)計(jì)部分往往都是模型的關(guān)鍵之處和難點(diǎn)所在，因此需要對(duì)模式進(jìn)行文檔化的工作，甚至在必要的時(shí)候，對(duì)這部分的設(shè)計(jì)進(jìn)行培訓(xùn)和指導(dǎo)。確保你的團(tuán)隊(duì)能夠正確的使用文檔來(lái)設(shè)計(jì)、理解、擴(kuò)展模式。我們?cè)诮鉀Q方案的前一個(gè)部分提到了盡可能延遲文檔的創(chuàng)建。而在設(shè)計(jì)重構(gòu)為模式的時(shí)候，我們就需要進(jìn)行文檔化的工作了。因?yàn)槟Ｊ骄哂徐`活性，能夠抵抗一定的變更風(fēng)險(xiǎn)。
重構(gòu)并保持模式的一致性
正如上一節(jié)所說(shuō)的那樣，模式并不是一個(gè)很容易理解的東西，雖然它保持了設(shè)計(jì)的靈活性和穩(wěn)定性。對(duì)于面向?qū)ο蟮男率侄裕Ｊ胶?jiǎn)直就像是飛碟一樣，由于缺少面向?qū)ο蟮脑O(shè)計(jì)經(jīng)驗(yàn)，他們無(wú)法理解模式的處理思路，在實(shí)踐中，我們不只一次的碰到這種情況。我們不得不重頭開始教授關(guān)于模式的課程。因此，最后我們?cè)谲浖O(shè)計(jì)采用一定數(shù)量的模式，并確保在處理相同問題的時(shí)候使用相同的模式。這樣，應(yīng)用的模式就成為解決某一類的問題的標(biāo)準(zhǔn)做法，從而在一定程度上降低了學(xué)習(xí)的曲線。
保持模式的一致性的另一個(gè)方面的含義是將模式作為溝通的橋梁。軟件開發(fā)是一種團(tuán)隊(duì)的行為。因此溝通在軟件開發(fā)中扮演著很重要的角色。試想一下，開發(fā)人員在討論軟件設(shè)計(jì)的時(shí)候，只需要說(shuō)"使用工廠模式"，大家就都能夠明白，而不是費(fèi)勁口舌的說(shuō)明幾個(gè)類之間的關(guān)系。這將大大提高溝通的效率。此外，模式的使用和設(shè)計(jì)的重構(gòu)對(duì)于提高團(tuán)隊(duì)的編程水平，培養(yǎng)后備的設(shè)計(jì)人員等方面都是很有意義的。
本博客為學(xué)習(xí)交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請(qǐng)注明出處，如有版權(quán)問題請(qǐng)及時(shí)通知。由于博客時(shí)間倉(cāng)促，錯(cuò)誤之處敬請(qǐng)諒解，有任何意見可給我留言，愿共同學(xué)習(xí)進(jìn)步。