国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

編輯導(dǎo)讀：說到中臺(tái)，很多企業(yè)盡管都在搭建，但是對(duì)它的了解不夠深。比如一套系統(tǒng)，為什么不能復(fù)用？復(fù)用需要一個(gè)體系的設(shè)計(jì)，一個(gè)組織的支撐，一個(gè)相互信任的團(tuán)隊(duì)文化，一個(gè)不斷完善的過程。本文作者從自身工作經(jīng)歷出發(fā)，對(duì)此進(jìn)行了分析，一起來看看吧。

最近一個(gè)項(xiàng)目匯報(bào)的時(shí)候，我下面的一個(gè)研發(fā)負(fù)責(zé)人被老板“罵”了一頓，原因是老板認(rèn)為這個(gè)功能之前某某項(xiàng)目，某某系統(tǒng)做過了，為啥要重新開發(fā)，拿來用就行，結(jié)果這位研發(fā)負(fù)責(zé)人講不清楚，或者技術(shù)人員太實(shí)在而不知道該如何表達(dá)，最后也把我叫過去數(shù)落一番。

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

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

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

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

一、系統(tǒng)復(fù)用為什么難？

還是從事例說起，我們做醫(yī)療行業(yè)的應(yīng)用系統(tǒng)，健康檔案的管理是一個(gè)非常普遍的功能，我們?cè)谀诚到y(tǒng)里已經(jīng)開發(fā)了稍微完整點(diǎn)的模塊，于是乎只要其他應(yīng)用要開發(fā)健康檔案的功能，老板就會(huì)說這個(gè)我們都做過了，拿過來用就好了，為什么要重新開發(fā)？我來嘗試的回答下這個(gè)為什么很難復(fù)用。

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

1. 復(fù)用是有成本的

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

復(fù)用這個(gè)道理我們都懂，我們也在實(shí)際的開發(fā)過程中真正去踐行的，但復(fù)用其實(shí)是有成本的，這也是為什么我們知道重復(fù)制造輪子不好，但卻又不停的的在制造輪子，因?yàn)楹芏鄷r(shí)候造一個(gè)新輪子比改造一個(gè)輪子可能更快，成本更低。

復(fù)用有哪些成本呢？

發(fā)現(xiàn)可復(fù)用組件的成本！

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

學(xué)習(xí)可復(fù)用組件的成本!

別人造的輪子有時(shí)候很難了解它內(nèi)部的構(gòu)造和邏輯，就要去學(xué)習(xí)別人造輪子的設(shè)計(jì)和邏輯，這個(gè)本身是存在學(xué)習(xí)成本的，如果對(duì)方的設(shè)計(jì)和實(shí)現(xiàn)與自己的思路存在出入的時(shí)候，又會(huì)非常的別扭。

擴(kuò)展可復(fù)用組件的成本！

前人造的輪子都是用在他當(dāng)時(shí)的那個(gè)場(chǎng)景或者業(yè)務(wù)中，當(dāng)這個(gè)輪子切換到新的場(chǎng)景和業(yè)務(wù)中的時(shí)候，你會(huì)發(fā)現(xiàn)100%的可復(fù)用基本上是沒有的，這時(shí)候就牽扯到對(duì)于這個(gè)輪子的擴(kuò)展以適用新的業(yè)務(wù)，先不說這個(gè)擴(kuò)展改造是所有者執(zhí)行還是使用者執(zhí)行（后面有一個(gè)章節(jié)專門討論組織的邏輯），擴(kuò)展總是有成本。

修改可復(fù)用組件的成本！

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

2. 復(fù)用是有級(jí)別的

