迪杰斯特拉与结构化编程：可扩展的纪律

为什么在软件增长时迪杰斯特拉仍然重要

软件很少因为“无法写出来”而失败。它失败是因为一年后，没有人能安全地改动它。

随着代码库变大，每个“微小”的改动都会开始产生涟漪：一个 bug 修复破坏了遥远的功能，一个新需求迫使重写，简单的重构变成一周的协调工作。难点不在于添加代码——而在于在周围一切都变化时保持行为可预测。

承诺：正确性与简洁性降低长期成本

埃兹格·迪杰斯特拉认为正确性和简洁性应该是第一等目标，而不是附加项。回报不是空洞的学术论断。当系统更容易被推理时，团队就会减少救火时间，更多精力用于建设。

• 正确性 降低错误成本：更少事故、更少回归、更少那种“不要碰它”的代码。
• 简洁性 降低变更成本：更少隐含假设、更少特殊情况、代码评审时更少惊讶。

“规模”实际上是什么意思

当人们说软件需要“扩展”时，他们通常指性能。迪杰斯特拉的观点不同：复杂性也会随之扩展。

规模表现为：

• 更多特性： 新的流程、边界情况和用户期望。
• 更多人手： 交接、不同风格和不同上下文。
• 更多集成： 外部 API、数据源和失败模式。
• 更多时间： 历史决策、变化的需求和部分重写。

核心思想：结构让行为更可预测

结构化编程不是为了刻板而刻板。它是选择使人容易回答两个问题的控制流与分解方式：

• “下一步会发生什么？”
• “在什么条件下会这样？”

当行为可预测时，变更变成了例行而非冒险。这就是迪杰斯特拉仍然重要的原因：他的纪律针对的是增长中软件的真实瓶颈——能否足够理解它以便改进它。

简要介绍埃兹格·迪杰斯特拉及其目标

Edsger W. Dijkstra (1930–2002) 是荷兰计算机科学家，影响了程序员构建可靠软件的思维方式。他参与早期操作系统工作、为算法做出贡献（包括以他命名的最短路径算法），更重要的是，他推动了一个观点：编程应该是我们可以推理的事情，而不是反复尝试直到看起来可行。

他的核心关注：推理胜过“在我机器上能跑”

迪杰斯特拉更关心的是我们是否能解释为什么程序在重要情况下是正确的，而不是仅仅让程序在几个例子上输出正确结果。

如果你能陈述一段代码应该做什么，你就该能逐步论证它确实如此。这个心态自然而然地导向更容易阅读、更容易审查、而不太依赖英雄式调试的代码。

为什么他的话听起来严苛——以及这为何有用

迪杰斯特拉的文字有时显得不妥协。他批评“聪明”的技巧、混乱的控制流和使推理困难的编码习惯。严格并非为了样式警察，而是为了减少歧义。当代码的含义清晰时，你花在意图争论上的时间更少，把时间用在验证行为上。

什么是“结构化编程”（高层次）

结构化编程是用一小组明确的控制结构——顺序、选择（if/else）和迭代（循环）来构建程序，而不是纠缠的跳转流。目标很简单：让程序路径可理解，从而能自信地解释、维护和改变它。

正确性：用户依赖的隐性特性

人们常把软件质量描述为“快”、“漂亮”或“功能丰富”。用户体验正确性的方式不同：那是一种安静的信心，认为应用不会给他们带来惊讶。当正确性存在时，没有人会注意到它；当它缺失时，其他一切都不再重要。

“现在能用”与“能一直用”

“现在能用”通常意味着你尝试了几个路径并得到期望结果。“能一直用”意味着在时间、边界情况和变更后仍按意图表现——重构后、整合后、更高流量和新团队成员改动后仍如此。

一个功能可以“现在能用”但仍然脆弱：

• 它依赖输入总是干净。
• 它假设网络调用总是快速返回。
• 它通过的测试只覆盖了顺利路径。

正确性是关于消除这些隐含假设——或把它们明确化。

小错误在大系统中如何乘数增长

