啥都複用不了，還談什麼中臺！

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"最近一個項目彙報的時候，我下面的一個研發負責人被老闆“罵”了一頓，原因是老闆認爲這個功能之前某某項目，某某系統做過了，爲啥要重新開發，拿來用就行，結果這位研發負責人講不清楚，或者技術人員太實在而不知道該如何表達，最後也把我叫過去數落一番。我不怪老闆，她的想法是可以理解的，站在投入和產品角度，不要重複製造輪子是沒有錯的；我也不能完全怨我的下屬，有些東西的複用和集成的確是不像做PPT那樣東拼西湊那樣容易的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"雙方都沒錯，那問題出在哪呢？我將這個問題發到老譚的讀友羣裏，大家討論的也挺熱烈，看來這個問題的確也是大家普遍存在的問題。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"有人吐槽老闆不懂技術，需要上課的；有人建議需要溝通，需要不斷磨他，盤他的；還有人還建議讓老闆參與幾個典型項目，讓他多體會體會的；最後我們把問題歸結到“信任”二字，原來所有的問題都可以通過“信任”來解決的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"的確信任可以解決任何問題，老闆如果一點不懂，他可以信任他的CTO能很好的解決這個事情；如果老闆很懂，他就會親自解決這個問題了。今天我們不討論老闆的問題，他的需求本身沒有問題，如果我是老闆我也會要求不做重複投入。本文我更多要站在技術領導者的視角去嘗試解析這個問題，尋求一定的解決方案。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"系統複用爲什麼難？","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"還是從事例說起，我們做醫療行業的應用系統，健康檔案的管理是一個非常普遍的功能，我們在某系統裏已經開發了稍微完整點的模塊，於是乎只要其他應用要開發健康檔案的功能，老闆就會說這個我們都做過了，拿過來用就好了，爲什麼要重新開發？我來嘗試的回答下這個","attrs":{}},{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"爲什麼很難複用","attrs":{}},{"type":"text","text":"。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"1、這個系統由於歷史原因，是.net開發，而我們團隊主流的技術棧是Java，開發語言都不一樣，沒法複用，只能參考。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"2、雖然都叫健康管理，但是不同的應用系統，他們的差異化還是非常大，慢病管理和專病管理有差異，在基層醫療和等級醫療有差異，即使同構系統，其實也無法直接複用，需要二次改造。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"3、如果這個模塊不是以公共組件的方式進行抽象設計的話，它其實和當前系統是緊密耦合的，數據層的耦合，業務邏輯層的耦合，視圖層的耦合，特別是代碼級的耦合，如果在其他系統複用，首先要去除這種耦合然後在做適應化改造，複用的成本有時候不比重新開發低。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"複用是有成本的","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"**DRY原則（Don't Repeat Yourself）**相信每一位程序員都應該知道。其指代的是我們寫程序時，不要一遍又一遍地編寫相似的代碼。當出現某些相似功能的代碼時，我們應該將通用部分代碼與特異部分代碼分離，以達到複用通用代碼，降低整體複雜度的目的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"複用這個道理我們都懂，我們也在實際的開發過程中真正去踐行的，但複用其實是有成本的，這也是爲什麼我們知道重複製造輪子不好，但卻又不停的的在製造輪子，因爲很多時候造一個新輪子比改造一個輪子可能更快，成本更低。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"複用有哪些成本呢？","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"發現可複用組件的成本！","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"很多時候我們並不是不想複用，而是不知道是不是存在我們需要的輪子，從哪裏可以找到這個輪子，正如本文最開始的那位研發負責人，他可能真的不清楚哪個團隊有他可複用的輪子，而老闆看到的範圍更廣，所以她更清楚。這個和組織管理和知識管理有關。","attrs":{}}]}],"attrs":{}}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"學習可複用組件的成本!","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"別人造的輪子有時候很難了解它內部的構造和邏輯，就要去學習別人造輪子的設計和邏輯，這個本身是存在學習成本的，如果對方的設計和實現與自己的思路存在出入的時候，又會非常的彆扭。","attrs":{}}]}],"attrs":{}}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"擴展可複用組件的成本","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"前人造的輪子都是用在他當時的那個場景或者業務中，當這個輪子切換到新的場景和業務中的時候，你會發現100%的可複用基本上是沒有的，這時候就牽扯到對於這個輪子的擴展以適用新的業務，先不說這個擴展改造是","attrs":{}},{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"所有者","attrs":{}},{"type":"text","text":"執行還是","attrs":{}},{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"使用者","attrs":{}},{"type":"text","text":"執行（後面有一個章節專門討論組織的邏輯），擴展總是有成本。","attrs":{}}]}],"attrs":{}}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"修改可複用組件的成本","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"有時候組件的抽象能力不夠，無法擴展，或者擴展的時間成本太高，或者組件所有者不願意支持，複用者可能採用直接拿過來修改的情況。修改的成本是一個層面，但把時間拉長來看，組件修改後就和原組件分化了，未來雙方的新功能也很難相互複用了。","attrs":{}}]}],"attrs":{}}]}],"attrs":{}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"複用是有級別的","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一般情況，複用的成本會因爲複用的組件的內容不同，所在組織的關係親密，它的成本是不一樣的。比如只是複用一段程序，就相當簡單，如果複用一個系統功能就很困難；如果複用同一個團隊的組件就相當簡單，如果跨團隊跨組織的複用就會變得困難，所以複用也是有級別的，爲了更好的理解我把複用分成了一下5個級別。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.infoq.cn/resource/image/d7/31/d7c2e0f5f34e5ec590b8f20c78250e31.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"**級別越低，粒度越小，複用的範圍越廣，但價值體現較低；級別越高，粒度越大，複用的價值越高，但複用範圍也比較侷限。**所以站在業務和價值角度上，都是先從最高的層次上去複用。只有上層無法實現複用，我們纔會逐步向下層去尋找。但是有時候站在技術角度，我們習慣在低層次上去複用，因爲這裏最接近自己的工作，粒度越小，技術上越可控。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"回到本節開始的問題，B系統的功能要複用A系統的功能，這個複用級別是最高的，如果能複用那會極大減少工作量降低成本，但這個級別的複用難度也是最大的，特別是異構系統，就幾乎沒有可能了。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"複用是有粒度的","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"影響複用達成時間的因素很多，這些因素疊加起來可能導致複用所消耗的時間更多。因此對於一些時間特別敏感、由其決定生死的業務，在可複用組件未成熟，或者可複用組件支持團隊的支持力度不夠時，可以不考慮複用。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"不復用的情況就是我們通常講的煙囪系統，現在大環境的論調是煙囪系統不好，其在一個業務成熟的公司裏確實不好。但是煙囪系統在業務早期變化大，快速野蠻生長時,由於不需要考慮複用,沒有太多的條條框框限制,提供了高效的開發效率支持，爲業務的存活做了重要貢獻。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.infoq.cn/resource/image/e9/33/e9c2e6e48a649b52359334641023a133.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Gartner 在研究報告裏提出了宏服務、小服務和微服務的粒度劃分：","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"宏服務","attrs":{}},{"type":"text","text":"——一種傳統的 Web 服務，支持將功能封裝於單體應用內。宏服務不支持獨立部署或擴展， 它們只能部署爲單體應用的一部分，而且它們不需要微服務基礎架構。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"小服務","attrs":{}},{"type":"text","text":"——就服務粒度範圍而言，小服務是一種粗粒度、鬆散耦合、支持獨立部署的應用組件。小服務需要微服務基礎架構。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"微服務","attrs":{}},{"type":"text","text":"——微服務處於粒度範圍的遠端，是一種可獨立部署的組件，能夠支持單個應用功能的實施。微服務可直接部署到微服務運行時環境中，也往往具備專用數據存儲區。微服務需要微服務基礎架構。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果我們想對已存在系統的能力進行復用，可以採用宏服務模式進行，宏服務的模式適合做系統的集成和治理。我們對於新的業務和項目，剛開始建議採用小服務的方式進行業務領域的拆分，不建議拆分的過細，這個小服務能滿足該需求的基本抽象即可。從適中的粒度開始，服務的粒度一定是業務推進的過程中不斷演化的，創新業務推動服務的粒度向更細的粒度裂變，而業務成熟穩定後，又推動服務向粗粒度方向聚合。站在複用的角度，優先級是宏服務>小服務>微服務，當然難度反之。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"所以複用要根據自身團隊發展情況，業務實際需要靈活把握，也要根據公司的發展階段，逐步的實現複用，總體來說複用的優先級技術層面複用優先於業務層面複用，團隊內的複用優先於團隊間的複用，項目級複用優先於產品級複用。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"如何更好的複用","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"老闆要求複用有沒有錯？沒有錯！員工說複用太難是不是實情？是實情！作爲技術領導者，我們的職責就是解決團隊的困難，實現老闆的目標。具體如何更好的複用，老譚根據自己的工作經驗和對該問題的深度思考，提供一定的思路僅供參考。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"不要忽視技術棧的管理","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"站在複用的角度，不同的開發語言之間是很難複用的，雖然對於互聯網或者自運營的信息化而言，還可以通過服務共享的方式實現複用，而對於我們更多以本地化交付的軟件產品研發而言，技術體系不統一對於複用和協同兼職就是噩夢。老譚在負責公司研發之前，整個公司沒有統一的技術棧，每個部門幾乎都有自己的技術棧，當時存在.net，java，php等多種語言開發的系統，主流的Java語言還存在Jfinal、springboot、dubbo等不同的框架。對於技術團隊最容易的代碼程序級別的複用因爲技術體系的不統一而導致無法複用，團隊資源無法流動平衡的問題，這對於我們中小規模的研發團隊來說就是災難。分散的組織必然帶來不統一的技術架構，這就是有名的康威定律（後面還會詳細介紹）。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"結合我自己的工作經歷，對於技術棧的管理提供以下思路供參考。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"numberedlist","attrs":{"start":1,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"確定團隊主流語言，主流開發框架，主流數據庫等；","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"我們確定了Java語言爲主流語言；springboot爲主要開發框架；採用SpringCloud的微服務架構體系，；數據庫第一選擇爲MySQL，新項目全部統一到MySQL。","attrs":{}}]}],"attrs":{}}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","text":"減少非主流技術體系的資源投入，新的業務逐步以主流技術進行；","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":4,"align":null,"origin":null},"content":[{"type":"text","text":"老譚之前團隊使用比較小衆的JFinal，同樣向主流框架springboot切換；減少Dubbo的使用範圍；嚴格控制非Java體系的資源投入，新業務可以採用Java開發的混合體系。","attrs":{}}]}],"attrs":{}}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":5,"align":null,"origin":null},"content":[{"type":"text","text":"逐步向前後端分離的開發方式轉變，大後端體系之後實行大前端；","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":6,"align":null,"origin":null},"content":[{"type":"text","text":"我們做技術的都清楚，後端穩定，前端變化多端，前端的複用的優先級是遠弱於後端的，但是對老闆們可就不一樣，後面的數據庫，服務接口啥的他們也看不見，最直觀的就是前端，所以不能忽視。我們最先確定下前端的開發框架VUE，防止前端技術的分化，傳統的前端開發根據實際需要有準備實現架構的轉變。其實這個轉變在前期是需要增加投入的，畢竟兩套體系前期要並行，老闆質問爲何要切換前後端分離，當然她不知道的是，如果我們不轉變，我們現在連人（前後通喫）都招不到。","attrs":{}}]}],"attrs":{}}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":7,"align":null,"origin":null},"content":[{"type":"text","text":"中間件不能濫用，新技術引進需要走技術評審。","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":"none"},"content":[{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":8,"align":null,"origin":null},"content":[{"type":"text","text":"技術人員都比較熱衷各種中間件的使用，對新技術趨之若鶩，追求新技術沒有錯，創新也需要鼓勵。但這些都需要管理，因爲作爲技術領導人，我們必須站在團隊整體角度平衡成本、效率、效益的關係，所以通過技術評審，我們既能引進新技術，又能管理技術引進帶來的學習成本，大面積推廣的時機和條件。","attrs":{}}]}],"attrs":{}}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"通過這一系列的措施，我們至少在技術底層取得了適度的統一，不同團隊之間的技術交流就消除了障礙，大家就容易共同積累，促進共享。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"統一架構，構建平臺級應用","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"技術棧的統一，只能讓我們做到LV1和LV2層級的複用能力，再往上走就涉及到功能層面和業務層面了，而這更接近老闆的視角了。所以實現更高層次的複用是每個技術領導人的追求，也是發揮自身專業能力的舞臺。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"但在這個環節我們往往會出現大問題，就是不能根據實際情況因地制宜，架構體系的彈性很大，沒有嚴格的標準，只有根據實際情況的平衡，平衡是考驗技術領導人的架構藝術，不要小瞧了這個能力。很多大廠的牛人去小企業做架構，太多失敗的案例，不是架構不好，是沒有用對地方。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"1、對於小團隊而言，統一架構體系，單體應用一樣很美。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我們一貫的常識就是，越是獨立的，沒有太多耦合關係的組件越容易複用，過去煙囪似的單體系統難以複用就是模塊和系統本身耦合太深而造成複用改造的成本很大。這個理論是對的，但我認爲不全面，完全去除耦合是不現實的，只是耦合的深淺和範圍是需要管理的，如果複用組件的使用者一樣耦合在同樣一個環境中，其實也是可以複用的。這就像A系統要複用B系統的模塊其實是很困難的，因爲耦合的環境不一樣，依賴的基礎不同；但是A系統內要複用自身系統的某模塊卻非常容易，因爲依賴環境是一樣的。所以，小團隊如果在代碼層級能夠統一成一個應用，然後通過插件化、代碼級的組件化對業務模塊進行抽象和管理，單體系統依然是很美的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我在七八年前帶一個小型互聯網團隊，自己花了兩三個月時間寫了一套基於JFinal（當時剛開始推出的小衆框架，現在已經非常流行了）插件化的腳手架系統作爲我們團隊所有業務開發的載體，這麼多年過去了，這個系統依然在健壯的運行，業務也在不斷持續的開發着。我們實施的泛微最新一代的OA系統，如此龐大的系統，通過部署結構來看，其實也是一個大單體應用。所以，不是單體系統不好，只是當它太大以後，我們沒有能力管理好它而已。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"2、有一定規模的技術組織，構建統一平臺底座。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"複用的成本以及難度往往都是組織規模擴大，尤其分化後才迅速提升的。在一個多組織中實現組件的複用需要建立統一的標準，也不要完全去除依賴，而是儘可能依賴單一，大家都依賴這個單一的東西，這個依賴對複用的影響就會降低，所以一定規模的技術組織，要通過構建統一的平臺底座，將共享組件沉澱在平臺底座上，讓不同的業務共同依賴同一套底層的環境，通過平臺底座的共享能力，實現各垂直業務的橫向交流和協同。這種模式特別適合軟件產品研發的企業，構建在厚實的平臺之上的產品研發，既高效又善於組合和擴展，產品的邊界不會因爲系統的隔離而變的僵化。而且構建平臺底座既適合單體架構的應用也適合分佈式的微服務架構，平臺底座其實一個組織有規劃的複用的體系建設。下圖是筆者團隊建設的平臺體系，後臺引擎由架構團隊主要負責建設，業務組件（屬於中臺範疇）由各研發團隊根據業務領域分別負責構建，供做參考。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/6d/6dbec11840c30bd14210c703c431a113.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"3、企業級的複用體系--中臺架構","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"中臺的廣義上的定義：企業級能力複用平臺。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"雖然我們的一體化平臺涉及到中臺服務部分，但是作爲研發企業，我們的中臺架構和服務是面向客戶去交付的，幫助甲方客戶構建中臺能力。一般情況我們所說的中臺，不是廠商的中臺解決方案，而是一個互聯網企業或者一個傳統企業爲了滿足自身數字化轉型的需要而構建的中臺體系，它是面向企業運營的中臺體系而不是面向項目交付的中臺服務。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"廣義上的中臺範圍是非常大的，涵蓋了企業運營的方方面面，而我們更關注的是企業中臺的載體即數字化運營中臺。企業首先通過信息化建設，將企業內在業務從線下搬到了線上，這個階段我們構建了一個個的單體系統，這些系統集成都不容易，複用幾乎就更沒可能。最終導致大量的重複開發建設，同時還帶了更大的系統治理的成本。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/fb/fb4345d05bf5e3b7f1b08304ea4e8bb0.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"進入數字化時代，甚至是智能化時代，面對激烈的市場競爭，企業降本增效的需求愈發迫切，更好的複用，更敏捷的建設是企業迫切的願望，中臺體系的提出，是順應這個時代的產物，所以企業關注中臺，嘗試中臺是對的，至於爲什麼會失敗，後面的文章再去探討。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/55/55115fcd845a80524696811b1eb9cabd.jpeg","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"對於一個有技術開發能力的企業，比如互聯網企業，科技企業等，中臺的複用能力不要極端的追求新建，雖然這樣比較簡單，但對企業來說着實浪費，如上圖所示，首先單體應用架構向業務中臺架構演變，能利用則利用，能改造就儘量不要新建，能沉澱就儘量沉澱。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"根據康威定律，組織要支撐","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"被複用的組件需要進行修改定製時，我們需要組件的維護方提供支持，此時就需要相應的溝通協調成本。若組件提供方與組件使用方沒有任何利益關係，甚至於其利益是衝突的，那麼組件提供方則缺乏動力爲使用者提供支持，甚至於拒絕提供服務。這時候溝通協調成本將會特別的大。（本文提到的那位研發負責人其實很大程度上也面臨這個問題，協調不動組件方修改，自己改又太有難度，與其不如自己造一個輪子了）","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這個問題實際上不是一個軟件技術問題，這涉及到組織架構的設計。因此要降低溝通協調成本，則需要更高一級的領導設計調整組件提供方與使用方之間的關係，使其達到利益相關、一致。如下圖所示，每個人在自己管轄的範圍之內都相對比較容易複用和協作（對應顏色的橫向箭頭），而一旦超出了這個範圍，複用和協同的難度和成本就會急劇增加。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/89/89b540875fb62041b85897b64f422c47.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"重溫下康威定律：","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"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)","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"設計系統的組織其產生的設計等價於組織間的溝通結構。","attrs":{}}]}],"attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"已經五十多年的康威定律依然是指導我們做系統設計和企業架構的重要定律，它詮釋了系統架構和組織架構的對應關係，其實這非常容易理解，任何事情都是有人去執行的，人的組織結構決定了系統的架構設計，一個分散型的組織很難有高度統一的架構，也註定難以複用。當然一個集權化的組織，複用和協作的成本就很低，相反組織的活性會降低，自主性和創新性不足。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"老闆最重要的任務其實是通過設計組織的結構，來匹配做事情的邏輯，最終實現自己想要的效果，否則在一個人、物、事不匹配的環境裏，只有一腔的熱血、殷切的希望和憤怒的咆哮也是無濟於事，這便是規律的不可違背性。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"正如阿里巴巴實施中臺戰略，CTO行癲（張建峯）親自掛帥負責中臺事業羣，負責中臺戰略的推進。同時作爲當時整個集團的CTO，在各事業部橫向推行中臺架構體系又有誰不配合呢，可見阿里中臺戰略的執行力有多強，這也是爲什麼阿里的中臺能夠成爲行業的標杆，這與其組織的設計是分不開的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/91/919850b74a13ada2cce5d08a082faee4.jpeg","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"最後總結一下，複用是老闆的合理需求，是技術領導人的核心職責，是所有技術人的全局意識。但複用的達成，不是老闆的念念不忘，不是技術領導人的行政要求，也不是所有技術人的滿腹牢騷，它需要一個體系的設計，一個組織的支撐，一個相互信任的團隊文化，一個不斷完善的過程。任重而道遠，讓我們勵志前行！","attrs":{}}]},{"type":"horizontalrule","attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":"br"}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/d6/d6e96dc2b5a0b44e023acc9f6911dd5a.png","alt":null,"title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"《產品研發體系步步爲營》是菜根老譚結合自己的工作經歷和對研發體系建設的思考而專門開闢的一個專欄，通過分享自己研發管理的過程來獲取更多反饋的信息，從而時時校驗自己，糾正自己。同時對於在中小型企業致力於技術管理的同學提供一些研發體系建設的思路。該專欄首發今日頭條,關注我的同名頭條號和微信公衆號獲取更及時的內容推薦。","attrs":{}}]}]}