一般情況，復(fù)用的成本會(huì)因?yàn)閺?fù)用的組件的內(nèi)容不同，所在組織的關(guān)系親密，它的成本是不一樣的。比如只是復(fù)用一段程序，就相當(dāng)簡(jiǎn)單，如果復(fù)用一個(gè)系統(tǒng)功能就很困難；如果復(fù)用同一個(gè)團(tuán)隊(duì)的組件就相當(dāng)簡(jiǎn)單，如果跨團(tuán)隊(duì)跨組織的復(fù)用就會(huì)變得困難，所以復(fù)用也是有級(jí)別的，為了更好的理解我把復(fù)用分成了一下5個(gè)級(jí)別。

級(jí)別越低，粒度越小，復(fù)用的范圍越廣，但價(jià)值體現(xiàn)較低；級(jí)別越高，粒度越大，復(fù)用的價(jià)值越高，但復(fù)用范圍也比較局限。所以站在業(yè)務(wù)和價(jià)值角度上，都是先從最高的層次上去復(fù)用。只有上層無法實(shí)現(xiàn)復(fù)用，我們才會(huì)逐步向下層去尋找。但是有時(shí)候站在技術(shù)角度，我們習(xí)慣在低層次上去復(fù)用，因?yàn)檫@里最接近自己的工作，粒度越小，技術(shù)上越可控。

回到本節(jié)開始的問題，B系統(tǒng)的功能要復(fù)用A系統(tǒng)的功能，這個(gè)復(fù)用級(jí)別是最高的，如果能復(fù)用那會(huì)極大減少工作量降低成本，但這個(gè)級(jí)別的復(fù)用難度也是最大的，特別是異構(gòu)系統(tǒng)，就幾乎沒有可能了。

3. 復(fù)用是有粒度的

影響復(fù)用達(dá)成時(shí)間的因素很多，這些因素疊加起來可能導(dǎo)致復(fù)用所消耗的時(shí)間更多。因此對(duì)于一些時(shí)間特別敏感、由其決定生死的業(yè)務(wù)，在可復(fù)用組件未成熟，或者可復(fù)用組件支持團(tuán)隊(duì)的支持力度不夠時(shí)，可以不考慮復(fù)用。

不復(fù)用的情況就是我們通常講的煙囪系統(tǒng)，現(xiàn)在大環(huán)境的論調(diào)是煙囪系統(tǒng)不好，其在一個(gè)業(yè)務(wù)成熟的公司里確實(shí)不好。但是煙囪系統(tǒng)在業(yè)務(wù)早期變化大，快速野蠻生長(zhǎng)時(shí),由于不需要考慮復(fù)用,沒有太多的條條框框限制,提供了高效的開發(fā)效率支持，為業(yè)務(wù)的存活做了重要貢獻(xiàn)。

Gartner 在研究報(bào)告里提出了宏服務(wù)、小服務(wù)和微服務(wù)的粒度劃分：

• 宏服務(wù)——一種傳統(tǒng)的 Web 服務(wù)，支持將功能封裝于單體應(yīng)用內(nèi)。宏服務(wù)不支持獨(dú)立部署或擴(kuò)展， 它們只能部署為單體應(yīng)用的一部分，而且它們不需要微服務(wù)基礎(chǔ)架構(gòu)。
• 小服務(wù)——就服務(wù)粒度范圍而言，小服務(wù)是一種粗粒度、松散耦合、支持獨(dú)立部署的應(yīng)用組件。小服務(wù)需要微服務(wù)基礎(chǔ)架構(gòu)。
• 微服務(wù)——微服務(wù)處于粒度范圍的遠(yuǎn)端，是一種可獨(dú)立部署的組件，能夠支持單個(gè)應(yīng)用功能的實(shí)施。微服務(wù)可直接部署到微服務(wù)運(yùn)行時(shí)環(huán)境中，也往往具備專用數(shù)據(jù)存儲(chǔ)區(qū)。微服務(wù)需要微服務(wù)基礎(chǔ)架構(gòu)。

