软件中的一切都是金字塔（不管你喜欢与否）

Source: Dev.to

引言

一段时间后，软件不再像工具。
它开始像重力。
无论你构建什么，复杂度总会向下沉。
我并没有刻意设计这个模型；我只是不断在各处看到相同的形状，于是我不再给模式命名，而是开始画金字塔。

框架

框架看起来很强大，直到你看到它们所处的位置：

• 框架
• 运行时环境
• 编程语言
• 编译器或解释器
• 机器码

框架并没有赋予计算机新的能力。它们的存在是为了提升开发者体验，就像 UI 为用户体验服务一样。当一切运行顺利时，你就在顶层。你永远不会通过添加另一层抽象来调试。

架构

人们认为架构在团队规模扩大时才开始。其实并不是。
一个单独的 MVC 应用已经形成了金字塔：

• 易变性位于顶部。
• 控制器翻译意图。

如果业务逻辑向上泄漏，系统会迅速腐烂。这并不是过度工程。

横向扩展

随着系统的增长，常见的错误是横向扩展。人们过早地把复杂度横向扩散。

每个模块：

• 拥有自己的规则
• 暴露接口
• 隐藏内部实现

部署仍然是单调的。当需要扩展时，抽取工作是机械化的。如果抽取过程很痛苦，那说明边界本来就是虚构的。

微服务

微服务并不会消除复杂度；它们把复杂度搬到网络上。每一次网络跳转都是一种故障模式。

• 微服务解决的是组织层面的规模，而不是早期的不确定性。
• 它们是通过压力而非野心获得的。
• 过早使用会让问题的增长速度超过解决速度。

金字塔规则

在所有四个金字塔中，规则从未改变：

将经常变化的东西放在顶部。

框架变化迅速。违背这一顺序并不会让你变得“现代”。这不是哲学，而是可逆性。

• 层级越高：错误成本越低，重写越容易。
• 层级越低：成本越高，恢复时间越长。

强大的系统顺应重力。薄弱的系统则用抽象去对抗它。

结论

一旦你看到了金字塔，问题就会改变：

• 我正在触及哪一层？
• 这个决定的可逆性如何？
• 我是否在不该放重物的地方增加了重量？