敏捷思維: 架構設計中的方法學(xué)(12)

Refactoring

級別: 初級

林星, 項目經(jīng)理, 辰訊軟件工作室

2002 年 11 月 01 日

當架構模型進(jìn)行迭代的過(guò)程中，必然伴隨著(zhù)對模型進(jìn)行修改和改進(jìn)。我們如何防止對模型的修改，又如何保證對模型進(jìn)行正確的改進(jìn)？

Context

架構模型通過(guò)精化、合并等活動(dòng)之后，將會(huì )直接用于指導代碼。而這個(gè)時(shí)候，往往就會(huì )暴露出一些問(wèn)題出來(lái)，通常在實(shí)際編碼中，發(fā)現架構存在或大或小的問(wèn)題和錯誤，導致編碼活動(dòng)無(wú)法繼續。這時(shí)候我們就需要對架構模型進(jìn)行修改了。而架構設計的過(guò)程本身是一個(gè)迭代的過(guò)程，這就意味著(zhù)在每一次的迭代周期中，都需要對架構進(jìn)行改進(jìn)。

Problem

我們如何避免對架構模型進(jìn)行修改？又如何保證架構進(jìn)行正確的改進(jìn)？

Solution

我們從XP中借用了一個(gè)詞來(lái)形容架構模型的修改過(guò)程――Refactoring，中文可以譯作重構。這個(gè)詞原本是形容對代碼進(jìn)行修改的。它指的是在不改變代碼外部行為（可觀(guān)察行為）的情況下對代碼進(jìn)行修改。我們把這個(gè)詞用在架構模型上，因為經(jīng)過(guò)精化和合并之后的架構模型往往由很多個(gè)粗粒度組件構成。這些組件之間存在一定的耦合度（雖然我們可以令耦合度盡可能的低，但是耦合度一定是存在的），任何一個(gè)組件的重構行為都會(huì )使變化擴散到系統中的其它組件。這取決于被重構的組件和其它組件之間的相對關(guān)系。如果被重構的組件屬于層次較低的工具層上，那么這次的修改就可以引起模型很大的變動(dòng)。

在精化和合并模式中，我們提到了改變和改進(jìn)的區別，因此，我們的對策主要分為兩種：如何防止改變的發(fā)生，以及，使用重構來(lái)改進(jìn)軟件架構。

防止改變的發(fā)生

在任何時(shí)候，需求的變更總是對架構及軟件有著(zhù)最大的傷害。而需求變更中最大問(wèn)題是需求蔓延。很多人都有這樣的感覺(jué)，項目完成之后，發(fā)現初期的計劃顯得那么陌生。在項目早期對需求進(jìn)行控制是重要的，但并不是該模式談?wù)摰闹攸c(diǎn)。我們更關(guān)注在項目中期的需求蔓延問(wèn)題和晚期的需求控制問(wèn)題。關(guān)于這方面的詳細討論，請參見(jiàn)穩定化模式。在項目中期，尤其是編碼工作已經(jīng)開(kāi)始之后，要盡可能避免出現需求蔓延的情況。需求蔓延是經(jīng)常發(fā)生的，可能是因為用戶(hù)希望加入額外的功能，或是隨著(zhù)用戶(hù)對軟件了解的加深，發(fā)現原有的需求存在一定的不足。完全防止需求蔓延是無(wú)法做到的，但是需要對其進(jìn)行必要的控制。例如，有效的估計變更對開(kāi)發(fā)、測試、文檔、管理、組織等各個(gè)方面帶來(lái)的影響。