如果我們想對(duì)已存在系統(tǒng)的能力進(jìn)行復(fù)用，可以采用宏服務(wù)模式進(jìn)行，宏服務(wù)的模式適合做系統(tǒng)的集成和治理。我們對(duì)于新的業(yè)務(wù)和項(xiàng)目，剛開始建議采用小服務(wù)的方式進(jìn)行業(yè)務(wù)領(lǐng)域的拆分，不建議拆分的過細(xì)，這個(gè)小服務(wù)能滿足該需求的基本抽象即可。從適中的粒度開始，服務(wù)的粒度一定是業(yè)務(wù)推進(jìn)的過程中不斷演化的，創(chuàng)新業(yè)務(wù)推動(dòng)服務(wù)的粒度向更細(xì)的粒度裂變，而業(yè)務(wù)成熟穩(wěn)定后，又推動(dòng)服務(wù)向粗粒度方向聚合。站在復(fù)用的角度，優(yōu)先級(jí)是宏服務(wù)>小服務(wù)>微服務(wù)，當(dāng)然難度反之。

所以復(fù)用要根據(jù)自身團(tuán)隊(duì)發(fā)展情況，業(yè)務(wù)實(shí)際需要靈活把握，也要根據(jù)公司的發(fā)展階段，逐步的實(shí)現(xiàn)復(fù)用，總體來說復(fù)用的優(yōu)先級(jí)技術(shù)層面復(fù)用優(yōu)先于業(yè)務(wù)層面復(fù)用，團(tuán)隊(duì)內(nèi)的復(fù)用優(yōu)先于團(tuán)隊(duì)間的復(fù)用，項(xiàng)目級(jí)復(fù)用優(yōu)先于產(chǎn)品級(jí)復(fù)用。

二、如何更好的復(fù)用

老板要求復(fù)用有沒有錯(cuò)？沒有錯(cuò)！員工說復(fù)用太難是不是實(shí)情？是實(shí)情！作為技術(shù)領(lǐng)導(dǎo)者，我們的職責(zé)就是解決團(tuán)隊(duì)的困難，實(shí)現(xiàn)老板的目標(biāo)。具體如何更好的復(fù)用，老譚根據(jù)自己的工作經(jīng)驗(yàn)和對(duì)該問題的深度思考，提供一定的思路僅供參考。

1. 不要忽視技術(shù)棧的管理

站在復(fù)用的角度，不同的開發(fā)語言之間是很難復(fù)用的，雖然對(duì)于互聯(lián)網(wǎng)或者自運(yùn)營的信息化而言，還可以通過服務(wù)共享的方式實(shí)現(xiàn)復(fù)用，而對(duì)于我們更多以本地化交付的軟件產(chǎn)品研發(fā)而言，技術(shù)體系不統(tǒng)一對(duì)于復(fù)用和協(xié)同兼職就是噩夢(mèng)。

老譚在負(fù)責(zé)公司研發(fā)之前，整個(gè)公司沒有統(tǒng)一的技術(shù)棧，每個(gè)部門幾乎都有自己的技術(shù)棧，當(dāng)時(shí)存在.net，java，php等多種語言開發(fā)的系統(tǒng)，主流的Java語言還存在Jfinal、springboot、dubbo等不同的框架。

對(duì)于技術(shù)團(tuán)隊(duì)最容易的代碼程序級(jí)別的復(fù)用因?yàn)榧夹g(shù)體系的不統(tǒng)一而導(dǎo)致無法復(fù)用，團(tuán)隊(duì)資源無法流動(dòng)平衡的問題，這對(duì)于我們中小規(guī)模的研發(fā)團(tuán)隊(duì)來說就是災(zāi)難。分散的組織必然帶來不統(tǒng)一的技術(shù)架構(gòu)，這就是有名的康威定律（后面還會(huì)詳細(xì)介紹）。

結(jié)合我自己的工作經(jīng)歷，對(duì)于技術(shù)棧的管理提供以下思路供參考。

確定團(tuán)隊(duì)主流語言，主流開發(fā)框架，主流數(shù)據(jù)庫等；

