第4章 务实的偏执

为什么这一单元不可压缩

本页依据 David Thomas、Andrew Hunt《程序员修炼之道：通向务实的最高境界（第2版）》，云风译，电子工业出版社，2020年4月，ISBN 9787121384356 的公开完整中文目录，独立重构 第4章 务实的偏执。本章不把“偏执”理解成恐惧，而是把软件必然存在的不确定性变成可检查的边界、可回退的动作和可重放的证据。

中文版目录逐项列出序、新版前言、第一版前言、9章、53个 Topic、99条提示、跋、参考文献、练习的参考答案和译者跋，共69个正式单元、168个目录节点。作者官方页面与英文原版目录交叉核对第4章及 Topic 23—27；英文版索引不计入中文目录分母。

豆瓣书目登记作者、译者、出版社、2020年4月1日、344页和 ISBN；出版社展示页登记2020年3月26日上市。日期口径不同不影响版本识别。书中的语言和工具例子有时代边界，本页只保留可迁移的责任划分、失败边界、资源平衡与反馈策略，并用当前代码样本重新验证。

本页对象、状态与验收合同

第4章的主张是“软件不完美，因此要让损害尽早、局部、可解释地停下”。本页把它展开为五个连续节点：契约 → 校验 → 失败隔离 → 资源平衡 → 反馈半径。每个节点都必须有输入、所有者、退出条件和下一位接收者；只画箭头而不说明状态变化，不能算作因果证据。

基线样本使用 invoice-42@commit-7c1，处理一笔金额为 128 的订单；唯一故障是移除内部状态断言。预期首差在“失败隔离”，而不是继续让订单进入结算。后文的图和实验台都围绕这个样本，避免用一个漂亮的总分掩盖真正的首个分叉。

本页最小可运行检查

unit: tpp20-chapter-04-pragmatic-paranoia
input: invoice-42@commit-7c1
baseline: contract-and-assertion-enabled
intervention: remove-one-assertion
expected_first_difference: failure-isolation
recovery: replay-same-input-and-restore-ownership

先写预期节点，再打开图示。观察“首差”是否与预测相同；如果下游仍显示成功，先怀疑合同或观测点，而不是手工修改最后一个结果。

官方目录逐项讲解

第4章 务实的偏执

本章级命题不是“永远怀疑一切”，而是承认不完美并提前安排失效路径。提示36“你无法写出完美的软件”因此应落在工程动作上：明确什么能被保证、什么只能被观测、什么失败后可以恢复，以及什么状态一旦不可信就必须停止传播。

提示36：你无法写出完美的软件

完美是无法验收的目标；可验收的是边界。对每个功能先写一条成功条件和一条拒绝条件，再问“如果依赖返回错误、输入恰好在阈值上，哪个节点会先拒绝？”这把乐观的口号改成可运行的测试预期，也让失败日志成为设计的一部分。

23 契约式设计

契约式设计 把责任分给调用者和实现者。调用者负责满足前置条件，实现者负责满足后置条件，双方共同守住不变量。契约应写出对象、单位、权限和拒绝方式，而不是只写“参数合法”。

例如，reserveSeat(count) 可以要求 count 是正整数且不超过剩余座位数，返回后座位数必须减少同样的数量，库存不能变成负数。边界样本 count 等于剩余数时应明确接受，超过剩余数则拒绝；若实现悄悄截断为可用数量，调用者就会收到与请求不一致的成功。

24 死掉的程序不会说谎

快速失败 不是让系统变得脆弱，而是缩短错误的传播距离。输入校验失败属于边界拒绝；内部状态违反不变量属于程序缺陷；可恢复的业务冲突则应返回明确结果。三者都不能用一个模糊的“继续试试”代替。

死掉的程序要说清楚对象、版本、状态和拒绝原因。一个只记录“结算失败”的异常不能帮助复核者判断是权限、库存还是金额不变量先坏了；一个带上下文的失败则能阻止脏状态继续进入下游，并把修复范围压缩到首个不可信节点。

25 断言式编程

断言 用来表达实现者认为“不可能发生”的状态，例如库存已经小于零、同一资源同时拥有两个释放者，或状态机跳过了必要阶段。断言不应替代用户输入校验，也不应包裹预期中的网络波动；它的价值在于让违反内部模型的瞬间可见。

