今晚準備在家做飯，但少了一把菜刀，你會問鄰居家借麼？

複用的成本

DRY原則（Don't Repeat Yourself）相信每一位程式設計師都應該知道。其指代的是我們寫程式時，不要一遍又一遍地編寫相似的程式碼。

當出現某些相似功能的程式碼時，我們應該將通用部分程式碼與特異部分程式碼分離，以達到複用通用程式碼，降低整體複雜度的目的。

按照我的理解裡，一個好的程式，壓縮率應該接近於0,沒有任何可以精簡的部分（變數名、方法名等除外）

複用帶來很多好處，如：

• 利用已有資源快速開發
• 程式碼更清晰易懂
• 程式碼可以統一修改管控
• 資料可以統一分析利用
• 降低系統整體複雜度

然而達到複用的目的並非沒有成本，從整體上看 複用的成本包含：

• 發現可複用邏輯的成本
• 學習可複用邏輯的成本
• 擴充套件可複用邏輯的成本
• 修改可複用邏輯的成本

如果整個系統是SOLO的，那麼發現和學習的成本近乎於0（前提是你還記得你寫過什麼東西），進行復用只包含擴充套件和修改程式碼的成本。

但一個系統可能很大，完成系統所需的人數可能是：

• 幾個人的小組
• 幾十個人的室
• 幾百人的部門
• 幾千人的公司
• 幾萬人的集團

當我們能在公司級或者集團級較好地處理複用這件事件時，我們就稱其為 中臺（當然，部門中臺、室中臺也可以，只是複用在企業級別時換個名稱顯得更高大上）

但讓我們回想一下自己所在的小組裡，已經處理掉了重複程式碼，達到了完美的複用了麼？如果已經完美複用了，那你所在的室呢？

我們發現，隨著人數的增加以及程式碼數量的增加，未經過良好設計及組織，發現及使用可複用程式碼的難度將會急劇增加。

同時，若複用發生在利益關係不一致的不同組織（室、部門、公司、集團）裡，則複用不一定能被執行。即使複用可以執行，但需求方與提供方對任務的優先順序定義不一致，提供方響應速度跟不上時，那也可能使得複用無法產生。

實現DRY可能只需要一個優秀的程式設計師，但實現Don't Repeat Ourselve就沒這麼簡單了。

對於需求方團隊是否要複用某個其他團隊的元件，可以由一個公式來表示：

實現複用所需時間 <= 業務允許的響應時間 
AND
（發現成本 + 學習成本 + 溝通協調成本 + 使用成本）  <= 重新做的成本
 

當上述表示式為“真”，那麼我們就可以考慮複用。

下面針對這個公式，進行分段討論。

實現複用所需的時間

複用並不是總能節約開發時間：

• 發現可複用元件需要時間
• 學習可複用元件需要時間
• 可複用元件准入需要時間
  • 使用本公司的元件服務所需的流程制度
  • 使用其他公司的元件服務所需的商務合作的溝通
• 可複用元件的擴充套件需要時間
• 可複用元件的修改需要時間
  • 複用元件需要經過多個業務驗證才能達到一個較為穩定的狀態，在此之前業務協助可複用元件演化需要更多的時間
  • 可複用元件的維護團隊可能跟使用者團隊的利益關係不一致，導致修改的優先順序更低

影響複用達成時間的因素很多，這些因素疊加起來可能導致複用所消耗的時間更多。因此對於一些時間特別敏感、由其決定生死的業務，在可複用元件未成熟，或者可複用元件支援團隊的支援力度不夠時，可以不考慮複用。

不復用的情況就是我們通常講的煙囪系統，現在大環境的論調是煙囪系統不好，其在一個業務成熟的公司裡確實不好。但是煙囪系統在業務早期變化大，快速野蠻生長時,由於不需要考慮複用,沒有太多的條條框框限制,提供了高效的開發效率支援，為業務的存活做了重要貢獻。

複用的發現成本

是什麼影響了複用的發現成本？我認為主要是：

• 發現複用的方式

在幾個人的小組維護的系統裡，我們傾向於不產生任何重複程式碼。在實現某些功能時，需要確定有沒有已有的列舉、類、方法、DAO時我們會問小組長，或者直接在小群裡吼一聲。

在幾十個人的室裡，我們小組要用其他小組系統的介面時，通常會由小組負責人之間拉會議溝通協調，確認對應介面是否存在，是否合適，如何使用，改造方案等。

這些發現都依賴於人，但而人的記憶是不可靠的，可能會遺忘記錯，並且一旦涉及到人之間的交流的話，效率就會降低（要打斷對方工作、等對方迴應、要組織會議等）。因此我們要降低複用發現成本最好的方式是降低對人的依賴。

單一系統的複用發現方式

降低單一系統（單個git repo/單個eclipse專案）的複用發現成本的一種做法就是合理分包，在寫好程式碼的同時，就把複用發現的手段給完善了。

一個合理分包的程式碼裡，我們能夠快速地推斷出我們所需要的東西在哪裡、是否存在。