我們確定了Java語言為主流語言；springboot為主要開發(fā)框架；采用SpringCloud的微服務(wù)架構(gòu)體系，；數(shù)據(jù)庫第一選擇為MySQL，新項(xiàng)目全部統(tǒng)一到MySQL。

減少非主流技術(shù)體系的資源投入，新的業(yè)務(wù)逐步以主流技術(shù)進(jìn)行；

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

逐步向前后端分離的開發(fā)方式轉(zhuǎn)變，大后端體系之后實(shí)行大前端；

我們做技術(shù)的都清楚，后端穩(wěn)定，前端變化多端，前端的復(fù)用的優(yōu)先級(jí)是遠(yuǎn)弱于后端的，但是對(duì)老板們可就不一樣，后面的數(shù)據(jù)庫，服務(wù)接口啥的他們也看不見，最直觀的就是前端，所以不能忽視。我們最先確定下前端的開發(fā)框架VUE，防止前端技術(shù)的分化，傳統(tǒng)的前端開發(fā)根據(jù)實(shí)際需要有準(zhǔn)備實(shí)現(xiàn)架構(gòu)的轉(zhuǎn)變。其實(shí)這個(gè)轉(zhuǎn)變?cè)谇捌谑切枰黾油度氲模吘箖商左w系前期要并行，老板質(zhì)問為何要切換前后端分離，當(dāng)然她不知道的是，如果我們不轉(zhuǎn)變，我們現(xiàn)在連人（前后通吃）都招不到。

中間件不能濫用，新技術(shù)引進(jìn)需要走技術(shù)評(píng)審。

技術(shù)人員都比較熱衷各種中間件的使用，對(duì)新技術(shù)趨之若鶩，追求新技術(shù)沒有錯(cuò)，創(chuàng)新也需要鼓勵(lì)。但這些都需要管理，因?yàn)樽鳛榧夹g(shù)領(lǐng)導(dǎo)人，我們必須站在團(tuán)隊(duì)整體角度平衡成本、效率、效益的關(guān)系，所以通過技術(shù)評(píng)審，我們既能引進(jìn)新技術(shù)，又能管理技術(shù)引進(jìn)帶來的學(xué)習(xí)成本，大面積推廣的時(shí)機(jī)和條件。

通過這一系列的措施，我們至少在技術(shù)底層取得了適度的統(tǒng)一，不同團(tuán)隊(duì)之間的技術(shù)交流就消除了障礙，大家就容易共同積累，促進(jìn)共享。

2. 統(tǒng)一架構(gòu)，構(gòu)建平臺(tái)級(jí)應(yīng)用

技術(shù)棧的統(tǒng)一，只能讓我們做到LV1和LV2層級(jí)的復(fù)用能力，再往上走就涉及到功能層面和業(yè)務(wù)層面了，而這更接近老板的視角了。所以實(shí)現(xiàn)更高層次的復(fù)用是每個(gè)技術(shù)領(lǐng)導(dǎo)人的追求，也是發(fā)揮自身專業(yè)能力的舞臺(tái)。

但在這個(gè)環(huán)節(jié)我們往往會(huì)出現(xiàn)大問題，就是不能根據(jù)實(shí)際情況因地制宜，架構(gòu)體系的彈性很大，沒有嚴(yán)格的標(biāo)準(zhǔn)，只有根據(jù)實(shí)際情況的平衡，平衡是考驗(yàn)技術(shù)領(lǐng)導(dǎo)人的架構(gòu)藝術(shù)，不要小瞧了這個(gè)能力。很多大廠的牛人去小企業(yè)做架構(gòu)，太多失敗的案例，不是架構(gòu)不好，是沒有用對(duì)地方。

1）對(duì)于小團(tuán)隊(duì)而言，統(tǒng)一架構(gòu)體系，單體應(yīng)用一樣很美

