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

weixin_33806914發表於2015-08-12

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

\\\\

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

介紹架構重構

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

元件與聯結器（經過建模、描繪或在程式碼中隱式地表現出來），\\t
設計決策的記錄（以結構化和非結構化的文字表現），以及\\t
計劃階段的產物，例如專案管理工具中的工作項。\

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

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

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

\\t\t\t AR名稱 \\\t\t\t\\\t\t\t 如何能夠輕易地認出某個AR並進行引用？ \\t\t\t	\\t\t\t SQL \\t\t\t
\\t\t\t 背景 \\\t\t\t\\\t\t\t 該AR適用於的場景（以及所處的條件）是什麼？ \\t\t\t	\\t\t\t 從功能性的觀點與資訊的觀點這兩者的角度對概念級別（資料庫正規化）以及資產級別（MySQL與MongoDB）進行抽象。 \\t\t\t
\\t\t\t 專案干係人的關注點 \\\t\t\t\\\t\t\t 該AR會影響到哪些非功能性需求以及約束（包括質量特性及設計外力）？ \\t\t\t	\\t\t\t 靈活性（從資料模型變更的角度）、資料完整性，以及遷移時間。 \\t\t\t
\\t\t\t 架構壞味道 \\\t\t\t\\\t\t\t 在何時，以及為什麼要考慮該AR？ \\t\t\t	\\t\t\t 當資料模型（資料庫架構）產生變動時，將現有的資料庫內容進行遷移所需的時間太長。 \\t\t\t
\\t\t\t 需要重新審視的架構決策 \\\t\t\t 與該AR相關的設計問題有哪些，目前採取了哪些設計方式以處理這些問題？ \\t\t\t	\\t\t\t 資料建模的正規化的選擇（目前的決定是關係型資料）\\t\t\t\t 元模型及查詢語言的選擇（目前的決定是SQL）\\t\t\t\t 資料庫管理系統的選擇（目前的決定是MySQL）\\t\t\t
\\t\t\t 改進輪廓（解決方案的簡介） \\\t\t\t 現在應當選擇哪些設計選項？ \\\t\t\t 解決方案的目標看起來是怎樣的？ \\t\t\t	\\t\t\t 使用面向文件的資料庫，例如MongoDB以取代關係型資料庫，例如MySQL。\\t\t\t\t 對事務管理與資料庫管理進行重新設計。\\t\t\t
\\t\t\t 受影響的架構元素 \\\t\t\t 哪些設計模型元素必須進行改動（例如被顯式建模的元件與聯結器）？ \\t\t\t	\\t\t\t 資料庫層（包括伺服器程式、備份與恢復功能）。\\t\t\t\t 資料訪問層（例如命令與查詢的模式，以及連線池）。\\t\t\t
\\t\t\t 執行任務 \\\t\t\t 如何應用並驗證該AR？ \\t\t\t	\\t\t\t 設計文件佈局（需要機器可讀的SQL資料定義語言）。\\t\t\t\t 編寫一個新的資料訪問層，並在應用中實現類SQL的查詢功能。\\t\t\t\t 決定事務邊界（如果存在的話）。\\t\t\t\t 對資料庫管理變更進行文件化（例如命令列查詢、更新指令碼以及備份過程）。\\t\t\t\t 根據成功標準（例如遷移時間與資料訪問層的效能），對新舊兩套方案進行對比。\\t\t\t

表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都可以屬於這一目錄。

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

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

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

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

致謝

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

引用

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

關於作者

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