谈复用的成本与中台的建设

今晚准备在家作饭，但少了一把菜刀，你会问邻居家借么？

复用的成本

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

当出现某些类似功能的代码时，咱们应该将通用部分代码与特异部分代码分离，以达到复用通用代码，下降总体复杂度的目的。

按照个人理解里，一个好的程序，压缩率应该接近于0,没有任何能够精简的部分（变量名、方法名等除外）

复用带来不少好处，如：

• 利用已有资源快速开发
• 代码更清晰易懂
• 代码能够统一修改管控
• 数据能够统一分析利用
• 下降系统总体复杂度

然而达到复用的目的并不是没有成本，从总体上看 复用的成本包含：

• 发现可复用逻辑的成本
• 学习可复用逻辑的成本
• 扩展可复用逻辑的成本
• 修改可复用逻辑的成本

若是整个系统是SOLO的，那么发现和学习的成本近乎于0（前提是你还记得你写过什么东西），进行复用只包含扩展和修改代码的成本。

但一个系统可能很大，完成系统所需的人数多是：

• 几我的的小组
• 几十我的的室
• 几百人的部门
• 几千人的公司
• 几万人的集团

当咱们能在公司级或者集团级较好地处理复用这件事件时，咱们就称其为 中台（固然，部门中台、室中台也能够，只是复用在企业级别时换个名称显得更高大上）

但让咱们回想一下本身所在的小组里，已经处理掉了重复代码，达到了完美的复用了么？若是已经完美复用了，那你所在的室呢？

咱们发现，随着人数的增长以及代码数量的增长，未通过良好设计及组织，发现及使用可复用代码的难度将会急剧增长。

同时，若复用发生在利益关系不一致的不一样组织（室、部门、公司、集团）里，则复用不必定能被执行。即便复用能够执行，但需求方与提供方对任务的优先级定义不一致，提供方响应速度跟不上时，那也可能使得复用没法产生。

实现DRY可能只须要一个优秀的程序员，但实现Don't Repeat Ourselve就没这么简单了。

对于需求方团队是否要复用某个其余团队的组件，能够由一个公式来表示：

实现复用所需时间 <= 业务容许的响应时间 
AND （发现成本 + 学习成本 + 沟通协调成本 + 使用成本） <= 从新作的成本

当上述表达式为“真”，那么咱们就能够考虑复用。

下面针对这个公式，进行分段讨论。

实现复用所需的时间

复用并非总能节约开发时间：

• 发现可复用组件须要时间
• 学习可复用组件须要时间
• 可复用组件准入须要时间
  • 使用本公司的组件服务所需的流程制度
  • 使用其余公司的组件服务所需的商务合做的沟通
• 可复用组件的扩展须要时间
• 可复用组件的修改须要时间
  • 复用组件须要通过多个业务验证才能达到一个较为稳定的状态，在此以前业务协助可复用组件演化须要更多的时间
  • 可复用组件的维护团队可能跟使用者团队的利益关系不一致，致使修改的优先级更低

影响复用达成时间的因素不少，这些因素叠加起来可能致使复用所消耗的时间更多。所以对于一些时间特别敏感、由其决定生死的业务，在可复用组件未成熟，或者可复用组件支持团队的支持力度不够时，能够不考虑复用。

不复用的状况就是咱们一般讲的烟囱系统，如今大环境的论调是烟囱系统很差，其在一个业务成熟的公司里确实很差。可是烟囱系统在业务早期变化大，快速野蛮生长时,因为不须要考虑复用,没有太多的条条框框限制,提供了高效的开发效率支持，为业务的存活作了重要贡献。

复用的发现成本

是什么影响了复用的发现成本？我认为主要是：

• 发现复用的方式

在几我的的小组维护的系统里，咱们倾向于不产生任何重复代码。在实现某些功能时，须要肯定有没有已有的枚举、类、方法、DAO时咱们会问小组长，或者直接在小群里吼一声。

在几十我的的室里，咱们小组要用其余小组系统的接口时，一般会由小组负责人之间拉会议沟通协调，确认对应接口是否存在，是否合适，如何使用，改造方案等。

这些发现都依赖于人，但而人的记忆是不可靠的，可能会遗忘记错，而且一旦涉及到人之间的交流的话，效率就会下降（要打断对方工做、等对方回应、要组织会议等）。所以咱们要下降复用发现成本最好的方式是下降对人的依赖。

单一系统的复用发现方式

下降单一系统（单个git repo/单个eclipse项目）的复用发现成本的一种作法就是合理分包，在写好代码的同时，就把复用发现的手段给完善了。

一个合理分包的代码里，咱们可以快速地推断出咱们所须要的东西在哪里、是否存在。