我們一貫的常識(shí)就是，越是獨(dú)立的，沒有太多耦合關(guān)系的組件越容易復(fù)用，過去煙囪似的單體系統(tǒng)難以復(fù)用就是模塊和系統(tǒng)本身耦合太深而造成復(fù)用改造的成本很大。這個(gè)理論是對(duì)的，但我認(rèn)為不全面，完全去除耦合是不現(xiàn)實(shí)的，只是耦合的深淺和范圍是需要管理的，如果復(fù)用組件的使用者一樣耦合在同樣一個(gè)環(huán)境中，其實(shí)也是可以復(fù)用的。這就像A系統(tǒng)要復(fù)用B系統(tǒng)的模塊其實(shí)是很困難的，因?yàn)轳詈系沫h(huán)境不一樣，依賴的基礎(chǔ)不同；但是A系統(tǒng)內(nèi)要復(fù)用自身系統(tǒng)的某模塊卻非常容易，因?yàn)橐蕾嚟h(huán)境是一樣的。所以，小團(tuán)隊(duì)如果在代碼層級(jí)能夠統(tǒng)一成一個(gè)應(yīng)用，然后通過插件化、代碼級(jí)的組件化對(duì)業(yè)務(wù)模塊進(jìn)行抽象和管理，單體系統(tǒng)依然是很美的。

我在七八年前帶一個(gè)小型互聯(lián)網(wǎng)團(tuán)隊(duì)，自己花了兩三個(gè)月時(shí)間寫了一套基于JFinal（當(dāng)時(shí)剛開始推出的小眾框架，現(xiàn)在已經(jīng)非常流行了）插件化的腳手架系統(tǒng)作為我們團(tuán)隊(duì)所有業(yè)務(wù)開發(fā)的載體，這么多年過去了，這個(gè)系統(tǒng)依然在健壯的運(yùn)行，業(yè)務(wù)也在不斷持續(xù)的開發(fā)著。我們實(shí)施的泛微最新一代的OA系統(tǒng)，如此龐大的系統(tǒng)，通過部署結(jié)構(gòu)來看，其實(shí)也是一個(gè)大單體應(yīng)用。所以，不是單體系統(tǒng)不好，只是當(dāng)它太大以后，我們沒有能力管理好它而已。

2）有一定規(guī)模的技術(shù)組織，構(gòu)建統(tǒng)一平臺(tái)底座

復(fù)用的成本以及難度往往都是組織規(guī)模擴(kuò)大，尤其分化后才迅速提升的。在一個(gè)多組織中實(shí)現(xiàn)組件的復(fù)用需要建立統(tǒng)一的標(biāo)準(zhǔn)，也不要完全去除依賴，而是盡可能依賴單一，大家都依賴這個(gè)單一的東西，這個(gè)依賴對(duì)復(fù)用的影響就會(huì)降低，所以一定規(guī)模的技術(shù)組織，要通過構(gòu)建統(tǒng)一的平臺(tái)底座，將共享組件沉淀在平臺(tái)底座上，讓不同的業(yè)務(wù)共同依賴同一套底層的環(huán)境，通過平臺(tái)底座的共享能力，實(shí)現(xiàn)各垂直業(yè)務(wù)的橫向交流和協(xié)同。

這種模式特別適合軟件產(chǎn)品研發(fā)的企業(yè)，構(gòu)建在厚實(shí)的平臺(tái)之上的產(chǎn)品研發(fā)，既高效又善于組合和擴(kuò)展，產(chǎn)品的邊界不會(huì)因?yàn)橄到y(tǒng)的隔離而變的僵化。

而且構(gòu)建平臺(tái)底座既適合單體架構(gòu)的應(yīng)用也適合分布式的微服務(wù)架構(gòu)，平臺(tái)底座其實(shí)一個(gè)組織有規(guī)劃的復(fù)用的體系建設(shè)。下圖是筆者團(tuán)隊(duì)建設(shè)的平臺(tái)體系，后臺(tái)引擎由架構(gòu)團(tuán)隊(duì)主要負(fù)責(zé)建設(shè)，業(yè)務(wù)組件（屬于中臺(tái)范疇）由各研發(fā)團(tuán)隊(duì)根據(jù)業(yè)務(wù)領(lǐng)域分別負(fù)責(zé)構(gòu)建，供做參考。