一个小 bug 很少会一直只是小范围的。一个不正确的状态、一个越界的 off-by-one 或一条不明确的错误处理规则会被复制到新模块，被其他服务包裹，被缓存、被重试或被“绕开”。随着时间推移，团队不再问“什么是真的？”，而开始问“通常发生什么？”这时事故响应变成了考古学。

乘数效应来自依赖：一个小的异常行为变成许多下游异常行为，每个都有自己的部分修复。

清晰性是正确性的工具（而不仅仅是风格选择）

清晰的代码通过改善沟通来提升正确性：

• 代码评审 在意图明显时能抓住真正的问题。
• 入职 当规则可读而不是部落知识时更快。
• 事故 当控制流与失败模式容易追踪时能更快解决。

对产品团队的实用正确性定义

正确性意味着：对于我们声称支持的输入与情况，系统稳定地产生我们承诺的结果——在无法满足时以可预测、可解释的方式失败。

将简洁视为策略，而非风格偏好

简洁不是让代码“可爱”、极简或聪明。它是让行为易于预测、解释和在不惧怕的情况下修改。迪杰斯特拉重视简洁，因为它增强了我们推理程序的能力——尤其是在代码库和团队增长时。

简洁是什么（以及不是）

简洁的代码同时维持少量想法：清晰的数据流、清晰的控制流和明确的职责。它不会迫使读者在脑中模拟许多替代路径。

简洁不是：

• 不惜一切代价减少行数
• “聪明”技巧、密集的一行写法或过度抽象
• 为了看起来灵活而避免结构

偶然复杂度：你无意中加入的东西

许多系统之所以难以改变，并非因为领域本身固有复杂，而是因为我们引入了偶然复杂度：交互的旗标、从未移除的特殊补丁和主要为绕过早期决策而存在的层。

每一个额外的例外都是理解的税负。成本会在后来显现：当某人尝试修复 bug 时，发现一个区域的改动会微妙地破坏几个其他区域。

简单设计减少英雄式救火的必要

当设计简单时，进展来自稳定工作：可审阅的改动、更小的 diff、更少的紧急修复。团队不再需要记住每个历史边界情况的“英雄”开发者，或在凌晨两点能在压力下调试的人。系统支持正常的人类注意力跨度。

经验法则：更少特殊情况，更少惊讶

实用测试：如果你不断添加例外（“除非……”、“只有为这个客户……”），你很可能在累积偶然复杂度。优先选择减少行为分支的解决方案——一条一致规则胜过五个特殊情况，即便这条一致规则稍微比最初想象的更泛化。

结构化编程：值得信赖的清晰控制流

结构化编程是一个简单但后果重大的思想：写代码使其执行路径容易跟随。通俗来说，大多数程序可以由三种构建块构成——顺序、选择 和 重复——而无需依赖纠结的跳转。

三个构建块（用人话说）

• 顺序： 做步骤 A，然后 B，然后 C。
• 选择： 根据条件选择路径（例如 if/else、switch）。
• 重复： 在条件成立时重复一组步骤（例如 for、while）。

当控制流由这些结构组装时，通常可以自上而下解释程序做什么，而无需在文件间“瞬移”。

它替代了什么：意式的执行路径

在结构化编程成为常态之前，很多代码库大量依赖任意跳转（经典的 goto 风格）。问题不是跳转总是邪恶，而是不受限制的跳转制造了难以预测的执行路径。你会不断问“我们怎么到这里？”和“这个变量是什么状态？”，而代码不会清楚地回答。

为什么清晰对实际团队重要

清晰的控制流帮助人类构建正确的心理模型。调试、审查 PR 或在时间压力下改变行为时，大家依赖的就是这个模型。

当结构一致时，修改更安全：你可以改动一个分支而不会无意影响另一个，或重构循环而不会错过隐藏的退出路径。可读性不仅仅是审美——它是自信变更行为而不破坏已有功能的基础。

推理工具：不变式、前置条件与后置条件

迪杰斯特拉推动了一个简单思想：如果你能解释为什么代码是正确的，你就能更少恐惧地改变它。三个小的推理工具让这变得可行——无需把团队变成数学家。

