編輯導讀：說到中臺，很多企業盡管都在搭建，但是對它的了解不夠深。比如一套系統，為什么不能復用？復用需要一個體系的設計，一個組織的支撐，一個相互信任的團隊文化，一個不斷完善的過程。本文作者從自身工作經歷出發，對此進行了分析，一起來看看吧。

最近一個項目匯報的時候，我下面的一個研發負責人被老板“罵”了一頓，原因是老板認為這個功能之前某某項目，某某系統做過了，為啥要重新開發，拿來用就行，結果這位研發負責人講不清楚，或者技術人員太實在而不知道該如何表達，最后也把我叫過去數落一番。

我不怪老板，她的想法是可以理解的，站在投入和產品角度，不要重復制造輪子是沒有錯的；我也不能完全怨我的下屬，有些東西的復用和集成的確是不像做PPT那樣東拼西湊那樣容易的。

雙方都沒錯，那問題出在哪呢？我將這個問題發到老譚的讀友群里，大家討論的也挺熱烈，看來這個問題的確也是大家普遍存在的問題。

有人吐槽老板不懂技術，需要上課的；有人建議需要溝通，需要不斷磨他，盤他的；還有人還建議讓老板參與幾個典型項目，讓他多體會體會的；最后我們把問題歸結到“信任”二字，原來所有的問題都可以通過“信任”來解決的。

的確信任可以解決任何問題，老板如果一點不懂，他可以信任他的CTO能很好的解決這個事情；如果老板很懂，他就會親自解決這個問題了。今天我們不討論老板的問題，他的需求本身沒有問題，如果我是老板我也會要求不做重復投入。本文我更多要站在技術領導者的視角去嘗試解析這個問題，尋求一定的解決方案。

一、系統復用為什么難？

還是從事例說起，我們做醫療行業的應用系統，健康檔案的管理是一個非常普遍的功能，我們在某系統里已經開發了稍微完整點的模塊，于是乎只要其他應用要開發健康檔案的功能，老板就會說這個我們都做過了，拿過來用就好了，為什么要重新開發？我來嘗試的回答下這個為什么很難復用。

• 這個系統由于歷史原因，是.net開發，而我們團隊主流的技術棧是Java，開發語言都不一樣，沒法復用，只能參考。
• 雖然都叫健康管理，但是不同的應用系統，他們的差異化還是非常大，慢病管理和專病管理有差異，在基層醫療和等級醫療有差異，即使同構系統，其實也無法直接復用，需要二次改造。
• 如果這個模塊不是以公共組件的方式進行抽象設計的話，它其實和當前系統是緊密耦合的，數據層的耦合，業務邏輯層的耦合，視圖層的耦合，特別是代碼級的耦合，如果在其他系統復用，首先要去除這種耦合然后在做適應化改造，復用的成本有時候不比重新開發低。

1. 復用是有成本的

DRY原則（Don’t Repeat Yourself）相信每一位程序員都應該知道。其指代的是我們寫程序時，不要一遍又一遍地編寫相似的代碼。當出現某些相似功能的代碼時，我們應該將通用部分代碼與特異部分代碼分離，以達到復用通用代碼，降低整體復雜度的目的。

復用這個道理我們都懂，我們也在實際的開發過程中真正去踐行的，但復用其實是有成本的，這也是為什么我們知道重復制造輪子不好，但卻又不停的的在制造輪子，因為很多時候造一個新輪子比改造一個輪子可能更快，成本更低。

復用有哪些成本呢？

發現可復用組件的成本！

很多時候我們并不是不想復用，而是不知道是不是存在我們需要的輪子，從哪里可以找到這個輪子，正如本文最開始的那位研發負責人，他可能真的不清楚哪個團隊有他可復用的輪子，而老板看到的范圍更廣，所以她更清楚。這個和組織管理和知識管理有關。

學習可復用組件的成本!

別人造的輪子有時候很難了解它內部的構造和邏輯，就要去學習別人造輪子的設計和邏輯，這個本身是存在學習成本的，如果對方的設計和實現與自己的思路存在出入的時候，又會非常的別扭。

擴展可復用組件的成本！

前人造的輪子都是用在他當時的那個場景或者業務中，當這個輪子切換到新的場景和業務中的時候，你會發現100%的可復用基本上是沒有的，這時候就牽扯到對于這個輪子的擴展以適用新的業務，先不說這個擴展改造是所有者執行還是使用者執行（后面有一個章節專門討論組織的邏輯），擴展總是有成本。

修改可復用組件的成本！