function commitReservation(state: ReservationState) {
  if (state.pending < 0) {
    throw new Error("reservation invariant failed: pending < 0");
  }
  assert(state.phase === "validated", "commit requires validated input");
  return { ...state, phase: "committed" };
}

这里的断言保护的是实现内部的阶段不变量。真正来自用户的 count 仍应在入口校验；真正可恢复的“座位已经被别人占用”则应返回业务冲突。把三类信号混成一个异常，只会让调用者无法判断是修正输入、重试还是报警。

26 如何保持资源的平衡

资源所有权 要回答“谁取得、谁使用、谁释放”。文件句柄、锁、临时目录、数据库连接和外部租约都应有明确的拥有者；拥有者退出作用域时必须执行释放，即使中间抛出了错误。

作用域 把释放动作放在可见的边界内。伪代码如下：

const lease = await lock.acquire("invoice-42");
try {
  await updateInvoice(lease, input);
} finally {
  await lease.release();
}

finally 不是装饰；它证明异常路径也会走释放出口。若一个函数把锁交给多个调用者，却没有写清转移规则，代码看似局部，资源责任却已经泄漏到不可追踪的远处。

27 不要冲出前灯范围

前灯范围 是一种反馈纪律：先做能在几分钟或一个小测试内观察的变化，再根据结果决定下一步。它不否定远期设计，而是把远期假设标成未知，避免一次性承诺无法回退的架构和迁移。

小步反馈至少保存三件事：这一步只改变了什么、哪条信号支持或反驳假设、如果失败从哪里回退。把“今天先改接口、顺便迁数据库、再升级依赖”合并成一个动作，就离开了前灯范围，最终结果也无法归因。

专属图示：五个节点如何限制损害

下面的图把提示36的抽象前提落到一条可观察链：每个节点都有责任和拒绝出口。先预测移除断言后哪个节点会变红，再用单步观察核对；图示不是生产指标，而是帮助你定位第一处不可信状态。

三步观察：从契约走到反馈

每一步都使用同一笔 invoice-42 输入，只改变一个条件。动手前先预测首差；如果结果和预测不同，保留分叉，不要把图上的期望答案改成实际答案。

动手试：故障隔离实验台

猜一猜：在第3个节点移除断言，下一次推进时应在哪里停止？点击“注入单故障”，逐步前进，再点击“重置实验台”；复位后应恢复完整链条、第一步和未注入状态。

正常、边界与单故障矩阵

三种样本共享其余输入。若同时升级依赖、扩大样本并改变权限，就无法知道结果来自哪一个条件；应先回到正常样本，恢复基线，再做单变量实验。

常见误区与回退

证据账本：让偏执可以复核

反例不是“我不同意”。它必须在相同前提下产生相反结果，或指出前提在目标环境中不成立。发现反例后，缩小结论的适用范围，更新模型并重放旧样本；不能删除失败记录来保持提示看似永远正确。

本章回顾

• 软件不完美不是停止改进的理由，而是提前设计拒绝、隔离、释放和回退边界的理由。
• 契约明确双方责任，快速失败缩短错误传播，断言暴露内部不变量的破坏。
• 资源所有权必须覆盖异常路径；前灯范围要求每一步都能被及时观察和回退。
• 一次成功不能证明普遍成立；同一输入下的正常、边界、单故障与恢复证据才可迁移。

完成本章后，你应能为一个接口写出契约，制造一个只改变断言的故障，指出首个不可信节点，并从原始输入证明资源已经释放、下一小步仍在反馈范围内。

练习：把“更可靠”改成可验收行为

名词解释

来源与改写范围

• 作者与英文版页面：核对20周年版书名、版本与第4章的英文目录坐标。
• 中文公开目录：核对“第4章 务实的偏执”、提示36与 Topic 23—27 的中文目录位置。
• Git 文档：异常路径与历史记录：作为可重放、版本身份与证据留存边界的技术事实来源；本章模型、图示、代码和练习均为独立改写。

前后导航

• 上一页：22 工程日记
• 下一页：23 契约式设计