不变式：“始终为真的事实”

不变式 是在代码运行期间（尤其在循环内）始终为真的事实。

示例：你在汇总购物车里价格。一个有用的不变式是：“total 等于到目前为止已处理商品的和。” 如果在每一步都保持这一点，那么当循环结束时，结果是可信的。

不变式很强大，因为它把注意力放在永远不能被破坏的东西，而不是仅仅下一步应该发生什么。

前置条件与后置条件：日常契约

前置条件 是函数运行前必须为真的条件。后置条件 是函数结束后保证的事项。

日常例子：

• 前置条件：“只有当账户有足够余额时才能取款。”
• 后置条件：“取款后，余额减少了确切的金额，且不会变为负数。”

在代码中，前置条件可能是“输入列表已排序”，后置条件可能是“输出列表已排序，并包含相同元素外加插入项”。

把它们写下来如何改变编码和审查

即便是非正式地写下这些，设计也会更清晰：你决定函数期望什么和承诺什么，自然会把它写得更小、更专注。

在审查中，讨论会从样式上的“我会这样写”转向正确性的辩论：“这段代码保持了不变式吗？”“我们是要强制前置条件还是把它记录下来？”

轻量实践：在容易出错处注释

你不需要形式证明就能受益。挑出最常出 bug 的循环或最棘手的状态更新，在上面加一句不变式注释。后来有人修改代码时，那条注释像护栏一样：若改动破坏了这一事实，代码就不再安全。

测试 vs 推理：各自能保证什么、不能保证什么

测试与推理追求相同的目标——软件按意图工作——但方式不同。测试通过示例发现问题。推理通过使逻辑明确来防止某些类别的问题。

测试擅长什么

测试是实际的安全网。它们抓住回归、验证真实场景，并以团队可运行的方式记录期望行为。

但测试只能显示 bug 的存在，而不能表明其不存在。没有测试集能覆盖所有输入、所有时序变化或所有特性间的交互。许多“在我机器上能跑”的失败来自未测试的组合：罕见输入、特定的操作顺序或只有在若干步骤后才出现的微妙状态。

推理能保证什么（以及不能）

推理是证明代码属性：“这个循环总会终止”、“这个变量从不为负”、“这个函数不会返回无效对象”。做好了，它能排除整类缺陷——尤其是边界和极端情况相关的缺陷。

限制在于成本和范围。对整个产品做完全形式化证明通常不经济。推理在有选择地应用时效果最好：核心算法、对安全敏感的流程、金钱/计费逻辑和并发部分。

一个可扩展的平衡方法

广泛使用测试，并在失效代价高的地方应用更深的推理。

一个介于两者之间的实用桥梁是把意图可执行化：

• 断言 用于内部假设（例如“索引在范围内”）。
• 前置/后置条件（契约）用于函数输入/输出。
• 不变式 用于持久的真理（例如“购物车总额等于商品之和”）。

这些技术不会取代测试——但会收紧安全网，把模糊的期望变成可检查的规则，使得编写错误更难、诊断更容易。

纪律：团队如何避免“聪明债”

“聪明”的代码在当下常常感觉是一种胜利：更少行、巧妙技巧、一行把事情做完让你感觉很聪明。问题是聪明不会随着时间或人员扩展。六个月后，作者忘记了技巧。新队员按字面读懂，却错过了隐含假设，从而以破坏行为的方式改动它。这就是“聪明债”：短期的速度换来长期的混乱。

纪律是团队的加速器

迪杰斯特拉的观点不是“写无聊代码”作为风格偏好——而是有纪律的约束使程序更容易被推理。在团队里，约束还减少决策疲劳。如果每个人都知道默认做法（命名、函数结构、什么算“完成”），你就不用在每个 PR 里重复讨论基础问题。那时间可以回到产品工作上。

纪律体现在常规实践中：

• 代码评审 奖励清晰胜过新奇（“别人能安全改动吗？”）。
• 共享规范（格式、命名、错误处理）让代码库读起来像一个声音。
• 重构作为维护，而不是救火行动——持续的小清理。

