點擊鏈接閱讀原文，獲取更多技術內容：復用性風控：軟件復用成本的量化管理-阿里云開發者社區

本文分析「復用性」這一概念背后的風險及成因，借助筆者在業務安全和基礎安全的經驗，提出了一個在軟件研發流程中，管理「復用性成本風險」的風險管理模型，希望能為讀者在后續的技術決策和軟件研發流程提供些許幫助。

作者 | 齊光

來源 | 阿里云開發者公眾號

復用性（Reusability）是軟件工程中一個被頻頻使用的術語，它一般作為產品的賣點被宣傳，或者出現在技術設計文檔之中。大部分看到這個概念的的受眾只是將其作為一個積極的軟件非功能屬性去理解，但卻忽略了其背后隱藏的風險。本文從另一個角度出發，去分析「復用性」這一概念背后的風險及成因，借助筆者在業務安全和基礎安全的一點經驗，提出了一個在軟件研發流程中，管理「復用性成本風險」的風險管理模型。從模型出發，我們可以認識到實現復用時面臨的各項挑戰、開發認知謬誤、復用成本的形式化定義方法等，希望這些輸入能為讀者在后續的技術決策和軟件研發流程提供些許幫助。

本文主要分為三個部分：第一部分介紹復用性的定義以及不合理復用引入的主要技術債，第二部分分析復用性失效的原因；第三部分為復用性軟件資產的構建方和使用方提供一個形式化的度量工具，該工具將奠定后續風險管理模型評估階段定量分析的基礎；第四部分提出一個用于管理「復用性風險」的模型，覆蓋軟件研發生命周期的全流程，通過事前評估、事中緩釋和事后迭代三個環節最大程度地降低由于軟件復用帶來的軟件開發和維護成本。

一、復用性的理想與現實

1.1 復用定義：從代碼到系統

軟件復用是解決軟件質量和生產力問題的一種方法，它指的是在軟件開發過程中重復使用相同或相似的軟件元素。通過合理利用軟件復用技術，我們可以提高開發效率，并且降低開發過程中的錯誤率。同時，軟件復用還可以促進團隊協作和知識共享，使得開發者們能夠更好地利用彼此的經驗和資源。因此，在當今快節奏的開發環境中，軟件復用已經成為提高生產力和質量的關鍵策略之一。在過去幾十年的時間里，很多編程語言的成功（Python、Java 等）和開源文化的蓬勃發展，都與復用密不可分。

軟件復用可以在不同粒度上進行，包括代碼和設計拷貝、源代碼復用、設計和軟件體系結構復用以及領域特定的軟件體系結構復用等。早期的軟件復用主要集中在代碼級別，例如共享方法、抽象類、庫、微服務和Docker鏡像等。隨著時間推移，其外延拓展至領域知識、開發經驗、設計文檔、需求分析和測試用例及數據等在不同階段所產生的各種軟件產品。在本文中，除非特別說明，復用性主要指的就是聚焦代碼的復用，下文中的「組件復用」，不僅限于通常我們認知中的公共庫，還包括代碼方法、公共類、軟件框架、可集成系統等軟件開發中的可復用元素。

1.2 復用風險：復雜度和成本

誠然，通過組件的復用可以提高軟件開發效率和質量，但復用不是銀彈，復用也會有一些副作用：

1.兼容性/安全性/性能；

2.增加了系統間的依賴；

3.增加了開發和維護成本。

首先，兼容性/安全性/性能等這幾類問題，是針對可復用組件的使用方來說的，一般來說，在決策是否復用之前就可以評估，其指標和過程也比較清晰，這里就不具體展開了。?

其次，復用會增加系統依賴。依賴關系是軟件的基本組成部分，無法消除，但軟件設計的目標之一是盡可能消除依賴關系，并使依賴關系盡可能簡單和明顯。當我們引入外部組件進行復用時，軟件組件之間的依賴關系會導致組件變更范圍的擴大以及組件認知負荷的增加，前者是針對組件維護方而言的，即看似簡單的變更需要在許多不同的地方修改代碼，隨著消費者數量的增長，在不同需求之間進行平衡變得越來越困難；后者是對于組件使用方而言的，即開發人員需要了解大量組件領域知識才能實現有效的組件復用。

比如，需要了解待使用接口中若干入參的設計意圖、是否存在隱式依賴傳遞從而導致依賴沖突等。依賴的增加會為系統引入更多的復雜性，而我們知道，構建軟件系統的核心挑戰就是管理復雜性，復用組件只會在一定程度上轉移復雜性，但并不能消除復雜性。因此，我們需要在「復用組件降低成本」和「復用組件引入依賴（復雜性）」之間取得平衡。

最后，復用會增加各項成本。包括開發的成本、變更的成本、集成的成本、領域知識遷移的成本。對于一個面向復用設計的組件來說，實現正確抽象和通用框架的設計和開發成本，比一次性的解決方案高得多，對于組件的后續維護者來說，這樣的可復用框架和庫通常也會帶來陡峭的學習曲線（因為文檔一般是缺失的），組件會逐漸走向腐化，最后不得不推倒重來。此外，對于可復用組件的使用方來說，其理解和集成組件的成本通常也是被忽略的，一些強推的業務層的「偽復用框架」給前臺集成的同學帶來了巨大的集成、學習和維護成本。

