啥都复用不了，还谈什么狗屁中台

编纂导读：说到中台，许多企业只管都在搭建，然则对它的相识不够深。好比一套体系，为什么不克不及复用。复用必要一个别系的设计，一个组织的支持，一个互相相信的团队文化，一个赓续完美的进程。本文作者从自身事情阅历动身，对此进行了阐发，一路来看看吧。

比来一个项目报告请示的时刻，我下面的一个研发卖力人被老板“骂”了一顿，缘故原由是老板以为这个功效之前某某项目，某某体系做过了，为啥要从新开发，拿来用就行，成果这位研发卖力人讲不清晰，或者技术职员太其实而不知道该若何表达，末了也把我叫曩昔数落一番。

我不怪老板，她的设法主意是可以懂得的，站在投入和产物角度，不要反复制作轮子是没有错的；我也不克不及完全怨我的部属，有些器械的复用和集成切实其实是不像做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等多种岗亭。现卖力某科技公司整体产物研发，长于企业IT架构及互联网产物架构。

本文原创宣布于大家都是产物司理。未经许可，制止转载

题图来自Unsplash，基于CC0协定