架構重構：通過以任務為中心的視角看軟件的進化

本文最初 發表在 IEEE 軟件 雜志上， IEEE 軟件 雜志致力于發表嚴謹的、經過互相審校的文章，專注于當今世界的戰略科技。為了滿足運行可靠且靈活企業所面臨的挑戰，IT經理和技術管理者依賴IT Pro獲取最先進的解決方案。

軟件密集型的系統經常會因為各種各樣的原因而必須進行重新設計，例如某個不可預知的業務變動或是技術上的創新。許多重新設計活動會對這些系統的軟 件架構產生影響，代碼重構就是一種流行的重新設計實踐。考慮到代碼成功這一實踐的巨大成功，這使人們對于架構重構（AR）這種實踐的沉默感到有些吃驚。為 了糾正這一情形，我將在本文中為讀者展示，作為一種軟件進化技術，AR如何重新審視架構決策，并確認相關的設計、實現及文檔任務。

介紹架構重構

重構的目的是在改善某部分質量的同時保持其它部分不變，舉例來說，代碼重構實踐對代碼的結構進行了重新調整，以增強代碼的可維護性，同時又保持它的可觀察 行為不變。代碼重構實踐是與機器可讀的實體進行打交道，例如包、類以及方法，讓這些實體能夠在編譯器構造階段利用各種數據結構，例如抽象語法樹 ¹ 。而AR則是與架構文檔和架構知識在代碼與運行時產品中所表現出的行為打交道。因此，不存在一種單一的架構語法樹。AR的范疇包括：

• 組件與連接器（經過建模、描繪或在代碼中隱式地表現出來），
• 設計決策的記錄（以結構化和非結構化的文本表現），以及
• 計劃階段的產物，例如項目管理工具中的工作項。

AR能夠找出架構中的壞味道，這種壞味道暗示著架構中的某部分對于目前的需求與約定來說已經不再適用，而這些需求比起從前可能已經產生了某種變 化。從這一層意義上說，AR是一種將經過深思熟慮的架構活動進行整理后的集合，它能夠去除某種特定的架構壞味道，能夠在不影響系統的范圍與功能的情況下， 對系統中至少一方面的質量特性加以改進。而由于矛盾的需求與權衡因素的存在，AR也可能會對其它質量特性帶來負面的影響。

在我看來，AR的過程就是對某個架構決策進行重新審視 ² ，并為某些設計問題的集合提供一種不同的解決方案。決策的執行牽涉到多個相關的工程任務，它們可以被歸類為以下幾種：

• 認識到某個設計中的結構性變化的任務。這種變化的范圍比起代碼重構更大，它需要與組件、子系統以及系統的系統（和它們的接口）打交道。
• 在開發與運維過程中的實現與配置任務（取決于AR的視角）。
• 文檔與交流任務，例如建模活動、技術寫作工作、或技術研討會的準備與促進。

表1. 某個架構重構（AR）的結構化表現。

我所設計的以決策和任務為中心的AR視圖是對Michael Stal的觀點的一種補充與擴展，他在2007年發表了關于AR的第一份目錄 ³ 。為了對他的AR進行文檔化，Stal使用了一種簡單的模式格式，其中包括三個部分：背景、問題與一般方案意見。他所描述的AR包括“打破依賴循環”以及“切分子系統”，分別對應了“依賴循環”與“功能切分不充分”這兩種架構上的壞味道 ⁴ 。

以任務為中心的模板的示例

Doodle.com的首席技術官在他們的博客上解釋了他們為什么要從MySQL遷移到MongoDB的原因，這是在他們的協作型在線日程設定服 務上線使用多年后所做出的一個決定。在這個案例中的架構壞味道在于，一旦SQL架構產生變化（例如在某張表中加入新的一列），對大型的生產環境中的數據庫 進行遷移的過程耗時極長。受到影響的質量特性包括開發與運維的生產力，以及數據庫和數據訪問層的性能與可伸縮性。而這種壞味道的癥結在于，關系型數據庫管 理系統本身就不是為了應對這種使用場景而設計的，雖然它們能夠勉強處理這種需求，但并非最佳選擇。

他們所采用的方案是對架構方面的決策進行重新審視，這些決策包括數據庫范式、查詢API以及數據庫provider。技術官最終決定使用面向文檔 的范式，這也是無架構的NoSQL技術中的其中一種，并使用MongoDB作為文檔數據庫的實現。這一變化改進了遷移管理的同時，也帶來了管理與代碼方面 的成本，他們需要為此編寫新的數據訪問、事務以及備份管理方面的新方案。

Doodle的示例體現了一次成功的AR，因為它通過對某個架構決策進行重新審視，改善了某方面的質量特性，而并不包括代碼的重構。表1以結構化 的方式展現了這個AR過程，使它更容易理解，并能夠應用到類似的項目中。這一示例也提供了一個AR文檔模板的建議，表1中的每一行都是模板中的一個條目。 圖1展示了模板結構的結果。