上述復用帶來問題，有一些是可以規避的，如兼容性、性能、容量等的匹配度，有一些是無法避免的，如設計通用化組件的開發成本、不合理的抽象導致的代碼腐化、不合理的復用導致的維護成本等。事實上，無論我們在技術上做多么精妙的設計，技術的創新永遠滯后于系統的腐化速度。?

為了最大程度的降低復用帶來的風險，本文提出一套從類比于安全風險管理的「復用性風險」應對模型，從事前評估、事中緩釋、事后迭代三個階段出發，最大程度地降低我們在開發可復用組件、使用可復用組件中遇到的各類風險。需要說明的是，上面以及后面指的「復用性風險」，定義為「由于不合理的復用決策，導致依賴和復雜度膨脹過快，從而導致軟件維護成本過高」的問題，除了成本風險外，由于復用組件的不合理使用或存在的缺陷而導致的兼容性、安全性、性能等方面的風險，其風險更為顯著和易于治理，因此不是本文論述的重點。此外，復用開發過程中的開發目標偏移、迭代和發布計劃的延期、人員短缺等風險，限于篇幅也不在這里展開。

第二部分首先會介紹導致「復用提升軟件開發效率」這一原則失效的幾類主要原因，第三部分會重點介紹用于評估復用性的若干工具，有了對復用性本質的認識后，再第四部分我們會簡要介紹復用性風險管理模型。

二、復用性風險根因分析

2.1 現實挑戰：正確和錯誤的抽象

我們復用組件的一個初衷，除了是為了提升研發效率之外，也是希望可復用組件可以將領域的復雜性隔離在一個我們永遠看不到的地方，從而整體降低組件使用方的系統復雜度。因此，一個可復用的組件，無論其規模大小，其設計過程就是對某個領域高度抽象的過程。在設計組件時，向上面對當前或潛在的需求，需要我們做一定的前向通用設計，向下盡可能屏蔽掉組件的實現細節，抽象的結果直接決定了后續該組件可復用性程度的高低（可復用性的度量將在下一個章節詳述）。但遺憾的是，良好的抽象能力對于大部分開發者來說是一個稀缺的產物，它需要對問題進行清晰的定義、簡化和分解，同時識別和利用通用模式，將子問題的解法組合起來形成一個整體解決方案，依賴對設計模式、開源的庫和框架、數據結構和算法以及大量生產項目的長期實踐和思考。

在日常的代碼中，我們不乏抽象，但大部分都是不合理的抽象。錯誤的抽象造成的危害甚于不抽象，比如常見的一個現象：對設計模式的適用范圍知之甚少，僅僅為了炫技而濫用設計模式，導致代碼的可讀性和可維護性下降。

除了對抽象能力的要求外，很多時候需求緊迫度、開發資源、責任心以及組件所在領域職責的變更等因素，都會導致可復用組件從出生就帶著「高成本」的原罪，其后續的使用成本和維護成本會急劇上升，這里就不一一展開了。

2.2 認知謬誤：復用不是設計目標

一個對于復用性的認知謬誤就是，把「不重復」等效為「復用」，這兩個概念之間有相似之處，但還是有一些微妙的差別。「不重復」即我們所熟知的 DRY 原則（Don’t Repeat Yourself），其目標是通過減少重復建設從而避免承擔副本不一致的維護成本，而 Reusability 是從所有代碼中找到重復的部分，然后在復雜度可控的前提下，努力抽象出可復用的東西。一堆不重復的代碼，并不代表存在可復用的組件。

復用只是實現不重復目標的一種手段，「不重復」才是我們設計軟件系統時的目標，單純追逐「復用性」很多時候會出現一些本末倒置的現象。如出現了一些接入成本非常高的自動測試框架、業務中臺框架，一味追逐「（我）一次開發，（你）隨處使用」，殊不知在使用方需要消耗大量的精力去內化框架設計者的設計初衷，面對十幾個接入參數或配置文件一籌莫展。

舉個例子，偶爾會看到我們在業務層代碼中，部分同學會把簡單的新增和修改邏輯抽象為一個方法，美其名曰「提供給接入層復用」，如下面的 insertOrUpdate 方法中，初看是復用了領域對象轉換和用戶對象是否存在的代碼，符合 DRY 原則，但實際上卻是混用了兩個不同的業務語義，會給后續的維護帶來較高的成本，如變更用戶信息時，需要做更個性化的用戶屬性處理，這時候調整領域對象轉換處的代碼，將會影響新增邏輯。

更合理的實現是，將明顯不同語義的代碼進行拆分，雖然看上去存在一定程度上的代碼重復，但其設計會更利于后續的功能迭代，也更符合代碼的「單一職責」設計原則。

2.3 決策偏差：復用的決策權在哪

代碼的復用更多的時候是軟件開發者自發完成的，但我們無法忽視的一點是，如何集成、是否復用、如何復用、是否是同一個功能、使用什么粒度的復用，很多時候是由業務架構決定的，「康威定律」還是無法回避的。

