程序员与「中台」的爱恨交错

如果第二次看到我的文章，欢迎「文末」扫码订阅我的个人公众号「跨界架构师」）哟~ 

每周五11：45 按时送达。当然了，也会时不时加个餐～

我的第「115」篇原创敬上

 

 

大家好，我是Z哥。

这篇文章比较长，有5200+字，不过希望你能耐心看完，特别是程序员。

中台这个词，最近两年特别火，它的爆发源于2015年张勇在阿里发出的内部信中提到的“大中台，小前台”战略。随后吸引了很多人开始“追逐”它。也有很多人开始借着这概念来挣钱。

任何事物一旦开始受到炒作，很容易让人失去理性的思考。

我们先不论中台这个概念能火多久，是不是昙花一现。

它带来的变化，除了外界大肆宣扬的那些“好处”之外，还有什么？可能很多人没有考虑过，不知道你有考虑过吗？

 

任何事物都是有两面性的，并且从多个不同的角度来看待和解读有时候差异也很大。 

如果我们看不到背后更多的信息，哪怕追逐中台的道路是一条康庄大道，众人皆知的那条路上会挤满着人，竞争的惨烈程度自然不用说，很容易陷入到绝境。

与其是这样，不如思考一下，它的背后有些什么没被大家重视，甚至是忽略的。其中是不是同样藏着一些机会。

很多人认为中台好，我们得要去向中台演进、迭代、变化。因为，

• 能够避免重复功能建设和维护带来的重复投资

• 打通烟囱式系统间交互的集成和协作成本高昂，更快的响应用户的新需求，降低试错成本。

• 更易于业务沉淀和持续发展。

• ……

是的，没错，这些都是中台概念看得到的好处。

更是在经过了阿里和马云的品牌背书后，把它推上了风口浪尖。

 

但实际上，体现中台概念的事情，日常生活中就有很多。简单来说就是「整合」。比如，

• 过去你肚子饿了，想分别吃两家不同的店里的美食的话你得分别跑两个地方。而现在，外卖平台成为了你与商家之间的“中台”。你只要与外卖平台打交道，不管是几个店的食物，都能给你送来。 

• 曾经你用手机打电话，通过电视机看剧，通过收音机听广播；现在智能手机就可以全部满足你打电话+看剧+听广播。这里，智能手机就是“中台”。以后你就可以不用了解电视机、收音机怎么调频道了，只要在手机上切换不同的APP就好。 

• 瑞士军刀也是一个极其厉害的“中台”，可以开啤酒瓶、开红酒瓶、可以切东西等等。

• ……

你看，减少冗余、通过「复用」使得投入更少获得更多，是每个正常理性人都会去考虑和乐于接受的事情，并不是什么新鲜的东西。

那么我们来思考一下，为什么中台在这个时间节点出现、被宣传？而不是更早或者更晚？为什么势头越演越烈？

其实大家作为互联网从业者，心里也清楚原因。自从17年开始，裁员潮开启，并且越演越烈。而在这之前的行业热门的关键字还是“融资、估值”，一幅繁荣景象。 

另外，最近两年看到企业倒闭、跑路的新闻变多了。还包括一些知名企业的财务造假。

这些负面的消息无不体现着企业经营成本高企，入不支出的情况正在蔓延。

从市场上看，现在所谓的爆品、网红款出现的频次越来越快，一批爆品的崛起伴随着另一批爆品的没落。说明用户的需求变化也在越来越快，更加的捉摸不定。

再看技术层面。Gartner发布的2019年8月的技术成熟度曲线中，大量为我们熟知的新技术都处于泡沫和悲观阶段，大家所盼望的新动力源迟迟还未出现。

 

▲图片来源于Gartner官网，版权归原作者所有

在企业成本高企、市场变化速度加快、缺乏新的出路的大背景下，「提效降本」便成了大多数企业的选择。这是中台概念受到追捧的宏观因素。

不过，这些最多算是「天时」和「人和」，缺少了「地利」，这个事情其实还是成不了。

这个「地利」我认为是B/S架构的蓬勃发展。

因为B/S架构让一个软件有了做中台的资本，他让软件几乎完全隐藏到了服务端，在客户端只留下了小小的一个浏览器作为通往软件的入口。

如此一来，企业拥有了对软件更高的控制度、可以更自由的作出调整。

包括随后的移动端发展，也是建立在B/S架构所延伸的思想之上，与曾经的C/S架构已经大相径庭。

所以你也可以想象一下，假如当下还是一个C/S架构大行其道的时代，做中台的难度相比现在必然大大增加。甚至，中台的概念估计还没提出来呢。

  

对我们程序员群体来说，在这满足天时、地利、人和的“中台”背后，还隐藏着另一股暗流在涌动。这股暗流就是我们原来的生存空间在逐渐缩小。 

理由有三点。

  

01  中台将“三者关系”拆分成了“四者关系”

曾经的软件系统，只分为硬件、操作系统和软件，其中操作系统在这里也可以理解为是一个“中台”。硬件提供原料，操作系统负责统一调度硬件资源，软件决定具体用来做什么。

