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

图片来自 包图网

结果这位研发担任人讲不分明，或许技术人员太真实而不知道该如何表白，最后也把我叫过去数落一番。

我不怪老板，她的想法是可以了解的，站在投入和产品角度，不要重复制作轮子是没有错的；我也不能齐全怨我的下属，有些物品的复用和集成确实是不像做 PPT那样七拼八凑那样容易的。

双方都没错，那疑问出在哪呢?我将这个疑问发到技术交换群里，大家讨论的也挺热烈，看来这个疑问确实也是大家广泛存在的疑问。

有人吐槽老板疑问技术，须要上课的；有人倡导须要沟通，须要始终磨他，盘他的；还有人还倡导让老板介入几个典型名目，让他多体会体会的;最后咱们把疑问归纳到“信赖”二字，原来一切的疑问都可以经过“信赖”来处置的。

确实信赖可以处置任何疑问，老板假设一点疑问，他可以信赖他的 CTO 能很好的处置这个事件；假设老板很懂，他就会亲身处置这个疑问了。

当天咱们不讨论老板的疑问，他的需求自身没有疑问，假设我是老板我也会要求不做重复投入。

本文我更多要站在技术指导者的视角去尝试解析这个疑问，寻求肯定的处置打算。

系统复用为什么难?

还是从事例说起，咱们做医疗行业的运行系统，肥壮档案的控制是一个十分广泛的配置。

咱们在某系统里曾经开发了稍微完整陷的模块，于是乎只需其余运行要开发肥壮档案的配置，老板就会说这个咱们都做过了，拿上来用就好了，为什么要从新开发?

我来尝试的回答下这个为什么很难复用：

①复用是有老本的

