程序员究竟要具备什么底层思维？（免费送书）

朋友张建飞出了一本《程序员的底层思维》，免费送一些，帮他宣传下。

画外音：无任何套路，就是直接送。

截取一段，看老张是怎么批判中台的。

前些年，阿里巴巴提出了“大中台、小前台”战略，在业界掀起了不小的波澜，一时间，各种中台建设的方法论和最佳实践满天飞。

中台的底层逻辑是什么？中台能带来的价值到底是什么？

中台的底层逻辑，用一句话解释就是通过复用提升研发效率。

如图1所示，基于这样的演进路径，有没有可能做一个Business-PaaS（业务中台），提炼业务中具有共性的内容，减轻前台业务，提升研发效率呢？

图1  业务中台的位置

单看图1，这个逻辑似乎是通的。于是，在“大中台、小前台”的旗帜下，业务中台诞生了。可是不管是一线研发人员的反馈，还是高层人员的质疑声，都表明了业务中台似乎并没有解决问题，反而制造了更多的阻碍和困难，这是为什么呢？

业务中台为何低效？

业务中台它解决的是复杂、多变的业务问题。如果你把镜头拉近一点看，会发现业务和业务中台的关系并不是像我们理想的一样在中间有一道清晰的边界线，而是像图2一样，犬牙交错地耦合在一起。

图2  业务和业务中台的关系

前台业务要借助业务中台一起去完成业务逻辑，所以有一部分埋在了业务中台里，至于埋得多深，则取决于使用中台能力的多少，用得多就埋得深，用得少就埋得浅。

因此，用一句话来说，业务中台低效的根本原因在于，前台业务和业务中台的“深度单体耦合”。这种耦合性至少在以下3个方面严重影响了整体的研发效率。

1. 协作成本

研发≠写代码，实际上我们大部分时间不是在写代码，而是在沟通协调，况且与人打交道要比与机器打交道麻烦得多。

2. 认知成本

就阿里巴巴的业务中台体系来说，不可谓不复杂，其中有大量的业务概念，这会显著增加了开发者的认知负荷，让系统变得异常复杂。

3. 稳定性成本

理想的情况是我们能预见所有的业务变化，提前做抽象，预留所有的业务扩展点，这样针对不同的业务只需要在扩展点中定制就好了。但没人能预见未来，这样就难免要改动平台代码，比如加一个扩展点。由于平台代码是被所有业务共享的，这就给稳定性带来了极大的隐患。比如，A业务改动了平台代码，然而B业务什么也没做就出了故障。

如何解决中台的困境？

为了解决上述业务中台碰到的问题，至少可以做这么几件事：

（1）把业务能力做薄。做薄是为了解耦，业务最懂自己，因此不要尝试去“control”它们。中台可以更多地关注与“业务无关”的能力建设，比如稳定性、性能、监控、运维工具等非功能属性；

（2）把中台能力做强。除了非功能属性，中台还可以通过建设丰富的业务解决方案库、业务组件库等工具，赋能业务快速发展，用enable代替control；

（3）把系统结构做简单，复杂是万恶之源；

1. 解耦

协作成本和稳定性问题都是由前台业务和业务中台的深度耦合造成的，因此，中台这种集中式的代码管控和部署的“大单体”模式亟需改变。解决方案显而易见，解决“大”的问题的方法就是分而治之，解决“单体”的问题的方法就是服务化。

如图3所示。就像BPaas这个名字所隐喻的一样，让业务中台真正变成服务（Business Platform as a Service）。

图3  业务和中台解耦

解耦不难，关键是这一刀要从哪里切？

所谓“业务无关”，就是想办法在业务中台中找到和具体业务无关的内核（kernel）。这样既可以最大程度上复用中台能力，又可以保持业务的灵活性。比如，所有的业务都需要对数据进行增删改查（CRUD）操作，这就是业务无关的，而业务的各种校验逻辑是业务相关的。

2. Platform as Code

简单不等于简陋，帮助业务快速发展的主要职责不能丢。

假如需要启动一个全新的业务，因为中台做薄了，之前在业务中台沉淀的业务能力很多都释放给业务自己了，中台要怎么帮助快速搭建新业务呢？

这时可以考虑借鉴DevOps中的概念——IaC（Infrastructure as Code），这里暂时将它命名为PaC（Platform as Code）。

图4  PaC中台解决方案

当一个架构师设计一个系统的时候，他如果选择重用，那么同时也选择了耦合。因为重用不管是通过组合（Composition）还是继承（Inheritance）实现，都会引入耦合。然而，如果你不想耦合，可以采用重复代替重用。

3. Platform as Code + 组件化

在PaC的基础上，可以进一步考虑组件化，即把一些共用的逻辑封装成组件，打造一个“中台组件库”，如图5所示。业务可以按需组合这些组件去实现业务，同时，业务也可以把自己沉淀的组件“反哺”给组件库，形成一个良性循环的“大集市”——好的组件会被大量使用、迭代和演化，不好的组件会被逐渐淘汰。

图5  PaC+组件化的中台解决方案

然而，业务具有易变、不确定、复杂和模糊性（Volatility Uncertainty Complexity Ambiguity，VUCA），很难标准化，如何设计组件并让组件和业务之间松耦合——即不要让组件绑架业务，困住业务的手脚，将是一个极大的挑战。

上面的文字节选自《程序员的底层思维》，如果喜欢，欢迎阅读原文入手。

▊ 《程序员的底层思维》

张建飞 著

• 本书带你学会用底层思维解决复杂技术问题

• 这也是一本培养思维能力的通用技能书

本书涵盖程序员应知应会的16种思维能力：抽象思维、逻辑思维、结构化思维、批判性思维、维度思维、分类思维、分治思维、简单思维，以及成长型思维等解决日常问题的基础思维能力，除此之外，还有解耦思维、契约思维、模型思维、工具化思维、量化思维、数据思维，以及产品思维等专业思维能力。

免费抽奖送出5本，如何抽奖？

留言评论想看此书的原因。
一人一楼，5, 10, 15, 20...楼依次中奖。
中奖者我会回复你的评论与你联系。
抽奖截止时间：4.24 12:00
如果等不及了，欢迎阅读原文入手。