有時候組件的抽象能力不夠，無法擴展，或者擴展的時間成本太高，或者組件所有者不愿意支持，復用者可能采用直接拿過來修改的情況。修改的成本是一個層面，但把時間拉長來看，組件修改后就和原組件分化了，未來雙方的新功能也無法相互復用了。

2. 復用是有級別的

一般情況，復用的成本會因為復用的組件的內容不同，所在組織的關系親密，它的成本是不一樣的。比如只是復用一段程序，就相當簡單，如果復用一個系統功能就很困難；如果復用同一個團隊的組件就相當簡單，如果跨團隊跨組織的復用就會變得困難，所以復用也是有級別的，為了更好的理解我把復用分成了一下5個級別。

級別越低，粒度越小，復用的范圍越廣，但價值體現較低；級別越高，粒度越大，復用的價值越高，但復用范圍也比較局限。所以站在業務和價值角度上，都是先從最高的層次上去復用。只有上層無法實現復用，我們才會逐步向下層去尋找。但是有時候站在技術角度，我們習慣在低層次上去復用，因為這里最接近自己的工作，粒度越小，技術上越可控。

回到本節開始的問題，B系統的功能要復用A系統的功能，這個復用級別是最高的，如果能復用那會極大減少工作量降低成本，但這個級別的復用難度也是最大的，特別是異構系統，就幾乎沒有可能了。

3. 復用是有粒度的

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

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

Gartner 在研究報告里提出了宏服務、小服務和微服務的粒度劃分：

• 宏服務——一種傳統的 Web 服務，支持將功能封裝于單體應用內。宏服務不支持獨立部署或擴展， 它們只能部署為單體應用的一部分，而且它們不需要微服務基礎架構。
• 小服務——就服務粒度范圍而言，小服務是一種粗粒度、松散耦合、支持獨立部署的應用組件。小服務需要微服務基礎架構。
• 微服務——微服務處于粒度范圍的遠端，是一種可獨立部署的組件，能夠支持單個應用功能的實施。微服務可直接部署到微服務運行時環境中，也往往具備專用數據存儲區。微服務需要微服務基礎架構。

如果我們想對已存在系統的能力進行復用，可以采用宏服務模式進行，宏服務的模式適合做系統的集成和治理。我們對于新的業務和項目，剛開始建議采用小服務的方式進行業務領域的拆分，不建議拆分的過細，這個小服務能滿足該需求的基本抽象即可。從適中的粒度開始，服務的粒度一定是業務推進的過程中不斷演化的，創新業務推動服務的粒度向更細的粒度裂變，而業務成熟穩定后，又推動服務向粗粒度方向聚合。站在復用的角度，優先級是宏服務>小服務>微服務，當然難度反之。

所以復用要根據自身團隊發展情況，業務實際需要靈活把握，也要根據公司的發展階段，逐步的實現復用，總體來說復用的優先級技術層面復用優先于業務層面復用，團隊內的復用優先于團隊間的復用，項目級復用優先于產品級復用。

二、如何更好的復用

老板要求復用有沒有錯？沒有錯！員工說復用太難是不是實情？是實情！作為技術領導者，我們的職責就是解決團隊的困難，實現老板的目標。具體如何更好的復用，老譚根據自己的工作經驗和對該問題的深度思考，提供一定的思路僅供參考。

1. 不要忽視技術棧的管理

站在復用的角度，不同的開發語言之間是很難復用的，雖然對于互聯網或者自運營的信息化而言，還可以通過服務共享的方式實現復用，而對于我們更多以本地化交付的軟件產品研發而言，技術體系不統一對于復用和協同兼職就是噩夢。

老譚在負責公司研發之前，整個公司沒有統一的技術棧，每個部門幾乎都有自己的技術棧，當時存在.net，java，php等多種語言開發的系統，主流的Java語言還存在Jfinal、springboot、dubbo等不同的框架。

對于技術團隊最容易的代碼程序級別的復用因為技術體系的不統一而導致無法復用，團隊資源無法流動平衡的問題，這對于我們中小規模的研發團隊來說就是災難。分散的組織必然帶來不統一的技術架構，這就是有名的康威定律（后面還會詳細介紹）。

結合我自己的工作經歷，對于技術棧的管理提供以下思路供參考。

確定團隊主流語言，主流開發框架，主流數據庫等；

我們確定了Java語言為主流語言；springboot為主要開發框架；采用SpringCloud的微服務架構體系，；數據庫第一選擇為MySQL，新項目全部統一到MySQL。

減少非主流技術體系的資源投入，新的業務逐步以主流技術進行；