DRY 准则(Don't Repeat Yourself)置信每一位程序员都应该知道。其指代的是咱们写程序时，不要一遍又一遍地编写相似的代码。

当发生某些相似配置的代码时，咱们应该将通用局部代码与特异局部代码分别，以到达复用通用代码，降落全体复杂度的目的。

复用这个情理咱们都懂，咱们也在实践的开发环节中真正去践行的，但复用其实是有老本的。

这也是为什么咱们知道重复制作轮子不好，但却又不停的的在制作轮子，由于很多时刻造一个新轮子比变革一个轮子或许更快，老本更低。

那么复用有哪些老本呢?

发现可复用组件的老本 ：很多时刻咱们并不是不想复用，而是不知道是不是存在咱们须要的轮子，从哪里可以找到这个轮子。

正如本文最开局的那位研发担任人，他或许真的不分明哪个团队有他可复用的轮子，而老板看到的范围更广，所以她更分明。这个和组织控制和知识控制无关。

学习可复用组件的老本 ：他天然的轮子有时刻很难了解它外部的结构和逻辑，就要去学习他天然轮子的设计和逻辑，这个自身是存在学习老本的，假设对方的设计和成功与自己的思绪存在出入的时刻，又会十分的顺当。

扩展可复用组件的老本 ：前天然的轮子都是用在他过后的那个场景或许业务中，当这个轮子切换到新的场景和业务中的时刻，你会发现 100%的可复用基本上是没有的。

这时刻就牵扯到关于这个轮子的扩展以适用新的业务，先不说这个扩展变革是一切者口头还是经常使用者口头(前面有一个章节专门讨论组织的逻辑)，扩展总是有老本。

修正可复用组件的老本 ：有时刻组件的形象才干不够，无法扩展，或许扩展的期间老本太高，或许组件一切者不情愿允许，复用者或许驳回间接拿上来修正的状况。

修正的老本是一个层面，但把期间拉长来看，组件修正后就和原组件分化了，未来双方的新配置也无法相互复用了。

②复用是有级别的

普通状况，复用的老本会由于复用的组件的内容不同，所在组织的相关亲密，它的老本是不一样的。

比如只是复用一段程序，就相当方便，假设复用一个系统配置就很艰巨;假设复用同一个团队的组件就相当方便，假设跨团队跨组织的复用就会变得艰巨。

所以复用也是有级别的，为了更好的了解我把复用分红了一下 5 个级别：

级别越低，粒度越小，复用的范围越广，但价值表现较低;级别越高，粒度越大，复用的价值越高，但复用范围也比拟局限。

所以站在业务和价值角度上，都是先从最高的档次下来复用。只要高层无法成功复用，咱们才会逐渐向高层去寻觅。

但是有时刻站在技术角度，咱们习气在低档次下来复用，由于这里最凑近自己的上班，粒度越小，技术上越可控。

回到本节开局的疑问，B 系统的配置要复用 A系统的配置，这个复用级别是最高的，假设能复用那会极大缩小上班量降落老本，但这个级别的复用难度也是最大的，特意是异构系统，就简直没有或许了。

③复用是有粒度的

影响复用达成期间的要素很多，这些要素叠加起来或许造成复用所消耗的期间更多。

因此关于一些期间特意敏感、由其选择生死的业务，在可复用组件未成熟，或许可复用组件允许团队的允许力度不够时，可以不思索复用。

不复用的状况就是咱们通常讲的烟囱系统，如今大环境的论调是烟囱系统不好，其在一个业务成熟的公司里确实不好。

但是烟囱系统在业务早期变动大，极速横蛮生长时，由于不须要思索复用，没有太多的条条框框限度，提供了高效的开发效率允许，为业务的存活做了关键奉献。

Gartner 在钻研报告里提出了宏服务、小服务和微服务的粒度划分：

假设咱们想对已存在系统的才干启动复用，可以驳回宏服务形式启动，宏服务的形式适宜做系统的集成和控制。

咱们关于新的业务和名目，刚开局倡导驳回小服务的形式启动业务畛域的拆分，不倡导拆分的过细，这个小服务能满足该需求的基本形象即可。

从适中的粒度开局，服务的粒度肯定是业务推进的环节中始终演化的，翻新业务推进服务的粒度向更细的粒度裂变，而业务成熟稳固后，又推进服务向粗粒度方向聚合。

站在复用的角度，优先级是宏服务>小服务>微服务，当然难度反之。

所以复用要依据自身团队开展状况，业务虚际须要灵敏掌握，也要依据公司的开展阶段，逐渐的成功复用。

总体来说复用的优先级技术层面复用优先于业务层面复用，团队内的复用优先于团队间的复用，名目级复用优先于产品级复用。

如何更好的复用

老板要求复用有没有错?没有错!员工说复用太难是不是实情?是实情!作为技术指导者，咱们的职责就是处置团队的艰巨，成功老板的指标。

详细如何更好的复用，老谭依据自己的上班阅历和对该疑问的深度思索，提供肯定的思绪仅供参考。

①不要漠视技术栈的控制

站在复用的角度，不同的开发言语之间是很难复用的，只管关于互联网或许自运营的消息化而言，还可以经过服务共享的形式成功复用。

而关于咱们更多以本地化交付的软件产品研发而言，技术体系不一致关于复用和协同兼职就是噩梦。

我在担任公司研发之前，整个公司没有一致的技术栈，每个部门简直都有自己的技术栈，过后存在 .net，Java，PHP 等多种言语开发的系统，干流的 Java言语还存在 Jfinal、SpringBoot、Dubbo 等不同的框架。

关于技术团队最容易的代码程序级别的复用由于技术体系的不一致而造成无法复用，团队资源无法流动平衡的疑问，这关于咱们中小规模的研发团队来说就是劫难。

扩散的组织肯定带来不一致的技术架构，这就是有名的康威定律(前面还会详细引见)。

联合我自己的上班阅历，关于技术栈的控制提供以下思绪供参考：

确定团队支谣言语，干流开发框架，干流数据库等：咱们确定了 Java 言语为支谣言语;SpringBoot 为关键开发框架;驳回 SpringCloud的微服务架构体系;数据库第一选用为 MySQL，新名目所有一致到 MySQL。

缩小非干流技术体系的资源投入，新的业务逐渐以干流技术启动：我之前团队经常使用比拟小众的 JFinal，雷同向干流框架 SpringBoot 切换;缩小Dubbo 的经常使用范围;严厉控制非 Java 体系的资源投入，新业务可以驳回 Java 开发的混合体系。

逐渐向前后端分别的开发形式转变，大后端体系之后履行大前端：咱们做技术的都分明，后端稳固，前端变动无常，前端的复用的优先级是远弱于后端的。

但是对老板们可就不一样，前面的数据库，服务接口啥的他们也看不见，最直观的就是前端，所以不能漠视。

咱们最先确定下前端的开发框架 VUE，防止前端技术的分化，传统的前端开发依据实践须要有预备成功架构的转变。

其实这个转变在前期是须要参与投入的，毕竟两套体系前期要并行，老板质问为何要切换前后端分别，当然她不知道的是，假设咱们不转变，咱们如今连人(前后通吃)都招不到。

两边件不能滥用，新技术引进须要走技术评审：技术人员都比拟热衷各种两边件的经常使用，对新技术趋之若鹜，谋求新技术没有错，翻新也须要激励。

但这些都须要控制，由于作为技术指导人，咱们肯定站在团队全体角度平衡老本、效率、效益的相关，所以经过技术评审，咱们既能引进新技术，又能控制技术引进带来的学习老本，大面积推行的机遇和条件。

经过这一系列的措施，咱们至少在技术底层取得了过度的一致，不同团队之间的技术交换就消弭了阻碍，大家就容易独特积攒，促成共享。

②一致架构，构建平台级运行

技术栈的一致，只能让咱们做到 LV1 和 LV2 层级的复用才干，再往上走就触及到配置层面和业务层面了，而这更凑近老板的视角了。

所以成功更高档次的复用是每个技术指导人的谋求，也是施展自身专业才干的舞台。

但在这个环节咱们往往会发生大疑问，就是不能依据实践状况量体裁衣，架构体系的弹性很大，没有严厉的规范，只要依据实践状况的平衡，平衡是考验技术指导人的架构艺术，不要小瞧了这个才干。

很多大厂的牛人去小企业做架构，太多失败的案例，不是架构不好，是没有用对中央。

(1)关于小团队而言，一致架构体系，单体运行一样很美

咱们一向的知识就是，越是独立的，没有太多耦合相关的组件越容易复用，过去烟囱似的单体系统难以复用就是模块和系统自身耦合太深而形成复用变革的老本很大。

这个通常是对的，但我以为不片面，齐全去除耦合是不事实的，只是耦合的深浅和范围是须要控制的，假设复用组件的经常使用者一样耦合在雷同一个环境中，其实也是可以复用的。

这就像 A 系统要复用 B 系统的模块其实是很艰巨的，由于耦合的环境不一样，依赖的基础不同;但是 A系统内要复用自身系统的某模块却十分容易，由于依赖环境是一样的。

所以，小团队假设在代码层级能够一致成一个运行，而后经过插件化、代码级的组件化对业务模块启动形象和控制，单体系统依然是很美的。

我在七八年前带一个小型互联网团队，自己花了两三个月期间写了一套基于JFinal(过后刚开局推出的小众框架，如今曾经十分盛行了)插件化的脚手架系统作为咱们团队一切业务开发的载体。

这么多年过去了，这个系统依然在强健的运转，业务也在始终继续的开发着。

咱们实施的最新一代的 OA 系统，如此宏大的系统，经过部署结构来看，其实也是一个大单体运行。

所以，不是单体系统不好，只是当它太大，咱们没有才干控制好它而已。

(2)有肯定规模的技术组织，构建一致平台底座

复用的老本以及难度往往都是组织规模扩展，尤其分化后才迅速优化的。

在一个多组织中成功组件的复用须要树立一致的规范，也不要齐全去除依赖，而是尽或许依赖繁多，大家都依赖这个繁多的物品，这个依赖对复用的影响就会降落。

所以肯定规模的技术组织，要经过构建一致的平台底座，将共享组件积淀在平台底座上，让不同的业务独特依赖同一套底层的环境，经过平台底座的共享才干，成功各垂直业务的横向交换和协同。

这种形式特意适宜软件产品研发的企业，构建在厚实的平台之上的产品研发，既高效又擅长组合和扩展，产品的边界不会由于系统的隔离而变的僵化。

而且构建平台底座既适宜单体架构的运行也适宜散布式的微服务架构，平台底座其实一个组织有布局的复用的体系树立。

下图是笔者团队树立的平台体系，后盾引擎由架构团队关键担任树立，业务组件(属于中台范围)由各研发团队依据业务畛域区分担任构建，供做参考。

企业级的复用体系：中台架构

中台的狭义上的定义：企业级才干复用平台。

只管咱们的一体化平台触及到中台服务局部，但是作为研发企业，咱们的中台架构和服务是面向客户去交付的，协助甲方客户构建中台才干。

普通状况咱们所说的中台，不是厂商的中台处置打算，而是一个互联网企业或许一个传统企业为了满足自身数字化转型的须要而构建的中台体系，它是面向企业运营的中台体系而不是面向名目交付的中台服务。

狭义上的中台范围是十分大的，涵盖了企业运营的方方面面，而咱们更关注的是企业中台的载体即数字化运营中台。

企业首先经过消息化树立，将企业外在业务从线下搬到了线上，这个阶段咱们构建了一个个的单体系统，这些系统集成都不容易，复用简直就更没或许。最终造成少量的重复开发树立，同时还带了更大的系统控制的老本。

进入数字化时代，甚至是默认化时代，面对剧烈的市场竞争，企业降本增效的需求愈发迫切，更好的复用，更矫捷的树立是企业迫切的欲望。

中台体系的提出，是顺应这个时代的产物，所以企业关注中台，尝试中台是对的，至于为什么会失败，前面的文章再去讨论。

关于一个有技术开发才干的企业，比如互联网企业，科技企业等，中台的复用才干不要极其的谋求新建。

只管这样比拟方便，但对企业来说着实糜费，如上图所示，首先单体运行架构向业务中台架构演化，能应用则应用，能改培育尽量不要新建，能积淀就尽量积淀。

依据康威定律，组织要撑持：被复用的组件须要启动修正定制时，咱们须要组件的保养方提供允许，此时就须要相应的沟通协调老本。

若组件提供方与组件经常使用方没有任何利益相关，甚至于其利益是抵触的，那么组件提供方则缺乏能源为经常使用者提供允许，甚至于拒绝提供服务。

这时刻沟通协调老本将会特意的大。(本文提到的那位研发担任人其实很大水平上也面临这个疑问，协调不动组件方修正，自己改又太有难度，与其不如本天然一个轮子了)

这个疑问实践上不是一个软件技术疑问，这触及到组织架构的设计。因此要降落沟通协调老本，则须要更高一级的指导设计调整组件提供方与经常使用方之间的相关，使其到达利益相关、分歧。

如下图所示，每团体在自己管辖的范围之内都相对比拟容易复用和单干(对应色彩的横向箭头)，而一旦超出了这个范围，复用和协同的难度和老本就会急剧参与。

重温下康威定律：

Conway’s law: Organizations which design systems are constrained to producedesigns which are copies of the communication structures of theseorganizations.

- Melvin Conway(1967)

设计系统的组织其发生的设计等价于组织间的沟通结构。

曾经五十多年的康威定律依然是指点咱们做系统设计和企业架构的关键定律，它诠释了系统架构和组织架构的对应相关。

其实这十分容易了解，任何事件都是有人去口头的，人的组织结构选择了系统的架构设计，一个扩散型的组织很难有高度一致的架构，也注定难以复用。

当然一个集权化的组织，复用和单干的老本就很低，雷同组织的活性会降落，自主性和翻新性无余。

老板最关键的义务其实是经过设计组织的结构，来婚配做事件的逻辑，最终成功自己想要的成果，否则在一团体、物、事不婚配的环境里，只要一腔的热血、殷切的宿愿和愤怒的咆哮也是无济于事，这便是法令的无法违反性。

正如阿里巴巴实施中台策略，CTO 行癫(张建峰)亲身挂帅担任中台事业群，担任中台策略的推进。

同时作为过后整个团体的CTO，在各事业部横向推行中台架构体系又有谁不配合呢，可见阿里中台策略的行能源有多强，这也是为什么阿里的中台能够成为行业的标杆，这与其组织的设计是分不开的。

最后总结一下，复用是老板的正当需求，是技术指导人的外围职责，是一切技术人的全局看法。

但复用的达成，不是老板的朝思暮想，不是技术指导人的行政要求，也不是一切技术人的满腹怨言，它须要一集体系的设计，一个组织的撑持，一个相互信赖的团队文明，一个始终完善的环节。任重而道远，让咱们励志前行!

作者：老谭

简介：人人都是产品经理专栏作家。阅历程序员、技术 Leader、研发 Leader 等多种岗位，现任某公司产品研发担任人，擅长企业 IT架构及互联网产品架构。

编辑：陶家龙