比如，在一個新的場景里，產品要求把「PPT 上與其名字相同的一個功能」進行復用，以快速上線，雖然他們除了名字相同，其產品形態、業務流程、環境依賴等都不一樣。最終強行「復用」的結果就是代碼邏輯里出現了大量的分支判斷，底層技術架構變得臃腫。由于對于領域的理解不同，出現這種情況在所難免。雖然很多時候軟件復用的決策權并不在開發者這里，但出于技術情懷也好，責任心也罷，開發者有義務去做這種糾偏，最大程度地消除這種差異性。但需要認識到技術的作用在這里并不是決定性的，卓越的技術是復用成功的必要非充分條件。

2.4 工具缺失：如何計算復用成本

復用性度量，主要分為兩個部分：

1.復用度：決定一個組件復用性高低水平的因素有哪些？

2.復用成本：組件集成方、組件所在的組織，決定實行復用策略后的 ROI 如何計算？

通過復用度和復用成本兩個指標，我們可以進行一定程度上的復用性定量分析，做出更為長遠的技術決策。比如，可以了解到一個復用性高的組件，其特征有哪些？引入一個新的第三方組件時，除了基礎的功能性組件外，我還需要考慮哪些？相較于使用已經存在的組件，是否考慮重新造一個輪子？「復用」和「造輪子」間成本有多大？關于復用性的度量工具，第三部分將重點論述。

三、復用性的形式化度量

3.1 組件度量：可復用水平的評估

我們在設計一段代碼/一個類/一個模塊等可復用的組件時，一些可衡量的軟件指標共同決定了組件的可復用性水平的高低。這些指標包括：可靠性（Reliability）、可讀性（Understandability）、可維護性（Maintainability）、通用性（Generality）與可遷移性（Portability），如下圖所示。每一個指標可由各類代碼度量屬性決定，如組件的可遷移性由「組件的獨立性」和「耦合性」兩個屬性決定，大部分的度量屬性都是可以通過形式化定義并計算出來。不同指標的決定因子及度量值（括號中）如下：

1.可靠性：性能（響應時間）、容錯程度（恢復時間）；

2.通用性：類泛化水平（子類實例個數或接口實現類個數）；

3.可讀性：內聚性（類之間耦合度）、復雜度（圈復雜度）、規模（代碼行數）、文檔水平（數量 完整度）；

4.可維護性：易于修改、單測和回歸測試（測試覆蓋度）、組件的獨立性（依賴數）、耦合性（類間耦合度）；

5.可遷移性：組件的獨立性（依賴數）、耦合性（類間耦合度）。

為了度量整個組件的的可復用性，有必要定義一個可復用性計算模型。該模型基于上圖所示的復用性屬性模型。主要的可復用性屬性、影響這些屬性的因素以及度量這些因素的量度之間的關系顯示在這個模型中。理論上，軟件組件的可復用性(用 Reusability 表示)可以用表達式來計算：

Reusability = w1*M w2*R w3*P w4*U w5*G

?其中 w1 ~ w5 為不同指標的權重值，指標 M（Maintainability）、R（Reliability）、P（Portability）、U（Understandability）、G（Generality） 值進行歸一化（0 … 1）后，乘以每個指標不同的權重值，通過計算得到最終的組件的可復用度。

在上面的分析過程中，存在部分度量無法進行定量分析的情況，但不同因子組合計算還是有意義的，我們可以拿這些指標去評估我們目前的系統，存在的問題的嚴重程度。當下次別人問我們為什么要復用組件A而不是組件B時，我們可以給出更令人信服的理由，而不僅僅是「我覺得」、「A比B好很多」等論述。

3.2 組織度量：復用的投入產出比

對組件的復用性有了一個感性認知后，更加一步地，讓我們從經濟的角度去思考復用性背后的成本問題。首先，我們先定義幾個變量 RL、NUC、RCR、RCWR。

• RL（Reuse Level）：可復用組件在應用中的比例，即 RL=復用的組件中代碼行數/應用總的代碼行數；
• NUC（Not Use Cost）：應用開發過程中完全不使用可復用組件的成本，注意不包括后續的維護成本；
• RCR（Relative Cost of Reuse）：復用既有的組件與重新造一個相似的輪子，這兩者之間工作量的比值，一般在0.03~0.4之間，經驗值為20%，即這意味著復用所花費的成本大約是編寫新組件所投入的20%；
• RCWR（Relative Cost of Writing for Reuse）：開發可復用的組件與開發一次性使用的模塊，這兩者之間工作量的比值，一般在1.0~2.2之間，經驗值為 1.5，即這意味著編寫可復用軟件需要大約50%的額外成本。

內容剩余60%，完整內容可點擊下方鏈接查看：復用性風控：軟件復用成本的量化管理-阿里云開發者社區

阿里云開發者社區，千萬開發者的選擇。百萬精品技術內容、千節免費系統課程、豐富的體驗場景、活躍的社群活動、行業專家分享交流，盡在：阿里云開發者社區-云計算社區-阿里云