但是如今这个简单的三者关系之间插入了一个“第四者”——中台。

本质上，中台就是多做了一层抽象，将那些软件中有共性的、可复用的部分提炼出来，作为一个独立的、中心化的个体。它的作用和先前的操作系统类似，作为相对更高级的原料，对上层软件应用提供支持。

Docker，Kubernetes这些技术，甚至包括DevOps，IaaS，FaaS、SOA、微服务这些思想概念，无不如此。

所以，原来的软件 -> 操作系统 -> 硬件的关系，就变成了。软件前台 -> 软件中台 -> 操作系统 -> 硬件。

那么这也就是意味着，你原来做的工作，现在被分为了两个部分，分别由两个人去做，你原来的一部分工作“被抽象没了”。从某种意义上说，你的能力覆盖范围更小了。

 

02  中台在大公司才能发挥作用

残酷的现实是，中台对规模越大的系统越有价值，反之则相反。所以，对初创的小企业、包括一些中型企业来说，做中台的必要性没有这么高。 

你想，一个企业里就一两个系统，而且一天就发生几十几百人次的交易、操作，此时中台有什么意义？还不如一个单体应用跑的顺溜。

可能你会说，这样的话最多就是没有变化啊，在这种企业里，还是原来软件 -> 操作系统 -> 硬件的关系，相当于还是一个人同时负责前端+后端，能力覆盖范围没有缩小。

其实你错了，如今大企业自己内部的「中台」正在不断地对外输出。你去看看阿里云、腾讯云这些云商上面的产品，你会发现它们会让很多原本你认为后端要做的事情变得都不需要做了。

而且这些高复用度的中台产品作为产品来售卖，自然很容易形成规模效应。所以，从经济效益上肯定比一个企业自己找几个程序员开发要强。你想想，前者是批发价，后者是零售价，而且还是“私人订制”的零售价，性价比的高低不言而喻。

 

03  年轻的初中级程序员还在不断涌入

从我与身边的人交流之后得到的主观感受来看，新的初中级程序员数量还在不断增加。

这就相当于原来的那锅粥不但锅子正在越来越小，僧反而越来越多。

可能你会说，不是有新的领域吗？像人工智能这些。

但是你仔细在身边观察一下看看，任何一个行业的发展总是往着越来越纵深方向去的，进入的难度会不断提高。这些新拓展的领域的门槛已经天然拦掉了一部分人。

所以从这个角度来看，整个市场当中庞大的初中级程序员的处境就非常尴尬，因为相对偏“劳动密集型”的工作岗位会变得越来越少（中台趋势将平均开发效率高了）。

而且以后的“劳动密集型”的开发工作中，越来越只剩下两件事，把业务翻译成代码（其实很多saas软件把这部分“粥”都吃掉了），以及CRUD（包括调用高度封装好的api）。所以，很多人在抱怨CRUD太多的问题不但不会减少，还会越来越严重。

是不是很绝望？感觉自己以后要么想办法挤进巨头公司、要么不断冒着成为“绝顶高手”的风险跟着行业往纵深去走，否则就只能沦落到真正的“码农”工作。

  

我们来一起想想怎么破局？

最近两年我时不时会想到这个问题，但是我想来想去，发现只有一条路是相对平滑，适合大多数人的。

就是，「主动拥抱业务」，做「跨界」人才。我这个号的名字里的跨界也是由此而来。

  

人类文明的发展，可以想象成一个接“龙”的过程。这个“龙”可以想象成“管道”。每一个管道就是对一件事物的标准化，为的是让后来者可以更快的经过这个管道到达“当下的最新世界”，而不用再去反复地重新走一遍前人走过的老路。 

举个例子。比如汇编语言只是为了操控计算机，而后的C语言基于它提供了更好的可移植性，再往后的C++基于C语言提供了更好的面向对象（OOP）的能力，进一步提高了代码的编写效率，到如今的Java、C#之类通过语法糖，让编码效率再提升了一个档次。

很多事物都是这样慢慢演化而来的。

这些“新管道”其实就来源于我们的现实世界。现实世界中的任何一个问题被解决和提炼之后就是一节管道，拼接在所依赖的前一个问题（管道）后面，不断累加。

中台就是其中正在提炼和拼接的一节“管道”。 

所以，面对这个趋势，我们与其回头看，纠结要不要去追逐中台，做一个完成最后的管道拼接的人。不如向前看，去探寻新的问题，那里的机会其实更多。

因此我觉得，拥抱业务，去接触和解决现实问题反而是康庄大道；相比之下，追逐中台，更像是去挤独木桥。

 

利用前人打造的管道，去解决更难、更有挑战的业务问题，帮助拓展业务的增量，才是我们大部分程序员应该去抓住的机会。如果你过去有排斥业务、不屑业务的心态我认为得转变一下，因为这才是你最好的机会。

程序员这个职业已经过了野蛮生长期，未来只有那些愿意去精耕细作、去披荆斩棘开路的人，才会被留下。

那么我们可以怎么做呢？我再分享三个小建议给你。

 