代码中“有纪律”的样子

一些具体习惯可防止聪明债积累：

• 小函数 做一件事，输入输出明显。
• 清晰命名 解释意图（宁可用 calculate_total()，不要 do_it()）。
• 无隐式状态： 最小化全局变量和令人惊讶的副作用；显式传递依赖。
• 直线控制流： 避免依赖微妙顺序、魔法值或“知道诀窍才行”的逻辑。

纪律不是追求完美——而是让下一个改动可预测。

模块化与边界：把变更局部化

模块化不仅仅是“把代码拆成文件”。它是把决策隔离在清晰边界后面，使系统其余部分无需知道（或关心）内部细节。模块隐藏混乱部分——数据结构、边界情况、性能技巧——只暴露小而稳定的接口面。

模块如何缩小爆炸面

当变更请求到来时，理想结果是：改动只影响一个模块，其余保持不动。这就是“让变更局部化”的实际含义。边界防止意外耦合——更新一个特性却悄悄破坏三个其他特性的情况。

一个好的边界也让推理变容易。如果你能陈述模块保证什么，你就能在不重读其整个实现的情况下推理更大的程序行为。

接口是承诺（并如何支持并行工作）

接口就是承诺：“给定这些输入，我会产生这些输出并保持这些规则。”当承诺清晰时，团队就能并行工作：

• 一个人实现模块。
• 另一个人基于接口构建调用方。
• QA 针对承诺的行为设计测试。

这不是官僚主义——而是在不断增长的代码库里创建安全的协调点。

防止漂移的简单模块检查

你不需要宏大的架构审查来改进模块化。试这些轻量检查：

• 输入/输出： 能否在几行内列出模块的输入、输出和副作用？不能的话，很可能功能过多。
• 归属： 谁负责它的行为与改动？无人负责的模块会变成垃圾堆。
• 依赖： 它是否依赖“所有东西”，还是仅依赖真正需要的？更少依赖意味着更少意外破坏。

划定良好的边界会把“变更”从系统级事件变成局部编辑。

为什么这些思想在团队、代码库和时间上都能取胜

当软件小的时候，你可以“把一切记在脑中”。到了规模化，这种做法不再成立——失败模式也变得熟悉。

常见症状包括：

• 可追溯到一个意外角落的宕机
• 每次发布都变慢，因为每个改动看起来都很冒险
• 脆弱的集成：一个小更新破坏三个下游系统

结构降低认知负担

迪杰斯特拉的核心押注是：人是瓶颈。清晰的控制流、小而明确的单元以及你能推理的代码不是审美选择——它们是提升产能的手段。

在大型代码库中，结构相当于对理解的压缩。如果函数有明确的输入/输出，模块有可以命名的边界，“顺利路径”没有与每个边界情况纠缠在一起，开发者就会花更少时间重建意图，更多时间去做有意图的改动。

它随着团队而扩展，而不仅仅是代码

随着团队增长，沟通成本比代码行数增长得更快。有纪律、可读的代码减少了参与所需的部落知识。

这会立即体现在入职上：新工程师能遵循可预测模式，学会一小组约定，并在无需长时间了解“陷阱”的情况下做出改动。代码本身会教会系统。

事件更容易调试且撤回更安全

发生事件时，时间稀缺而信心脆弱。用明确假设（前置条件）、有意义检查和直线控制流写的代码在压力下更容易追踪。

同样重要的是，有纪律的改动更容易回滚。小而局部的编辑和清晰的边界减少了回滚触发新故障的概率。结果不是完美——而是更少惊讶、更快恢复，以及系统在若干年和众多贡献者积累后仍可维护。

在不教条的前提下应用迪杰斯特拉

迪杰斯特拉的观点不是“用旧方法写代码”。而是“写你能解释的代码”。你可以在不把每个特性变成形式证明练习的情况下采纳这种心态。

把原则变成日常习惯

先从使推理便宜的选择开始：

• 偏好简单控制流：几个小函数胜过一个多分支的“包办一切”例程。
• 减少副作用：把变更局限在需要的地方，不让函数悄悄修改全局状态。
• 使用清晰契约：在类型、命名和注释中明确输入、输出和错误行为。