在使用表1中展現的模板對你自己的AR進行文檔化時，要注意AR名稱應當具有表達性，例如某種隱喻。與通常使用名詞的模式名稱不同，AR名稱應當 是動詞，例如在代碼重構過程中所使用的名稱。背景部分可以包含軟件工程方法中的抽象級別信息，或者是企業架構管理框架中的觀點。由于AR描述了一種設計上 的變化，因此可以提供兩種方案的簡介，即應用AR前的設計以及應用AR之后的設計。架構元素與結構化設計之間建立了一種鏈接，這種鏈接可以被顯式地建模、 非正式的描述或在代碼中進行隱式的表述。任務描述這部分可以引述敏捷計劃工具或軟件工程活動中的工作項。某些執行任務是可以被自動化的（正如在許多代碼重 構過程中的執行一樣），但并非所有任務都可以，因為AR是在一個更高的抽象層面的過程，它的范圍已超過了代碼重構。

圖1. 某個架構重構的解剖圖。左邊的部分展示了在某個特定上下文（例如視角或抽象級別）中觀察到的架構壞味道，這屬于某種質量特性（QA）方面的關注點。右邊的 部分簡述了經過重構后的架構，并確認了相關的設計、實現以及文檔任務。而需要重新審視的架構決策而扮演了這兩部分之間的粘合劑。

架構重構目錄

讓我們將目光放遠一點，來看看一些其它的AR。表2以兩個維度列舉了基本的AR，分別是架構的角度與變更的類型。這些AR可以被表示為圖1中的以任務為中心的模板實例。舉例來說，“引入緩存”這一任務的具體工作包括決定一個查找鍵、緩存失效策略、緩存的分布等等。

在今后，還有可能出現特定于某個領域與風格的AR目錄，可能會用于金融服務軟件、游戲開發或云計算。舉例來說，對于企業的應用現代化，以下三種AR都可以屬于這一目錄。

將會話狀態管理功能轉移（例如，從客戶端或中間服務器轉移至數據庫，以改善水平伸縮的能力，并更好地利用云的彈性）。

• 在某個服務接口契約中，使用數據遷移對象取代標量參數（以減少遠程調用的次數）。
• 簡化某個Web客戶端（以減少客戶端的負荷，增加它的處理能力）。
• 基本的AR與特定的AR都能夠提供一種跨社區的協作方式，協作雙方可以包括：
• 架構與開發。AR 的執行可能會包括一次或多次代碼重構的實踐，這部分工作也必須統一規劃。
• 架構與項目管理。根據AR模板所組織的AR描述可以作為計劃中的任務，對于AR的需求就意味著某種技術債的現形。
• 架構與運維（ArchOps）。從部署的角度來看，可以將AR視為一種溝通的方式。

表2. 視角、AR類型，以及對應的AR。

如何高效地共享并執行AR，這一點還有待觀察。模板與目錄是否能夠有效地承載這些知識，還是說建模與協作工具更適合于這一場景呢？基于Web交付 的知識具有天然的競爭力，這已經通過Wikipedia得到了證明。代碼重構任務可以通過閱讀書籍及正式的基礎著手，而重構工具（例如Eclipse中的 工具）是在很久之后才開發出來的，此時已經存在了豐富的內容，建立了完整的理論，人們也獲得了大量的經驗。對于AR工具的支持同樣需要與建模工具相配合， 這些建模工具能夠支持UML或架構描述語言，但這種支持能力目前還沒有看到。

致謝

感謝來自拉珀斯維爾的東瑞士應用科學大學的Christian Bisig與Mirko Stocker，他們對本文的原始版本進行了審校。同樣感謝曾出席我在OOP 2014與GI FG SWA 2014會議上的演講的聽眾，在演講中我介紹了對云服務進行架構重構的方式，他們的反饋對我幫助很大。

引用

1. M. Fowler于2004年9月1日所發表的博文“ 重構的定義 ”（Definition of Refactoring）。
2. O. Zimmermann于IEEE Software雜志2011年第28期第一卷中的64-69頁中的文章，“將架構決策視為可重用的設計資產” （Architectural Decisions as Reusable Design Assets）。
3. M. Stal于2007年發表的“ 軟件架構重構 ”（Software Architecture Refactoring）。
4. M. Stal與M. Babar、A. Brown、I. Mistrik、Morgan Kaufmann于2013年于敏捷軟件架構第一期所發表的“重構軟件架構”（Refactoring Software Architecture）。
5. P. Sevin?于2011年4月14日所發表的博文“ Doodle技術面面觀 ” （Doodle’s Technology Landscape）。

關于作者

Olaf Zimmermann 是拉珀斯維爾的東瑞士應用科學大學軟件協會的一名教授與合作伙伴，可以通過ozimmerm@hsr.ch聯系他。

本文最初 發表在 IEEE 軟件 雜志上， IEEE 軟件 雜志致力于發表嚴謹的、經過互相審校的文章，專注于當今世界的戰略科技。為了滿足運行可靠且靈活企業所面臨的挑戰，IT經理和技術管理者依賴IT Pro獲取最先進的解決方案。

查看英文原文： Architectural Refactoring: A Task-Centric View on Software Evolution