01  用产品思维看系统

 

产品思维的本质是什么。我的理解就是：带着怀疑精神，不断地寻求更优解，不断地让用户更爽。

这和程序员思维中的「确定性」，要么0要么1，非黑即白是背道而驰的。产品思维没有对与错、好与坏，只有更好、更好、更好。 

只有用产品思维来看待一个事物，你才能更深入业务，而不是停留在表面。永远做一个“代码翻译者”。 

你可以试试定期做下面四件事：

1. 梳理你当前工作所涉及的业务范围。可以用思维导图来做，便于更好的发散你的思维。

2. 通过分析系统中的数据，得到对这些业务模块的当前情况的主观判断，标出高于预期、还是低于预期。

3. 以你对这个业务模块的理解，找到你认为其中最应该关注和提升的环节。再想想从技术角度能够提供怎么样的支持和帮助。

4. 找产品经理聊聊自己看法，碰撞一下自己的思考中有哪些能够得到认同。对产品经理来说，你的一些想法也会对他产生启发，甚至被直接采纳。 

长期以往，你就不知不觉地深入到业务里去了。

 

02  在上级的视角看系统

 

为什么要从上级的视角来看？

因为他的信息源比较广，接收到的信息量比你大，对事物洞察更接近本质、对重要程度的判断比你更准确。 

但真要做到换位思考其实很难，因为我们大多数人来说，见识、阅历还不够丰富。举个极端的例子，假设见识、阅历、经验等方面与你的上级完全没有重合的地方，那么无论你怎么想换位，都换位不到对方的视角上去，因为那个视角对你来说是“不可见的”。 

所以，对于做换位思考我的一个思路是：以人性为主、见识、阅历、经验为辅。

不管是谁，归根到底都是人，自然就逃不开内存深处的人性，贪婪、嫉妒、傲慢、自私、冲动、懒惰等等。只是不同的人对其的克制能力不同罢了。

所以当你站在人性的角度去考虑你上级利益关系，他的重视点自然就出来了。见识、阅历、经验这些只是为了更精准的把握这个颗粒度而已。

因此，在你基于你的本能反应做出判断和理解之前，先缓一缓，多问自己几个“为什么”。

• 他为什么这么说？

• 他当前所重视的是什么？ 

• 这件事做好了或者做砸了，对他的影响是什么？

 

03  拥抱新技术，但要止于细节

 

前两点都是为了深入业务，但是想要更好的降本提效，甚至是创造增量的话，必然离不开新技术。 

新技术自然有其价值，否则也不会有人愿意去将它开发出来。但是是否最终得到市场的认可，需要时间来验证。

所以我的建议是，如果你现在还不打算用它，那么你不用去了解它的细节。你只要知道，它有什么作用？长处和短处分别是什么？这就够了。因为如果你后续没有机会用到它，所有对它的了解都浪费了。

比如，你可以先不用去了解某个机器学习算法是怎么推导实现的，但是你可以先记下它的优势在哪里？缺点是什么？大家有提到过的使用场景有哪些？这就够了。

我自己的习惯是，订阅一些相关的公众号（手机端）、加入一些圈子（手机端）、收藏一些相关的网站（电脑端），以保持新技术相关信息的持续摄入。这里主要要做好两件事， 

1. 为了保证信息接收的效率，内容高度重合的多个号只要保留一个即可。

2. 对它能用来干什么以及缺点做好及时的整理和归类，便于后续用到的时候快速做出决策判断。（我自己用思维导图做，你可以用任何自己喜欢的方式）

关于新技术选型可以参考我之前的文章：程序员与新技术之间的「爱」与「恨」。

我们的社会发展是建立在分工协作的基础上的，分工协作的演变趋势其实就不断地做两件事，「分离」和「生长」。 

长到一定程度，显得臃肿的时候就分离，各自专注一部分发展。各自继续变得臃肿之后再次分离，不断地的循环。

有点像数据结构中的“树”的样子。

所以，眼前的“中台”也只是一个过渡期，不需要纠结于此，往前看才是更重要的。

 

好了，我们总结一下。

这篇呢，Z哥先和你聊了一下中台本质其实就是「整合」，这个理念在日常生活中也到处可见。

其次和你聊了一下中台得以被大肆宣扬的宏观因素。

然后，提醒你要注意中台发展的背后对我们程序员的发展会产生的影响，并建议你要重视业务，成为为业务披荆斩棘的开路人。

最后分享了三个建议，「产品思维看系统」、「在上级视角看系统」、「拥抱新技术，但要止于细节」帮助你做好这点。

希望对你有所启发。

愿大家都能踩对节奏，顺利进入互联网行业的下一个阶段。

 

推荐阅读：

• Github带来的不止是开源，还有折叠的认知

• 如何摆脱「技术思维」的惯性？

 

作者：Zachary

出处：https://zacharyfan.com/archives/985.html

 

---

 

如果你喜欢这篇文章，可以点一下左下角的「推荐」。

这样可以给我一点反馈。: )

谢谢你的举手之劳。

 

▶关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描下方的二维码~。

如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。

 

​