而一個不合理分包的程式碼，我們會看到幾十上百個類平鋪於一個層級，用人眼根本找不到想要的類，必須依靠記憶中依稀記得的關鍵字來進行搜尋。

那怎麼做到合理分包？很簡單，只要保持一個簡單的原則

每個包的檔案數量不超過10個，若超過10個則分裂成兩到三個子包

但當然，包的名字必須是有含義且一眼能看明白的，這樣才能讓我們逐層找到我們要的檔案。這其實是一種通用的控制複雜度的方法，可見文末另外一篇文章《從分治的思想到架構的設計》

降低多系統間複用發現成本

降低多個系統間複用發現成本的一種做法是搭建一個WEB系統用於統一發現可複用元件。

這個管理系統應該可以按照分類逐層查詢複用元件，也可以按照關鍵字查詢對應的複用元件。阿里雲官方網站我們可以作為一種參考。

但當然，構造這麼一個系統也是需要消耗大量人力物力的，在初期使用Wiki+Swagger的形式將介面資訊提供出去也是不錯的選擇。

學習的成本

一個介面學習的成本大小與介面大小成正比。

介面大小指代要正確使用該介面所需具備的知識，如：

• 所需的引數數量
• 使用的前置條件
• 隱含的坑
• ......

這些知識，我們也可以稱其為“耦合”。

我們知道，耦合要越小越好，這樣才能讓通過介面互動的兩個模組更容易地獨立演進。

同時，耦合越小，我們學習這個介面的成本就越小。

當然，影響學習的成本除了介面自身要良好設計之外，還需要完善的文件與例子，這也是降低學習成本的關鍵。

溝通協調成本

複用的溝通協調成本在越大的組織裡有可能越大。

被複用的元件需要進行修改定製時，我們需要元件的維護方提供支援，此時就需要相應的溝通協調成本。

若元件提供方與元件使用方沒有任何利益關係，甚至於其利益是衝突的，那麼元件提供方則缺乏動力為使用者提供支援，甚至於拒絕提供服務。這時候溝通協調成本將會特別的大。

這個問題實際上不是一個軟體技術問題，這涉及到組織架構的設計。因此要降低溝通協調成本，則需要更高一級的領導設計調整 元件提供方與使用方之間的關係，使其達到利益相關、一致。

這實際上也是很多文章講的，（企業級）中臺是一把手工程的由來，其並非由技術人員就能推動的事情。

使用成本

當我們使用各種雲服務時，我們需要付費，在一些較大的公司裡，使用別的部門的服務也是需要付出相關成本的,當複用這些元件的成本超過自己重新做一份的成本時，我們就會考慮自己再搞一套

企業級複用的例子

以下是阿里謝純良分享的一個關於系統複用的圖：

圖中包含幾層

• 平臺層
  • 可複用的通用演算法、通用中介軟體
• 共享業務能力層
  • 可複用的通用能力，包括訂單、支付、商品等
  • 多應用通用功能的邏輯中心化及資料中心化
• 應用層
  • 按照應用所需的流程組裝共享業務能力
  • 應用可包含電商、客服、CRM等
• 擴充套件層
  • 通過擴充套件應用層預留的擴充套件點，以滿足特定渠道場景的需求

以下是我之前公司系統間進行復用的圖：

圖中最頂端的對應的是阿里圖中的應用層，其餘的對應的是共享業務能力層。

這裡共享能力層裡的各種能力也有可能互相組合形成一些新的能力，如圖中的投資組合服務 以及 套利工具服務。

如果我們願意，可以把沒有依賴於其他服務的服務叫原子能力服務，組合了其他原子能力服務的服務叫做組合能力服務，但這些名詞僅僅在特定場景特定公司內起作用，我們作為一個程式設計師要穿透這些名詞看到本質。

就像中臺這個名詞一樣，它的本質就是企業級的複用，達到這個複用目的途徑有千萬種，只要達到這個目的他就是中臺。

就像微服務這個名詞一樣，它的本質目的就是為了應對業務快速變化，而不得已地將服務做小。只要我們達到了應對業務快速變化這個目的，我們就成功了。而其中帶來的所謂 配置中心、註冊中心、熔斷、分散式事務等等，他們是不得不引入的一些額外成本，而不是成果。

總結

中臺是最近火起來的概念，但它只是新瓶裝舊酒，本質是在企業層級進行復用的一個描述。

複用則是每一個程式設計師應有的覺悟，但規模是萬惡之源，任何事情規模增大了，實施的難度都會急劇增加。

進行復用（或者說進行中臺建設）並非沒有代價，我們需要權衡複用的利弊後，才能做出正確的決策。

關於作者

在兩家排名前三的股份制商業銀行及互金創業公司工作過，目前在排名前二的網際網路銀行工作，做過業務，做過中介軟體，做過架構，也帶過小團隊。

歡迎加微信及公眾號交流技術，請備註名字+公司。

個人微信：

公眾號