自从马云参加完supercell后制定了阿里的中台战略以及华为提出的“让听得见炮火的人指挥战斗”后，令无数公司的领导趋之若鹜，提出“我们也要搭建中台”！中台的概念在此就不谈了，因为网上有关中台的文章特别多，每看一篇，在看的过程中觉得：嗯~真有道理。看完后：我刚刚看了啥？

从此怀疑人生，哈哈，也可能是笔者理解能力不够吧。正好最近参加了一场关于中台的技术座谈会，经过一番讨论最终得出一个结论，砖家说规模不到100亿不要搞中台！！(不愧是砖家，说的竟如此直白)介此有些想法，既然要做，那么该如何做？

在此此座谈会中，孩子王中台研发总监王海龙大佬分享了他们在走中台化道路所遇到的一些痛点。孩子王在走中台化的道路中，最初是拉上各业务线中最熟悉业务的人员一起划分抽取出沉淀业务作为中台服务。(沉淀业务：基本不会再有变更的业务)由于当初前端的逻辑都写到了后端，前端只负责展示，这么处理的好处在于：例如有一项功能要在IOS和Android实现，各开发人员实现的逻辑不一致，可能导致在IOS中是正常却在Android中出现了异常，此时把该逻辑放到后端实现，前端只负责展示就能避免由于多处实现造成的问题。最终拆分的中台依然包含了一些业务逻辑，显得颇为臃肿。于是又将其业务逻辑部分抽取出来，曰为：小前台。中台是搭建起来了，但耦合却增加了，当业务需求过来，如果涉及到修改，那么需要万分小心确认改动是否会影响到依赖中台的服务，否则将造成无法预估的后果。另外还存在灰色地带，当来了一个不太明确分类的业务时，还需要拉上各中台负责人召开会议讨论如何划分，划分给谁，增加了沟通的成本。

如此看来中台的建设并非是简单的资源整合，业务复用。在不讨论中台建设所带来组织架构丶部门的协调所带来的内耗的前提中，个人的见解是：在软件工程中，在支撑业务架构的同时尽可能的优化技术架构，通用的不变的抽取成组件，避免重复造轮子，耦合的尽可能想办法解耦等等。回归程序设计思想，从高内聚丶低耦合丶可扩展丶可复用，从面向过程到面向对象，从单体架构到微服务，这些过程不正是为了解决复杂的现实生活中我们所遇到的问题吗？因此中台化的思想并非是一个新概念，随着业务规模增大以及沉淀，我们是否需要将一些拥有共通的业务整合以解决新增一个相似业务需要重头开发的痛点呢？至此，文章开头的“不到100亿不要搞中台”算是豁然开朗，当规模上去，自然而然需要想办法去寻求更加合理的服务规划和治理，甚至组织架构的变更以快速应变业务量所带来的压力。当规模不大，业务变动频繁还要跟风瞎折腾搞什么中台，岂不是要累死一批人啊。像笔者本人公司也曾经经历过，自从我们后台的领导参加了某个中台技术大会回来后，也提出口号我们要做中台！但是产品丶测试、业务......也只是一脸懵逼的看着他，没有一个重量级的人物来推动根本推动不起来；还有就是业务线就几条，数据量也不大，纯粹就是自己找活给自己干......（此次参加完中台技术座谈会后我终于可以反驳领导了，咋们规模不到不能瞎搞，哈哈——纯属玩笑）

笔者认为大家所站的角度不同，看待事物的结果自然会有出入，但是都有所道理的。如果从大公司的角度来看，面对海量的业务，明明有一些相似业务却还要重头开发导致效率低，浪费研发资源。那么中台就是为了解决业务的能力最大复用，减少重复造轮子为目标，企业成立中台部门进行顶层规划设计，沉淀核心业务，贯通各组织实现高效的协作快速交付业务。如果站在笔者的角度，中台或许就是所谓的业务丶技术复用了。

最后，中台所给我的警醒：在做业务规划时，一定要多加考虑，千万不能听信产品的鬼话，“我们先上再说”，避免以后还要为此还债呐！