避免發(fā)生改變的另一個(gè)有效的辦法是從軟件過(guò)程著(zhù)手。迭代法或漸進(jìn)交付法都是可用的方法。一個(gè)軟件的架構設計往往是相對復雜的，其中涉及到整體結構、具體技術(shù)等問(wèn)題。一次性考慮全部的要素，就很容易發(fā)生考慮不周詳的情況。人的腦容量并沒(méi)有我們想象的那么大。將架構設計分為多個(gè)迭代周期來(lái)進(jìn)展，可以減少單次迭代周期中需要建模的架構數量，因此可以減少錯誤的發(fā)生。另一方面，迭代次數的增多的直接結果是時(shí)間的延長(cháng)，此外還有一個(gè)潛在的問(wèn)題，如果由于設計師的失誤，在后期的迭代中出現問(wèn)題，必然會(huì )導致大量的返工。因為之前的模型已經(jīng)實(shí)現了。在得與失之間，我們如何找到適當的平衡點(diǎn)呢？

迭代次數應該根據不同軟件組織的特點(diǎn)來(lái)制定，對于初期的迭代周期而言，它的主要任務(wù)應該是制定總原則（使用架構愿景模式）、定義層結構和各層的職責（使用分層模式）、解決主要的技術(shù)問(wèn)題上。在這個(gè)過(guò)程中，可以列出設計中可能會(huì )遇到的風(fēng)險，并根據風(fēng)險發(fā)生的可能性和危害性來(lái)排定優(yōu)先級，指定專(zhuān)人按次序解決這些問(wèn)題。除此之外，在初期參考前一個(gè)項目的經(jīng)驗，讓團隊進(jìn)行設計（參見(jiàn)團隊設計模式），這些組織保證也是很重要。初期的迭代過(guò)程是防止改變的最重要的活動(dòng)。

請注意需求中的非功能需求。如果說(shuō)功能需求定義了架構設計的目標的話(huà)，非功能需求就對如何到達這個(gè)目標做出了限制。例如，對于實(shí)現一個(gè)報表有著(zhù)多種的操作方法，但是如果用戶(hù)希望新系統和舊系統進(jìn)行有效的融合，那么實(shí)現的方式就需要好好的規劃了。請從初期的迭代過(guò)程就開(kāi)始注意非功能需求，因為如果忽略它們，在后期需要花費很大的精力來(lái)調整架構模型。試想一下，如果在項目晚期的壓力測試中，發(fā)現現有的數據庫訪(fǎng)問(wèn)方法無(wú)法滿(mǎn)足用戶(hù)基本的速度要求，那對項目進(jìn)行將會(huì )造成多么大的影響。

注意架構的穩定性。在精化和合并模式中，我們提到了一些模式，能夠降低不同組件之間的耦合度。并向調用者隱藏具體的實(shí)現。接口和實(shí)現分離是設計模式最大的特點(diǎn)，請善用這一點(diǎn)。

盡可能的推延正式文檔的編寫(xiě)。在設計的初期，修飾模型和編寫(xiě)文檔通常都沒(méi)有太大的意義。因為此時(shí)的模型還不穩定，需要不斷的修改。如果這時(shí)候開(kāi)始投入精力開(kāi)發(fā)文檔，這就意味著(zhù)后續的迭代周期中將會(huì )增加一項維護文檔一致性的工作了。而這時(shí)候的文檔卻無(wú)法發(fā)揮出它真正的作用。但是，延遲文檔的編寫(xiě)并不等于什么都不做，無(wú)論什么時(shí)候進(jìn)行設計，都需要隨手記錄設計的思路。這樣在需要的時(shí)候，我們就能夠有充分的資料對設計進(jìn)行文檔化的工作。

對軟件架構進(jìn)行重構

Martin Fowler的Refactoring一書(shū)為我們列舉了一系列的對代碼進(jìn)行重構方法。架構也是類(lèi)似的。

重構到模式

Joshua Kerievsky在《Refactoring to Patterns》一書(shū)中這樣描述重構和模式的關(guān)系：

Patterns are a cornerstone of object-oriented design, while test-first programming and merciless refactoring are cornerstones of evolutionary design

（模式是面向對象設計的基石，而測試優(yōu)先編程和無(wú)情的重構則是設計演進(jìn)的基石）。作者在文中著(zhù)重強調了保持適度設計的重要性。