一个好启发式：如果你无法用一句话概括函数保证了什么，它很可能做得太多。

小的“结构升级”（不做重写）

你不需要一次大重构。沿着接口缝隙逐步增加结构：

• 把复杂循环抽成有名函数，并定义每次迭代保持的事实。
• 用语义化谓词替换“魔法”条件（例如 isEligibleForRefund）。
• 把棘手的状态转换封装在单一函数后面，以防止被滥用。

这些升级是增量的：它们为下一次改动降低认知负担。

使代码评审保持诚实的提示

在审查（或撰写）改动时，问自己：

• “这里必须为真的是哪些？”（不变式、假设、必需状态）
• “什么能安全改变？”（哪些部分允许变化而不破坏调用者）

如果审查者无法迅速回答，代码就在示意隐藏的依赖。

记录推理，而不仅仅是步骤

重复代码的注释会过时。相反，写明为什么代码是正确的：关键假设、你防护的边界情况以及如果假设改变会有什么被破坏。短短一句“不变式：total 始终等于已处理项之和”可能比一段解释性文字更有价值。

如果你想把这些习惯轻量化地收集起来，可以把它们做成一份共享清单（参见 /blog/practical-checklist-for-disciplined-code）。

AI 辅助构建在何处适配（同时不丢失纪律）

现代团队越来越多地使用 AI 加速交付。风险是熟悉的：今天的速度如果产生的代码难以解释，明天就会变成混乱。

一种符合迪杰斯特拉精神的使用 AI 的方式是把它视为促进结构化思考的加速器，而不是替代品。例如在 Koder.ai 中构建时——一个通过聊天创建 Web、后端与移动应用的 vibe-coding 平台——你可以通过明确提示与审查步骤来保持“先推理”的习惯：

• 要求清晰契约："为这个端点定义前置条件、后置条件与错误行为。"
• 要求在有状态流程中给出不变式："在这个结账状态机的每一步之后哪些事实必须保持为真？"
• 使用规划模式把实现细节生成之前强制分解为小且可审查的部分（模块、接口、职责）。
• 依靠快照与回滚使改动保持小且可撤销——这与局部编辑与安全撤回的纪律相呼应。

即便你最终把源代码导出并在别处运行，同样的原则适用：生成的代码应该是你能解释的代码。

适用于正确、简单、有纪律代码的实用清单

这是一个轻量的“迪杰斯特拉友好”清单，可在审查、重构或合并前使用。它不是让你整天写证明——而是把正确性与清晰设为默认值。

快速自检（新代码与重构）

• 我能在 60 秒内向队友解释这段代码吗？ 如果解释需要大量“相信我”的部分，就该简化。
• 控制流明显吗？ 偏好直线代码；保持循环与条件小；避免隐藏退出与深度嵌套分支。
• 前置条件与后置条件是什么？ 把它们写在注释、docstring 或函数名里。如果说不清，函数可能做得太多。
• 每个函数只做一件事并有清晰边界吗？ 输入进、输出出——尽量少依赖全局状态。
• 什么不变式让这个循环可信？ 即便是一行注释，例如“total 始终等于已处理项之和”也能防止微妙的 bug。
• 是否有过多“聪明”的技巧？ 如果代码需要导游，说明它在积累聪明债。

定性衡量的内容

• 解释容易度： 不熟悉该模块的人能否说出它做什么以及为什么正确？
• 测试容易度： 边界情况是否自然可测，还是需要复杂的设置和大量 mock？
• 变更风险： 当需求变动时，你能预测会破坏什么吗？如果每次改动都让人害怕，边界就在泄露。

实践的下一步

挑一个混乱的模块，先重构控制流：

1. 抽取小函数并以清晰名称命名。
2. 用更简单、显式的情况替换纠缠的分支。
3. 把特殊情况移到外围（输入校验、早期返回）。

然后在新边界周围添加一些针对性的测试。如果你想看更多类似模式的文章，请浏览 /blog。