而一个不合理分包的代码，咱们会看到几十上百个类平铺于一个层级，用人眼根本找不到想要的类，必须依靠记忆中依稀记得的关键字来进行搜索。

那怎么作到合理分包？很简单，只要保持一个简单的原则

每一个包的文件数量不超过10个，若超过10个则分裂成两到三个子包

但固然，包的名字必须是有含义且一眼能看明白的，这样才能让咱们逐层找到咱们要的文件。这实际上是一种通用的控制复杂度的方法，可见文末另一篇文章《从分治的思想到架构的设计》

下降多系统间复用发现成本

下降多个系统间复用发现成本的一种作法是搭建一个WEB系统用于统一发现可复用组件。

这个管理系统应该能够按照分类逐层查找复用组件，也能够按照关键字查找对应的复用组件。阿里云官方网站咱们能够做为一种参考。

但固然，构造这么一个系统也是须要消耗大量人力物力的，在初期使用Wiki+Swagger的形式将接口信息提供出去也是不错的选择。

学习的成本

一个接口学习的成本大小与接口大小成正比。

接口大小指代要正确使用该接口所需具有的知识，如：

• 所需的参数数量
• 使用的前置条件
• 隐含的坑
• ......

这些知识，咱们也能够称其为“耦合”。

咱们知道，耦合要越小越好，这样才能让经过接口交互的两个模块更容易地独立演进。

同时，耦合越小，咱们学习这个接口的成本就越小。

固然，影响学习的成本除了接口自身要良好设计以外，还须要完善的文档与例子，这也是下降学习成本的关键。

沟通协调成本

复用的沟通协调成本在越大的组织里有可能越大。

被复用的组件须要进行修改定制时，咱们须要组件的维护方提供支持，此时就须要相应的沟通协调成本。

若组件提供方与组件使用方没有任何利益关系，甚至于其利益是冲突的，那么组件提供方则缺少动力为使用者提供支持，甚至于拒绝提供服务。这时候沟通协调成本将会特别的大。

这个问题实际上不是一个软件技术问题，这涉及到组织架构的设计。所以要下降沟通协调成本，则须要更高一级的领导设计调整 组件提供方与使用方之间的关系，使其达到利益相关、一致。

这实际上也是不少文章讲的，（企业级）中台是一把手工程的由来，其并不是由技术人员就能推进的事情。

使用成本

当咱们使用各类云服务时，咱们须要付费，在一些较大的公司里，使用别的部门的服务也是须要付出相关成本的,当复用这些组件的成本超过本身从新作一份的成本时，咱们就会考虑本身再搞一套

企业级复用的例子

如下是阿里谢纯良分享的一个关于系统复用的图：

图中包含几层

• 平台层
  • 可复用的通用算法、通用中间件
• 共享业务能力层
  • 可复用的通用能力，包括订单、支付、商品等
  • 多应用通用功能的逻辑中心化及数据中心化
• 应用层
  • 按照应用所需的流程组装共享业务能力
  • 应用可包含电商、客服、CRM等
• 扩展层
  • 经过扩展应用层预留的扩展点，以知足特定渠道场景的需求

如下是我以前公司系统间进行复用的图：

图中最顶端的对应的是阿里图中的应用层，其他的对应的是共享业务能力层。

这里共享能力层里的各类能力也有可能互相组合造成一些新的能力，如图中的投资组合服务 以及 套利工具服务。

若是咱们愿意，能够把没有依赖于其余服务的服务叫原子能力服务，组合了其余原子能力服务的服务叫作组合能力服务，但这些名词仅仅在特定场景特定公司内起做用，咱们做为一个程序员要穿透这些名词看到本质。

就像中台这个名词同样，它的本质就是企业级的复用，达到这个复用目的途径有千万种，只要达到这个目的他就是中台。

就像微服务这个名词同样，它的本质目的就是为了应对业务快速变化，而不得已地将服务作小。只要咱们达到了应对业务快速变化这个目的，咱们就成功了。而其中带来的所谓 配置中心、注册中心、熔断、分布式事务等等，他们是不得不引入的一些额外成本，而不是成果。

总结

中台是最近火起来的概念，但它只是新瓶装旧酒，本质是在企业层级进行复用的一个描述。

复用则是每个程序员应有的觉悟，但规模是万恶之源，任何事情规模增大了，实施的难度都会急剧增长。

进行复用（或者说进行中台建设）并不是没有代价，咱们须要权衡复用的利弊后，才能作出正确的决策。

关于做者

在两家排名前三的股份制商业银行及互金创业公司工做过，目前在排名前二的互联网银行工做，作过业务，作过中间件，作过架构，也带太小团队。

欢迎加微信及公众号交流技术，请备注名字+公司。

 

我的微信：

 

公众号