談複用的成本與中臺的建設

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

複用的成本

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

當出現某些類似功能的代碼時，咱們應該將通用部分代碼與特異部分代碼分離，以達到複用通用代碼，下降總體複雜度的目的。

按照個人理解裏，一個好的程序，壓縮率應該接近於0,沒有任何能夠精簡的部分（變量名、方法名等除外）

複用帶來不少好處，如：

• 利用已有資源快速開發
• 代碼更清晰易懂
• 代碼能夠統一修改管控
• 數據能夠統一分析利用
• 下降系統總體複雜度

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

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

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

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

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

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

但讓咱們回想一下本身所在的小組裏，已經處理掉了重複代碼，達到了完美的複用了麼？若是已經完美複用了，那你所在的室呢？

咱們發現，隨着人數的增長以及代碼數量的增長，未通過良好設計及組織，發現及使用可複用代碼的難度將會急劇增長。

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

實現DRY可能只須要一個優秀的程序員，但實現Don't Repeat Ourselve就沒這麼簡單了。

對於需求方團隊是否要複用某個其餘團隊的組件，能夠由一個公式來表示：

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

當上述表達式爲「真」，那麼咱們就能夠考慮複用。

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

實現複用所需的時間

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

• 發現可複用組件須要時間
• 學習可複用組件須要時間
• 可複用組件准入須要時間
  • 使用本公司的組件服務所需的流程制度
  • 使用其餘公司的組件服務所需的商務合做的溝通
• 可複用組件的擴展須要時間
• 可複用組件的修改須要時間
  • 複用組件須要通過多個業務驗證才能達到一個較爲穩定的狀態，在此以前業務協助可複用組件演化須要更多的時間
  • 可複用組件的維護團隊可能跟使用者團隊的利益關係不一致，致使修改的優先級更低

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

不復用的狀況就是咱們一般講的煙囪系統，如今大環境的論調是煙囪系統很差，其在一個業務成熟的公司裏確實很差。可是煙囪系統在業務早期變化大，快速野蠻生長時,因爲不須要考慮複用,沒有太多的條條框框限制,提供了高效的開發效率支持，爲業務的存活作了重要貢獻。

複用的發現成本

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

• 發現複用的方式

在幾我的的小組維護的系統裏，咱們傾向於不產生任何重複代碼。在實現某些功能時，須要肯定有沒有已有的枚舉、類、方法、DAO時咱們會問小組長，或者直接在小羣裏吼一聲。

在幾十我的的室裏，咱們小組要用其餘小組系統的接口時，一般會由小組負責人之間拉會議溝通協調，確認對應接口是否存在，是否合適，如何使用，改造方案等。

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

單一系統的複用發現方式

下降單一系統（單個git repo/單個eclipse項目）的複用發現成本的一種作法就是合理分包，在寫好代碼的同時，就把複用發現的手段給完善了。

一個合理分包的代碼裏，咱們可以快速地推斷出咱們所須要的東西在哪裏、是否存在。

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

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

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

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

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

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

這個管理系統應該能夠按照分類逐層查找複用組件，也能夠按照關鍵字查找對應的複用組件。阿里雲官方網站咱們能夠做爲一種參考。

但固然，構造這麼一個系統也是須要消耗大量人力物力的，在初期使用Wiki+Swagger的形式將接口信息提供出去也是不錯的選擇。

學習的成本

一個接口學習的成本大小與接口大小成正比。

接口大小指代要正確使用該接口所需具有的知識，如：

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

這些知識，咱們也能夠稱其爲「耦合」。

咱們知道，耦合要越小越好，這樣才能讓經過接口交互的兩個模塊更容易地獨立演進。

同時，耦合越小，咱們學習這個接口的成本就越小。

固然，影響學習的成本除了接口自身要良好設計以外，還須要完善的文檔與例子，這也是下降學習成本的關鍵。

溝通協調成本

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

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

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

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

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

使用成本

當咱們使用各類雲服務時，咱們須要付費，在一些較大的公司裏，使用別的部門的服務也是須要付出相關成本的,當複用這些組件的成本超過本身從新作一份的成本時，咱們就會考慮本身再搞一套

企業級複用的例子

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

圖中包含幾層

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

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

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

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

若是咱們願意，能夠把沒有依賴於其餘服務的服務叫原子能力服務，組合了其餘原子能力服務的服務叫作組合能力服務，但這些名詞僅僅在特定場景特定公司內起做用，咱們做爲一個程序員要穿透這些名詞看到本質。

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

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

總結

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

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

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

關於做者

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

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

 

我的微信：

 

公衆號