3）企業(yè)級(jí)的復(fù)用體系–中臺(tái)架構(gòu)

中臺(tái)的廣義上的定義：企業(yè)級(jí)能力復(fù)用平臺(tái)。

雖然我們的一體化平臺(tái)涉及到中臺(tái)服務(wù)部分，但是作為研發(fā)企業(yè)，我們的中臺(tái)架構(gòu)和服務(wù)是面向客戶去交付的，幫助甲方客戶構(gòu)建中臺(tái)能力。一般情況我們所說的中臺(tái)，不是廠商的中臺(tái)解決方案，而是一個(gè)互聯(lián)網(wǎng)企業(yè)或者一個(gè)傳統(tǒng)企業(yè)為了滿足自身數(shù)字化轉(zhuǎn)型的需要而構(gòu)建的中臺(tái)體系，它是面向企業(yè)運(yùn)營的中臺(tái)體系而不是面向項(xiàng)目交付的中臺(tái)服務(wù)。

廣義上的中臺(tái)范圍是非常大的，涵蓋了企業(yè)運(yùn)營的方方面面，而我們更關(guān)注的是企業(yè)中臺(tái)的載體即數(shù)字化運(yùn)營中臺(tái)。企業(yè)首先通過信息化建設(shè)，將企業(yè)內(nèi)在業(yè)務(wù)從線下搬到了線上，這個(gè)階段我們構(gòu)建了一個(gè)個(gè)的單體系統(tǒng)，這些系統(tǒng)集成都不容易，復(fù)用幾乎就更沒可能。最終導(dǎo)致大量的重復(fù)開發(fā)建設(shè)，同時(shí)還帶了更大的系統(tǒng)治理的成本。

進(jìn)入數(shù)字化時(shí)代，甚至是智能化時(shí)代，面對(duì)激烈的市場(chǎng)競(jìng)爭(zhēng)，企業(yè)降本增效的需求愈發(fā)迫切，更好的復(fù)用，更敏捷的建設(shè)是企業(yè)迫切的愿望，中臺(tái)體系的提出，是順應(yīng)這個(gè)時(shí)代的產(chǎn)物，所以企業(yè)關(guān)注中臺(tái)，嘗試中臺(tái)是對(duì)的，至于為什么會(huì)失敗，后面的文章再去探討。

對(duì)于一個(gè)有技術(shù)開發(fā)能力的企業(yè)，比如互聯(lián)網(wǎng)企業(yè)，科技企業(yè)等，中臺(tái)的復(fù)用能力不要極端的追求新建，雖然這樣比較簡(jiǎn)單，但對(duì)企業(yè)來說著實(shí)浪費(fèi)，如上圖所示，首先單體應(yīng)用架構(gòu)向業(yè)務(wù)中臺(tái)架構(gòu)演變，能利用則利用，能改造就盡量不要新建，能沉淀就盡量沉淀。

4. 根據(jù)康威定律，組織要支撐

被復(fù)用的組件需要進(jìn)行修改定制時(shí)，我們需要組件的維護(hù)方提供支持，此時(shí)就需要相應(yīng)的溝通協(xié)調(diào)成本。若組件提供方與組件使用方?jīng)]有任何利益關(guān)系，甚至于其利益是沖突的，那么組件提供方則缺乏動(dòng)力為使用者提供支持，甚至于拒絕提供服務(wù)。這時(shí)候溝通協(xié)調(diào)成本將會(huì)特別的大。（本文提到的那位研發(fā)負(fù)責(zé)人其實(shí)很大程度上也面臨這個(gè)問題，協(xié)調(diào)不動(dòng)組件方修改，自己改又太有難度，與其不如自己造一個(gè)輪子了）