在作者看來(lái)，模式常常扮演著(zhù)過(guò)度設計的角色。而在解決這個(gè)問(wèn)題的同時(shí)又利用模式的優(yōu)點(diǎn)的解決方法是避免在一開(kāi)始使用模式，而是在設計演進(jìn)中重構到模式。這種做法非常的有效，因為在初始設計中使用模式的話(huà)，你的注意力將會(huì )集中到如何使用模式上，而不是集中在如何滿(mǎn)足需求上。這樣就會(huì )導致不恰當的設計（過(guò)度設計或是設計不充分）。因此，在初始設計中，除非非常有把握（之前有類(lèi)似的經(jīng)驗），否則我們應當把精力放在如何滿(mǎn)足需求上。在初始模型完成后（參見(jiàn)精化和合并模式中的例子），我們會(huì )對架構進(jìn)行重構，而隨著(zhù)迭代的演進(jìn)，需求的演進(jìn)，架構也需要演進(jìn)，這時(shí)候也需要重構行為。在這些過(guò)程中，如果發(fā)現某些部分的設計需要額外的靈活性來(lái)滿(mǎn)足需求，那么這時(shí)候就需要引入模式了。

在軟件開(kāi)發(fā)過(guò)程中，我們更常的是遇見(jiàn)設計不充分的情況，例如組件之間耦合度過(guò)高，業(yè)務(wù)層向客戶(hù)端暴露了過(guò)多的方法等等。很多的時(shí)候，產(chǎn)生這種現象是由于不切實(shí)際的計劃而導致的。開(kāi)發(fā)人員不得不為了最終期限而趕工，所有的時(shí)間都花費在新功能上，而完成的軟件則被仍在一邊。這樣產(chǎn)出的軟件是無(wú)法保證其質(zhì)量的。對于這種情況，我們也需要對設計進(jìn)行重構，當然，合理的計劃是大前提所在。團隊的領(lǐng)導者必須向高層的管理者說(shuō)明，現在的這種做法只會(huì )導致未來(lái)的返工，目前的高速開(kāi)發(fā)是以犧牲未來(lái)的速度為代價(jià)的。因為低劣的設計需要的高成本的維護，這將抵消前期節省的成本。如果軟件團隊需要可持續的發(fā)展，那么請避免這種殺雞取卵的行為。

因此，使用模式來(lái)幫助重構行為，以實(shí)現恰當的設計。

測試行為

重構的前提是測試優(yōu)先，測試優(yōu)先是XP中很重要的一項實(shí)踐。對于編碼來(lái)說(shuō)，測試優(yōu)先的過(guò)程是先寫(xiě)測試用例，再編寫(xiě)代碼來(lái)完成通過(guò)測試用例（過(guò)程細節不只如此，請參看XP的相關(guān)書(shū)籍）。但是對于架構設計來(lái)說(shuō)，測試行為是發(fā)生在設計之后的，即在設計模型完成后，產(chǎn)出相應的測試用例，然后再編碼實(shí)現。這時(shí)候，測試用例就成為聯(lián)系架構設計和編碼活動(dòng)的紐帶。

另一方面，在設計進(jìn)行重構時(shí)，相應的測試用例也由很大的可能性發(fā)生改變。此時(shí)往往會(huì )發(fā)生需要改變的測試代碼超出普通代碼的情況。避免這種情況一種做法是令你的設計模型的接口和實(shí)現相分離，并使測試用例針對接口，而不是實(shí)現。在精化和合并模式中，我們提到了一些模式，能夠有助于穩定設計和測試用例。Martin Fowler在他的Application Facade一文中，提到使用Facade模式來(lái)分離不同的設計部分，而測試則應當針對facade來(lái)進(jìn)行，其思路也是如此。

考慮一個(gè)用戶(hù)轉帳的用例。銀行需要先對用戶(hù)進(jìn)行權限的審核，在審核通過(guò)之后才允許進(jìn)行轉帳（處于簡(jiǎn)便起見(jiàn)，圖中忽略了對象的創(chuàng )建過(guò)程和調用參數）：