老譚之前團隊使用比較小眾的JFinal，同樣向主流框架springboot切換；減少Dubbo的使用范圍；嚴格控制非Java體系的資源投入，新業務可以采用Java開發的混合體系。

逐步向前后端分離的開發方式轉變，大后端體系之后實行大前端；

我們做技術的都清楚，后端穩定，前端變化多端，前端的復用的優先級是遠弱于后端的，但是對老板們可就不一樣，后面的數據庫，服務接口啥的他們也看不見，最直觀的就是前端，所以不能忽視。我們最先確定下前端的開發框架VUE，防止前端技術的分化，傳統的前端開發根據實際需要有準備實現架構的轉變。其實這個轉變在前期是需要增加投入的，畢竟兩套體系前期要并行，老板質問為何要切換前后端分離，當然她不知道的是，如果我們不轉變，我們現在連人（前后通吃）都招不到。

中間件不能濫用，新技術引進需要走技術評審。

技術人員都比較熱衷各種中間件的使用，對新技術趨之若鶩，追求新技術沒有錯，創新也需要鼓勵。但這些都需要管理，因為作為技術領導人，我們必須站在團隊整體角度平衡成本、效率、效益的關系，所以通過技術評審，我們既能引進新技術，又能管理技術引進帶來的學習成本，大面積推廣的時機和條件。

通過這一系列的措施，我們至少在技術底層取得了適度的統一，不同團隊之間的技術交流就消除了障礙，大家就容易共同積累，促進共享。

2. 統一架構，構建平臺級應用

技術棧的統一，只能讓我們做到LV1和LV2層級的復用能力，再往上走就涉及到功能層面和業務層面了，而這更接近老板的視角了。所以實現更高層次的復用是每個技術領導人的追求，也是發揮自身專業能力的舞臺。

但在這個環節我們往往會出現大問題，就是不能根據實際情況因地制宜，架構體系的彈性很大，沒有嚴格的標準，只有根據實際情況的平衡，平衡是考驗技術領導人的架構藝術，不要小瞧了這個能力。很多大廠的牛人去小企業做架構，太多失敗的案例，不是架構不好，是沒有用對地方。

1）對于小團隊而言，統一架構體系，單體應用一樣很美

我們一貫的常識就是，越是獨立的，沒有太多耦合關系的組件越容易復用，過去煙囪似的單體系統難以復用就是模塊和系統本身耦合太深而造成復用改造的成本很大。這個理論是對的，但我認為不全面，完全去除耦合是不現實的，只是耦合的深淺和范圍是需要管理的，如果復用組件的使用者一樣耦合在同樣一個環境中，其實也是可以復用的。這就像A系統要復用B系統的模塊其實是很困難的，因為耦合的環境不一樣，依賴的基礎不同；但是A系統內要復用自身系統的某模塊卻非常容易，因為依賴環境是一樣的。所以，小團隊如果在代碼層級能夠統一成一個應用，然后通過插件化、代碼級的組件化對業務模塊進行抽象和管理，單體系統依然是很美的。

我在七八年前帶一個小型互聯網團隊，自己花了兩三個月時間寫了一套基于JFinal（當時剛開始推出的小眾框架，現在已經非常流行了）插件化的腳手架系統作為我們團隊所有業務開發的載體，這么多年過去了，這個系統依然在健壯的運行，業務也在不斷持續的開發著。我們實施的泛微最新一代的OA系統，如此龐大的系統，通過部署結構來看，其實也是一個大單體應用。所以，不是單體系統不好，只是當它太大以后，我們沒有能力管理好它而已。

2）有一定規模的技術組織，構建統一平臺底座

復用的成本以及難度往往都是組織規模擴大，尤其分化后才迅速提升的。在一個多組織中實現組件的復用需要建立統一的標準，也不要完全去除依賴，而是盡可能依賴單一，大家都依賴這個單一的東西，這個依賴對復用的影響就會降低，所以一定規模的技術組織，要通過構建統一的平臺底座，將共享組件沉淀在平臺底座上，讓不同的業務共同依賴同一套底層的環境，通過平臺底座的共享能力，實現各垂直業務的橫向交流和協同。

這種模式特別適合軟件產品研發的企業，構建在厚實的平臺之上的產品研發，既高效又善于組合和擴展，產品的邊界不會因為系統的隔離而變的僵化。

而且構建平臺底座既適合單體架構的應用也適合分布式的微服務架構，平臺底座其實一個組織有規劃的復用的體系建設。下圖是筆者團隊建設的平臺體系，后臺引擎由架構團隊主要負責建設，業務組件（屬于中臺范疇）由各研發團隊根據業務領域分別負責構建，供做參考。

