架构重构：通过以任务为中心的视角看软件的进化
本文最初發(fā)表在IEEE軟件雜志上，IEEE軟件雜志致力于發(fā)表嚴謹?shù)摹⒔?jīng)過互相審校的文章，專注于當今世界的戰(zhàn)略科技。為了滿足運行可靠且靈活企業(yè)所面臨的挑戰(zhàn)，IT經(jīng)理和技術(shù)管理者依賴IT Pro獲取最先進的解決方案。
\\\\軟件密集型的系統(tǒng)經(jīng)常會因為各種各樣的原因而必須進行重新設(shè)計，例如某個不可預(yù)知的業(yè)務(wù)變動或是技術(shù)上的創(chuàng)新。許多重新設(shè)計活動會對這些系統(tǒng)的軟件架構(gòu)產(chǎn)生影響，代碼重構(gòu)就是一種流行的重新設(shè)計實踐。考慮到代碼成功這一實踐的巨大成功，這使人們對于架構(gòu)重構(gòu)（AR）這種實踐的沉默感到有些吃驚。為了糾正這一情形，我將在本文中為讀者展示，作為一種軟件進化技術(shù)，AR如何重新審視架構(gòu)決策，并確認相關(guān)的設(shè)計、實現(xiàn)及文檔任務(wù)。
\\介紹架構(gòu)重構(gòu)
\\重構(gòu)的目的是在改善某部分質(zhì)量的同時保持其它部分不變，舉例來說，代碼重構(gòu)實踐對代碼的結(jié)構(gòu)進行了重新調(diào)整，以增強代碼的可維護性，同時又保持它的可觀察行為不變。代碼重構(gòu)實踐是與機器可讀的實體進行打交道，例如包、類以及方法，讓這些實體能夠在編譯器構(gòu)造階段利用各種數(shù)據(jù)結(jié)構(gòu)，例如抽象語法樹1。而AR則是與架構(gòu)文檔和架構(gòu)知識在代碼與運行時產(chǎn)品中所表現(xiàn)出的行為打交道。因此，不存在一種單一的架構(gòu)語法樹。AR的范疇包括：
\\- 組件與連接器（經(jīng)過建模、描繪或在代碼中隱式地表現(xiàn)出來），\\t
- 設(shè)計決策的記錄（以結(jié)構(gòu)化和非結(jié)構(gòu)化的文本表現(xiàn)），以及\\t
- 計劃階段的產(chǎn)物，例如項目管理工具中的工作項。\
AR能夠找出架構(gòu)中的壞味道，這種壞味道暗示著架構(gòu)中的某部分對于目前的需求與約定來說已經(jīng)不再適用，而這些需求比起從前可能已經(jīng)產(chǎn)生了某種變化。從這一層意義上說，AR是一種將經(jīng)過深思熟慮的架構(gòu)活動進行整理后的集合，它能夠去除某種特定的架構(gòu)壞味道，能夠在不影響系統(tǒng)的范圍與功能的情況下，對系統(tǒng)中至少一方面的質(zhì)量特性加以改進。而由于矛盾的需求與權(quán)衡因素的存在，AR也可能會對其它質(zhì)量特性帶來負面的影響。
\\在我看來，AR的過程就是對某個架構(gòu)決策進行重新審視2，并為某些設(shè)計問題的集合提供一種不同的解決方案。決策的執(zhí)行牽涉到多個相關(guān)的工程任務(wù)，它們可以被歸類為以下幾種：
\\- 認識到某個設(shè)計中的結(jié)構(gòu)性變化的任務(wù)。這種變化的范圍比起代碼重構(gòu)更大，它需要與組件、子系統(tǒng)以及系統(tǒng)的系統(tǒng)（和它們的接口）打交道。\\t
- 在開發(fā)與運維過程中的實現(xiàn)與配置任務(wù)（取決于AR的視角）。\\t
- 文檔與交流任務(wù)，例如建模活動、技術(shù)寫作工作、或技術(shù)研討會的準備與促進。\
| \\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 從功能性的觀點與信息的觀點這兩者的角度對概念級別（數(shù)據(jù)庫范式）以及資產(chǎn)級別（MySQL與MongoDB）進行抽象。 \\t\t\t |
| \\t\t\t 項目干系人的關(guān)注點 \\\t\t\t\\\t\t\t該AR會影響到哪些非功能性需求以及約束（包括質(zhì)量特性及設(shè)計外力）？ \\t\t\t | \\t\t\t 靈活性（從數(shù)據(jù)模型變更的角度）、數(shù)據(jù)完整性，以及遷移時間。 \\t\t\t |
| \\t\t\t 架構(gòu)壞味道 \\\t\t\t\\\t\t\t在何時，以及為什么要考慮該AR？ \\t\t\t | \\t\t\t 當數(shù)據(jù)模型（數(shù)據(jù)庫架構(gòu)）產(chǎn)生變動時，將現(xiàn)有的數(shù)據(jù)庫內(nèi)容進行遷移所需的時間太長。 \\t\t\t |
| \\t\t\t 需要重新審視的架構(gòu)決策 \\\t\t\t與該AR相關(guān)的設(shè)計問題有哪些，目前采取了哪些設(shè)計方式以處理這些問題？ \\t\t\t | \\t\t\t
|
| \\t\t\t 改進輪廓 （解決方案的簡介） \\\t\t\t現(xiàn)在應(yīng)當選擇哪些設(shè)計選項？ \\\t\t\t解決方案的目標看起來是怎樣的？ \\t\t\t | \\t\t\t
|
| \\t\t\t 受影響的架構(gòu)元素 \\\t\t\t哪些設(shè)計模型元素必須進行改動（例如被顯式建模的組件與連接器）？ \\t\t\t | \\t\t\t
|
| \\t\t\t 執(zhí)行任務(wù) \\\t\t\t如何應(yīng)用并驗證該AR？ \\t\t\t | \\t\t\t
|
表1. 某個架構(gòu)重構(gòu)（AR）的結(jié)構(gòu)化表現(xiàn)。
\\我所設(shè)計的以決策和任務(wù)為中心的AR視圖是對Michael Stal的觀點的一種補充與擴展，他在2007年發(fā)表了關(guān)于AR的第一份目錄3。為了對他的AR進行文檔化，Stal使用了一種簡單的模式格式，其中包括三個部分：背景、問題與一般方案意見。他所描述的AR包括“打破依賴循環(huán)”以及“切分子系統(tǒng)”，分別對應(yīng)了“依賴循環(huán)”與“功能切分不充分”這兩種架構(gòu)上的壞味道4。
\\以任務(wù)為中心的模板的示例
\\Doodle.com的首席技術(shù)官在他們的博客上解釋了他們?yōu)槭裁匆獜腗ySQL遷移到MongoDB的原因，這是在他們的協(xié)作型在線日程設(shè)定服務(wù)上線使用多年后所做出的一個決定。在這個案例中的架構(gòu)壞味道在于，一旦SQL架構(gòu)產(chǎn)生變化（例如在某張表中加入新的一列），對大型的生產(chǎn)環(huán)境中的數(shù)據(jù)庫進行遷移的過程耗時極長。受到影響的質(zhì)量特性包括開發(fā)與運維的生產(chǎn)力，以及數(shù)據(jù)庫和數(shù)據(jù)訪問層的性能與可伸縮性。而這種壞味道的癥結(jié)在于，關(guān)系型數(shù)據(jù)庫管理系統(tǒng)本身就不是為了應(yīng)對這種使用場景而設(shè)計的，雖然它們能夠勉強處理這種需求，但并非最佳選擇。
\\他們所采用的方案是對架構(gòu)方面的決策進行重新審視，這些決策包括數(shù)據(jù)庫范式、查詢API以及數(shù)據(jù)庫provider。技術(shù)官最終決定使用面向文檔的范式，這也是無架構(gòu)的NoSQL技術(shù)中的其中一種，并使用MongoDB作為文檔數(shù)據(jù)庫的實現(xiàn)。這一變化改進了遷移管理的同時，也帶來了管理與代碼方面的成本，他們需要為此編寫新的數(shù)據(jù)訪問、事務(wù)以及備份管理方面的新方案。
\\Doodle的示例體現(xiàn)了一次成功的AR，因為它通過對某個架構(gòu)決策進行重新審視，改善了某方面的質(zhì)量特性，而并不包括代碼的重構(gòu)。表1以結(jié)構(gòu)化的方式展現(xiàn)了這個AR過程，使它更容易理解，并能夠應(yīng)用到類似的項目中。這一示例也提供了一個AR文檔模板的建議，表1中的每一行都是模板中的一個條目。圖1展示了模板結(jié)構(gòu)的結(jié)果。
\\在使用表1中展現(xiàn)的模板對你自己的AR進行文檔化時，要注意AR名稱應(yīng)當具有表達性，例如某種隱喻。與通常使用名詞的模式名稱不同，AR名稱應(yīng)當是動詞，例如在代碼重構(gòu)過程中所使用的名稱。背景部分可以包含軟件工程方法中的抽象級別信息，或者是企業(yè)架構(gòu)管理框架中的觀點。由于AR描述了一種設(shè)計上的變化，因此可以提供兩種方案的簡介，即應(yīng)用AR前的設(shè)計以及應(yīng)用AR之后的設(shè)計。架構(gòu)元素與結(jié)構(gòu)化設(shè)計之間建立了一種鏈接，這種鏈接可以被顯式地建模、非正式的描述或在代碼中進行隱式的表述。任務(wù)描述這部分可以引述敏捷計劃工具或軟件工程活動中的工作項。某些執(zhí)行任務(wù)是可以被自動化的（正如在許多代碼重構(gòu)過程中的執(zhí)行一樣），但并非所有任務(wù)都可以，因為AR是在一個更高的抽象層面的過程，它的范圍已超過了代碼重構(gòu)。
\\ \\圖1. 某個架構(gòu)重構(gòu)的解剖圖。左邊的部分展示了在某個特定上下文（例如視角或抽象級別）中觀察到的架構(gòu)壞味道，這屬于某種質(zhì)量特性（QA）方面的關(guān)注點。右邊的部分簡述了經(jīng)過重構(gòu)后的架構(gòu)，并確認了相關(guān)的設(shè)計、實現(xiàn)以及文檔任務(wù)。而需要重新審視的架構(gòu)決策而扮演了這兩部分之間的粘合劑。
\\架構(gòu)重構(gòu)目錄
\\讓我們將目光放遠一點，來看看一些其它的AR。表2以兩個維度列舉了基本的AR，分別是架構(gòu)的角度與變更的類型。這些AR可以被表示為圖1中的以任務(wù)為中心的模板實例。舉例來說，“引入緩存”這一任務(wù)的具體工作包括決定一個查找鍵、緩存失效策略、緩存的分布等等。
\\在今后，還有可能出現(xiàn)特定于某個領(lǐng)域與風格的AR目錄，可能會用于金融服務(wù)軟件、游戲開發(fā)或云計算。舉例來說，對于企業(yè)的應(yīng)用現(xiàn)代化，以下三種AR都可以屬于這一目錄。
\\將會話狀態(tài)管理功能轉(zhuǎn)移（例如，從客戶端或中間服務(wù)器轉(zhuǎn)移至數(shù)據(jù)庫，以改善水平伸縮的能力，并更好地利用云的彈性）。
\\- 在某個服務(wù)接口契約中，使用數(shù)據(jù)遷移對象取代標量參數(shù)（以減少遠程調(diào)用的次數(shù)）。\\t
- 簡化某個Web客戶端（以減少客戶端的負荷，增加它的處理能力）。\\t
- 基本的AR與特定的AR都能夠提供一種跨社區(qū)的協(xié)作方式，協(xié)作雙方可以包括：\\t
- 架構(gòu)與開發(fā)。AR的執(zhí)行可能會包括一次或多次代碼重構(gòu)的實踐，這部分工作也必須統(tǒng)一規(guī)劃。\\t
- 架構(gòu)與項目管理。根據(jù)AR模板所組織的AR描述可以作為計劃中的任務(wù)，對于AR的需求就意味著某種技術(shù)債的現(xiàn)形。\\t
- 架構(gòu)與運維（ArchOps）。從部署的角度來看，可以將AR視為一種溝通的方式。\
表2. 視角、AR類型，以及對應(yīng)的AR。
\\如何高效地共享并執(zhí)行AR，這一點還有待觀察。模板與目錄是否能夠有效地承載這些知識，還是說建模與協(xié)作工具更適合于這一場景呢？基于Web交付的知識具有天然的競爭力，這已經(jīng)通過Wikipedia得到了證明。代碼重構(gòu)任務(wù)可以通過閱讀書籍及正式的基礎(chǔ)著手，而重構(gòu)工具（例如Eclipse中的工具）是在很久之后才開發(fā)出來的，此時已經(jīng)存在了豐富的內(nèi)容，建立了完整的理論，人們也獲得了大量的經(jīng)驗。對于AR工具的支持同樣需要與建模工具相配合，這些建模工具能夠支持UML或架構(gòu)描述語言，但這種支持能力目前還沒有看到。
\\致謝
\\感謝來自拉珀斯維爾的東瑞士應(yīng)用科學(xué)大學(xué)的Christian Bisig與Mirko Stocker，他們對本文的原始版本進行了審校。同樣感謝曾出席我在OOP 2014與GI FG SWA 2014會議上的演講的聽眾，在演講中我介紹了對云服務(wù)進行架構(gòu)重構(gòu)的方式，他們的反饋對我?guī)椭艽蟆?/p>\\
引用
\\關(guān)于作者
\\Olaf Zimmermann是拉珀斯維爾的東瑞士應(yīng)用科學(xué)大學(xué)軟件協(xié)會的一名教授與合作伙伴，可以通過ozimmerm@hsr.ch聯(lián)系他。
\\\\本文最初發(fā)表在IEEE軟件雜志上，IEEE軟件雜志致力于發(fā)表嚴謹?shù)摹⒔?jīng)過互相審校的文章，專注于當今世界的戰(zhàn)略科技。為了滿足運行可靠且靈活企業(yè)所面臨的挑戰(zhàn)，IT經(jīng)理和技術(shù)管理者依賴IT Pro獲取最先進的解決方案。
\\\\查看英文原文：Architectural Refactoring: A Task-Centric View on Software Evolution
總結(jié)
以上是生活随笔為你收集整理的架构重构：通过以任务为中心的视角看软件的进化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 抓住那头牛（宽搜bfs）
- 下一篇： 大学这么多比赛，我该参加哪个？