需要分別針對三個(gè)類(lèi)編寫(xiě)測試用例，設計模型一旦發(fā)生變化，測試用例也將需要重新編寫(xiě)。再考慮下面的一種情況：

現在的設計引入了TransferFacade對象，這樣我們的測試用例就可以針對TransferFacade來(lái)編寫(xiě)了，而轉帳的業(yè)務(wù)邏輯是相對比較穩定的。使用這種測試思路的時(shí)候，要注意兩點(diǎn)：首先，這并不是說(shuō)其它的類(lèi)就不需要測試用例了，這種測試思路僅僅是把測試的重點(diǎn)放在外觀(guān)類(lèi)上，因為任何時(shí)候充分的測試都是不可能的。但其它類(lèi)的測試也是必要的，對于外觀(guān)類(lèi)來(lái)說(shuō)，任何一個(gè)業(yè)務(wù)方法的錯誤都會(huì )導致最終的測試失敗。其次，當外觀(guān)類(lèi)的測試無(wú)法達到穩定測試用例的效果時(shí)，就沒(méi)有必要使用外觀(guān)類(lèi)了。

只針對有需要的設計進(jìn)行重構。

任何時(shí)候，請確保重構行為僅僅對那些有重構需要的設計。重構需要花費時(shí)間和精力，而無(wú)用的重構除了增大設計者的虛榮心之外，并不能夠為軟件增加價(jià)值。重構的需要來(lái)源于兩點(diǎn)：一是需求的變更。目前的設計可能無(wú)法滿(mǎn)足新的需求，因此需要重構。二是對設計進(jìn)行改進(jìn)，以得到優(yōu)秀簡(jiǎn)潔的設計。除了這兩種情況，我們不應該對設計模型進(jìn)行重構。

使用文檔記錄重構的模式。

應該承認，模式為設計提供了充分的靈活性。而這些設計部分往往都是模型的關(guān)鍵之處和難點(diǎn)所在，因此需要對模式進(jìn)行文檔化的工作，甚至在必要的時(shí)候，對這部分的設計進(jìn)行培訓和指導。確保你的團隊能夠正確的使用文檔來(lái)設計、理解、擴展模式。我們在解決方案的前一個(gè)部分提到了盡可能延遲文檔的創(chuàng )建。而在設計重構為模式的時(shí)候，我們就需要進(jìn)行文檔化的工作了。因為模式具有靈活性，能夠抵抗一定的變更風(fēng)險。

重構并保持模式的一致性

正如上一節所說(shuō)的那樣，模式并不是一個(gè)很容易理解的東西，雖然它保持了設計的靈活性和穩定性。對于面向對象的新手而言，模式簡(jiǎn)直就像是飛碟一樣，由于缺少面向對象的設計經(jīng)驗，他們無(wú)法理解模式的處理思路，在實(shí)踐中，我們不只一次的碰到這種情況。我們不得不重頭開(kāi)始教授關(guān)于模式的課程。因此，最后我們在軟件設計采用一定數量的模式，并確保在處理相同問(wèn)題的時(shí)候使用相同的模式。這樣，應用的模式就成為解決某一類(lèi)的問(wèn)題的標準做法，從而在一定程度上降低了學(xué)習的曲線(xiàn)。

保持模式的一致性的另一個(gè)方面的含義是將模式作為溝通的橋梁。軟件開(kāi)發(fā)是一種團隊的行為。因此溝通在軟件開(kāi)發(fā)中扮演著(zhù)很重要的角色。試想一下，開(kāi)發(fā)人員在討論軟件設計的時(shí)候，只需要說(shuō)"使用工廠(chǎng)模式"，大家就都能夠明白，而不是費勁口舌的說(shuō)明幾個(gè)類(lèi)之間的關(guān)系。這將大大提高溝通的效率。此外，模式的使用和設計的重構對于提高團隊的編程水平，培養后備的設計人員等方面都是很有意義的。