3）企業級的復用體系–中臺架構

中臺的廣義上的定義：企業級能力復用平臺。

雖然我們的一體化平臺涉及到中臺服務部分，但是作為研發企業，我們的中臺架構和服務是面向客戶去交付的，幫助甲方客戶構建中臺能力。一般情況我們所說的中臺，不是廠商的中臺解決方案，而是一個互聯網企業或者一個傳統企業為了滿足自身數字化轉型的需要而構建的中臺體系，它是面向企業運營的中臺體系而不是面向項目交付的中臺服務。

廣義上的中臺范圍是非常大的，涵蓋了企業運營的方方面面，而我們更關注的是企業中臺的載體即數字化運營中臺。企業首先通過信息化建設，將企業內在業務從線下搬到了線上，這個階段我們構建了一個個的單體系統，這些系統集成都不容易，復用幾乎就更沒可能。最終導致大量的重復開發建設，同時還帶了更大的系統治理的成本。

進入數字化時代，甚至是智能化時代，面對激烈的市場競爭，企業降本增效的需求愈發迫切，更好的復用，更敏捷的建設是企業迫切的愿望，中臺體系的提出，是順應這個時代的產物，所以企業關注中臺，嘗試中臺是對的，至于為什么會失敗，后面的文章再去探討。

對于一個有技術開發能力的企業，比如互聯網企業，科技企業等，中臺的復用能力不要極端的追求新建，雖然這樣比較簡單，但對企業來說著實浪費，如上圖所示，首先單體應用架構向業務中臺架構演變，能利用則利用，能改造就盡量不要新建，能沉淀就盡量沉淀。

4. 根據康威定律，組織要支撐

被復用的組件需要進行修改定制時，我們需要組件的維護方提供支持，此時就需要相應的溝通協調成本。若組件提供方與組件使用方沒有任何利益關系，甚至于其利益是沖突的，那么組件提供方則缺乏動力為使用者提供支持，甚至于拒絕提供服務。這時候溝通協調成本將會特別的大。（本文提到的那位研發負責人其實很大程度上也面臨這個問題，協調不動組件方修改，自己改又太有難度，與其不如自己造一個輪子了）

這個問題實際上不是一個軟件技術問題，這涉及到組織架構的設計。因此要降低溝通協調成本，則需要更高一級的領導設計調整組件提供方與使用方之間的關系，使其達到利益相關、一致。如下圖所示，每個人在自己管轄的范圍之內都相對比較容易復用和協作（對應顏色的橫向箭頭），而一旦超出了這個范圍，復用和協同的難度和成本就會急劇增加。

重溫下康威定律：

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway(1967)

設計系統的組織其產生的設計等價于組織間的溝通結構。

已經五十多年的康威定律依然是指導我們做系統設計和企業架構的重要定律，它詮釋了系統架構和組織架構的對應關系，其實這非常容易理解，任何事情都是有人去執行的，人的組織結構決定了系統的架構設計，一個分散型的組織很難有高度統一的架構，也注定難以復用。當然一個集權化的組織，復用和協作的成本就很低，相反組織的活性會降低，自主性和創新性不足。

老板最重要的任務其實是通過設計組織的結構，來匹配做事情的邏輯，最終實現自己想要的效果，否則在一個人、物、事不匹配的環境里，只有一腔的熱血、殷切的希望和憤怒的咆哮也是無濟于事，這便是規律的不可違背性。

正如阿里巴巴實施中臺戰略，CTO行癲（張建峰）親自掛帥負責中臺事業群，負責中臺戰略的推進。同時作為當時整個集團的CTO，在各事業部橫向推行中臺架構體系又有誰不配合呢，可見阿里中臺戰略的執行力有多強，這也是為什么阿里的中臺能夠成為行業的標桿，這與其組織的設計是分不開的。

最后總結一下，復用是老板的合理需求，是技術領導人的核心職責，是所有技術人的全局意識。但復用的達成，不是老板的念念不忘，不是技術領導人的行政要求，也不是所有技術人的滿腹牢騷，它需要一個體系的設計，一個組織的支撐，一個相互信任的團隊文化，一個不斷完善的過程。任重而道遠，讓我們勵志前行！

#專欄作家#

菜根老譚，微信公眾號：CGLT_TAN，人人都是產品經理專欄作家。經歷程序員、技術Leader、產品經理、研發Leader等多種崗位?，F負責某科技公司整體產品研發，擅長企業IT架構及互聯網產品架構。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議