确定性核心，非确定性外壳

2026 年 8 月 3 日 十四年前，Gary Bernhardt 创造了“功能核心、命令外壳”这一术语。与计算领域的大多数好想法一样，它并不是全新的，但他的概念非常清晰，并且为讨论现有系统中的测试和确定性奠定了良好的基础。简而言之，功能核心/命令式外壳架构将代码分为两部分。功能核心是纯粹的功能 - 即没有 IO，也没有破坏性的状态更新。它与应用程序的业务逻辑有关。 Imperative Shell 的路径相对较少，但可以维护状态、协调外部依赖关系并与外界打交道 - 即 IO。它的工作是用值查询核心，接收作为某些黑盒决策结果返回的值，并使用它与外部世界交互；无论是写入数据库、发送请求还是更新 GUI。该模型中的 Shell 和 Core 具有不同的特征： Core Shell 做出决策 协调依赖关系 许多分支执行路径 更多线性执行 与世界隔离 与世界集成 这使得核心非常适合测试。由于它是纯函数式的，因此相同的输入总是会得到相同的结果。由于它是孤立的，因此没有什么可以模拟或存根的。由于它处理复杂的业务逻辑，测试可以告诉我们很多有关系统行为的信息。函数的纯粹性和确定性 描述使纯函数易于测试的属性的一种更简短的方式是它们是确定性的。也就是说，给定一个输入流，纯函数总是返回相同的输出流；他们的行为是可重复的。但纯函数式编程并不是实现这一目标的唯一方法。如果我们稍稍倾斜一下头，我们就会发现，值流和赋值序列是表达同一事物的不同方式，而状态机可以给我们带来同样的好处。考虑以下代码： function add ( ns ) { return ns . reduce ( ( a , b ) => a + b , 0 ) } class AddMachine { # state = 0transition ( input ) { this .# state += input } get state ( ) { return this .# state } } 函数 add 很容易推理；它是纯粹的，因此是确定性的。但 AddMachine 也是确定性的 - 给定对转换函数的相同调用序列，AddMachine 将返回相同的状态。势在必行并不会改变这一点。 const 输出 = add([1,2,3]) const a = new AddMachine() a 。过渡 (1) a.过渡 (2) a．转换 (3) const 输出 = a 。 state 纯函数式编程是一个很好的范例，但由于语言或性能方面的考虑，它并不总是实用的 - 我不想在 C 中尝试它！但是，将需求从纯粹的功能性弱化为纯粹的确定性，我们保留了“功能性核心，命令性外壳”的可测试性优势，同时拓宽了其适用性。所以这篇文章的标题是：确定性核心，非确定性外壳。决定论感觉像是一个比功能纯粹性更抽象的概念。当你看到它时你怎么知道它？我发现从不确定性开始并逆向工作更容易。以下是不可重复行为的一些常见示例： 调用未播种的 RNG 异步和多线程操作 通过网络通信 与其他进程通信 读/写本地存储 数据库交互 向操作系统询问日期或时间 所有这些都属于非确定性 shell。每当您在业务逻辑中找到它们时，您就有了一个自然的碎片整理目标 - 要么将它们的函数分成两部分，要么将它们提升一层并将它们的结果作为参数注入。从字面上理解“壳”这个比喻是很说明问题的。它应该围绕逻辑，查询应用程序的核心以获得它所需要的内容。使用你所拥有的东西“这一切都很好”，你可能会想，“但是它对我来说有什么用处，在工业的遗留和氛围代码矿井中辛苦劳作呢？”。一个公正的指控，一个想象中的读者；并不是每个人都可以成为 Foundation DB，并从第一天起就做出区分（他们实际上更进一步，但这是另一篇文章的主题）。决定论和非决定论在我见过的几乎所有现实生活代码库中都高度交织在一起，而且我也看到了我的公平份额。但不要让完美成为优秀的敌人！考虑平均（即糟糕）代码库的一种方法是它有许多确定性核心。有成千上万的星星散布在斜坡上，就像天空中的星星一样。半空的玻璃杯认为这些代码库是一个不可挽回的遗留混乱。但玻璃半满的是，内部某处隐藏着许多确定性核心，而且可能只有少数。旧版 Windows 系统的用户可能还记得“磁盘碎片整理程序”；它获取内容物理上分散在旋转硬盘上的文件并使它们变得连续。在一个 e