业务与中台的爱恨纠缠

作为一位经历了业务开发->中台开发->业务开发的我，我觉得我还是有点资格来谈谈这个话题的，乐呵乐呵。

本该相爱

业务开发即直接面向具体业务、奋斗在用户一线的开发，主要开发功能特性。

中台则是站在后方提炼不同业务的共同需求，开发出通用的中台服务，一方面降低业务方重复开发的成本，一方面提高服务的质量。

听起来很美好、很互补对不对，按理说应该是一副非常和谐的画面，大家一起把事情做好。

奈何相恨

但是吧，人生不如意十之八九，没有那么多岁月静好。

做中台的看不起业务开发一天到晚crud,一点技术含量都没有

做业务开发的看不起做中台的一天到晚在那里大谈特谈通用、可拓展，在那里自我感动，却对真实的业务诉求视而不见

爱恨纠缠

我想谈谈我的经历。

业务开发阶段: 羡慕中台

在上一家公司我开始是做业务开发的，直接面对海量用户，版本需求非常多而且比较杂乱。

在开发过程中，大部分时间都是调各种其他服务的接口然后拼装数据展示给用户。

有人说用户量大，请求量肯定也非常大，应该很能锻炼高并发、高性能等等高大上的能力才对。这句话说对了一半，是这样没错，但基本上这种场景都已经有非常成熟、久经考验的方案了，很少需要你重新设计系统方案，只需要按照成熟方案的流程来就行了。

所以，那时候就非常羡慕做中台的，中台面对众多业务，用户量是我们的几倍之多，而且要设计成通用、可拓展的中台系统相当不容易，很能锻炼系统设计能力。

而且，还不用直接面对用户，不用时时刻刻处理用户反馈，相对比较轻松。一个小的需求点他都能排期一个月进行开发，十分滴轻松，十分滴惬意。
嗯，我当时就是这么想的，非常滴的天真。

中台开发阶段: 不是人干的事

后面经历了一轮组织的调整，团队需要拆分为app开发组和平台开发组，分别负责业务和中台服务。

千载难逢的机会啊，所以当leader问我想做哪部分时，我毫不犹豫说要做中台。

等做了中台发现，这tm简直不是人干的事。

1. 由于成本独立核算，你的中台功能需要有人用才能产生收入，所以你设计开发一款中台服务，还得有团队接入有团队用才行，也就是你还得去拉客，给各个业务方当孙子
2. 当了孙子，你发现同样的场景，有些业务方需要的能力是不一样的，甚至是冲突的，但是他们都要求你支持他们，要求升级中台能力，所以需要设计的即通用又特殊的系统，最后发展成一个一个业务方一套中台代码的怪物。
3. 排期上，当然要优先支持各位金主的需求啦，今天提的，明天就上线也不是没有过。
4. 提心吊胆，由于接入了多个业务方，用户量增多，其实是更容易出问题了，一些非常非常小概率的问题都会被海量用户放大，造成一批用户受到影响，什么底层磁盘故障啦，容器故障啦等等，真的半夜都会被告警电话叫起然后处理问题，一有故障，那背锅就是妥妥的，肯定都是中台的锅，想都不用想。什么，你说业务方为啥不做错误处理，不做缓存，他才不管你死活

再战业务开发

后面换了工作，又遇到上面的选择题，我想这次我可得聪明点，我要选业务开发。
结果吧，还以为能像上面狠狠压榨中台呢，结果人家中台吊得很。

你：这个功能场景其他项目都遇到了，都重复开发了一套，需要中台支持下，免得后面其他项目再重复开发。
中台：什么？巴拉巴拉，这个是特殊场景，不是通用的，中台不管，你们自己开发吧，你看别人都开发了，你可以参考下他们的代码
你：可是事实上之前好多项目都遇到了，都有这方面的需求，总不能后面项目遇到了再重复开发吧
中台：后面其他项目遇到了再说吧

其实吧，我觉得就是没经历过成本独立核算，要是来上这么一招，肯定就乖了，你觉得呢？

不同的破防理由

业务方

业务开发破防理解一般都很简单，无非就是:

• 你的代码就是坨屎
• 你怎么老是写bug
• 代码一点都不优雅，没眼看，改不动

上面任何一句话都听了让人上火，恨不得弄死他，没人喜欢别人说自己的代码很垃圾。

中台

但是中台就不一样了，你说他代码，他很有可能无动于衷，人家压根不care垃圾不垃圾的，反正你都要用。

那能让中台破防的话是啥，看好了，那就是：

你做的系统就是个玩具

完