這個(gè)問題實(shí)際上不是一個(gè)軟件技術(shù)問題，這涉及到組織架構(gòu)的設(shè)計(jì)。因此要降低溝通協(xié)調(diào)成本，則需要更高一級(jí)的領(lǐng)導(dǎo)設(shè)計(jì)調(diào)整組件提供方與使用方之間的關(guān)系，使其達(dá)到利益相關(guān)、一致。如下圖所示，每個(gè)人在自己管轄的范圍之內(nèi)都相對(duì)比較容易復(fù)用和協(xié)作（對(duì)應(yīng)顏色的橫向箭頭），而一旦超出了這個(gè)范圍，復(fù)用和協(xié)同的難度和成本就會(huì)急劇增加。

重溫下康威定律：

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)

設(shè)計(jì)系統(tǒng)的組織其產(chǎn)生的設(shè)計(jì)等價(jià)于組織間的溝通結(jié)構(gòu)。

已經(jīng)五十多年的康威定律依然是指導(dǎo)我們做系統(tǒng)設(shè)計(jì)和企業(yè)架構(gòu)的重要定律，它詮釋了系統(tǒng)架構(gòu)和組織架構(gòu)的對(duì)應(yīng)關(guān)系，其實(shí)這非常容易理解，任何事情都是有人去執(zhí)行的，人的組織結(jié)構(gòu)決定了系統(tǒng)的架構(gòu)設(shè)計(jì)，一個(gè)分散型的組織很難有高度統(tǒng)一的架構(gòu)，也注定難以復(fù)用。當(dāng)然一個(gè)集權(quán)化的組織，復(fù)用和協(xié)作的成本就很低，相反組織的活性會(huì)降低，自主性和創(chuàng)新性不足。

老板最重要的任務(wù)其實(shí)是通過設(shè)計(jì)組織的結(jié)構(gòu)，來匹配做事情的邏輯，最終實(shí)現(xiàn)自己想要的效果，否則在一個(gè)人、物、事不匹配的環(huán)境里，只有一腔的熱血、殷切的希望和憤怒的咆哮也是無濟(jì)于事，這便是規(guī)律的不可違背性。

正如阿里巴巴實(shí)施中臺(tái)戰(zhàn)略，CTO行癲（張建峰）親自掛帥負(fù)責(zé)中臺(tái)事業(yè)群，負(fù)責(zé)中臺(tái)戰(zhàn)略的推進(jìn)。同時(shí)作為當(dāng)時(shí)整個(gè)集團(tuán)的CTO，在各事業(yè)部橫向推行中臺(tái)架構(gòu)體系又有誰不配合呢，可見阿里中臺(tái)戰(zhàn)略的執(zhí)行力有多強(qiáng)，這也是為什么阿里的中臺(tái)能夠成為行業(yè)的標(biāo)桿，這與其組織的設(shè)計(jì)是分不開的。

最后總結(jié)一下，復(fù)用是老板的合理需求，是技術(shù)領(lǐng)導(dǎo)人的核心職責(zé)，是所有技術(shù)人的全局意識(shí)。但復(fù)用的達(dá)成，不是老板的念念不忘，不是技術(shù)領(lǐng)導(dǎo)人的行政要求，也不是所有技術(shù)人的滿腹牢騷，它需要一個(gè)體系的設(shè)計(jì)，一個(gè)組織的支撐，一個(gè)相互信任的團(tuán)隊(duì)文化，一個(gè)不斷完善的過程。任重而道遠(yuǎn)，讓我們勵(lì)志前行！

#專欄作家#

菜根老譚，微信公眾號(hào)：CGLT_TAN，人人都是產(chǎn)品經(jīng)理專欄作家。經(jīng)歷程序員、技術(shù)Leader、產(chǎn)品經(jīng)理、研發(fā)Leader等多種崗位。現(xiàn)負(fù)責(zé)某科技公司整體產(chǎn)品研發(fā)，擅長(zhǎng)企業(yè)IT架構(gòu)及互聯(lián)網(wǎng)產(chǎn)品架構(gòu)。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議