8 优秀设计的精髓
以更容易变更作为设计优劣的操作性标准，比较变化触达、反馈时间和恢复难度。
学习目标
- 能把“8 优秀设计的精髓”转成可比较的变更合同，记录变化触达范围、反馈延迟和恢复成本
- 能用“提示14：优秀的设计比糟糕的设计更容易变更”比较两个设计，并解释局部性、边界和替代路径的证据
- 能在真实项目中只改变一个设计条件，重放正常、边界和一次故障样本，让独立复核者定位首个偏离
为什么 8 优秀设计的精髓不是审美评分
本页依据 David Thomas、Andrew Hunt《程序员修炼之道：通向务实的最高境界（第2版）》，云风译，电子工业出版社，2020年4月，ISBN 9787121384356 的公开完整中文目录，独立重构 8 优秀设计的精髓。本页不复制原书正文、插图、练习答案或代码，而把目录命题转写成变更合同、设计对照、反例和复核证据。
设计的优劣要放进变化场景里判断。一个结构在稳定需求下看起来简洁，遇到第二种用户、替换供应商或修改数据规则时可能需要同时改动很多边界。相反，能够让变化停在局部、快速取得反馈、保留回退路径的设计，更能承受未知。
本单元只保留三个可观察问题：要改什么、影响谁、多久知道结果；若结果不对，怎样恢复。它不把触达范围压成一个漂亮总分，而是保存节点、负责人、输入、输出、拒绝条件和恢复动作。
8 优秀设计的精髓：变更合同
| 观察项 | 要问的问题 | 证据 | 失败动作 |
|---|---|---|---|
| 变化目标 | 哪个需求、约束或事实将要改变 | 变更命题与边界 | 重新确认目标，不先改代码 |
| 触达范围 | 哪些模块、数据、角色和文档需要响应 | 影响图与所有者 | 隔离共享状态或缩小接口 |
| 反馈延迟 | 何时能知道修改正确或错误 | 测试、演练、用户结果 | 建立更短的验证路径 |
| 恢复成本 | 结果不对时如何回到可用状态 | 回滚步骤、出口和数据保护 | 先做低风险实验再承诺 |
Change Surface 不是代码行数，而是变化需要协调的真实边界；它应能从依赖图和负责人清单中重建。
↡把目标变化、触达范围、反馈方式、接受条件和恢复动作写成可复查合同的工件。Changeability Contract 让“易变更”成为可比较的步骤，而不是设计者的感觉。
↡从执行修改到得到足够证据判断接受或拒绝之间经过的时间和等待环节。Feedback Latency 越长，错误越容易携带更多后续变化；测量它可以帮助团队决定先缩短哪条路径。
↡一次变化失败后恢复到安全、可用状态所需的步骤、时间、数据处理和协作代价。Recovery Cost 包含回滚、重放、迁移、通知和复核，不只是一条撤销命令的耗时。
↡针对同一变化目标提出的另一种边界、依赖和回退安排，用于与当前设计进行可证据比较。Design Alternative 不是为了制造选择题，而是让团队看见当前设计锁定了什么、放弃了什么。
提示14：把优秀设计解释为更容易变更
提示14：优秀的设计比糟糕的设计更容易变更。它不是要求所有设计都抽象成同一种形状，而是要求设计面对下一次变化时有较短的 Change Surface、较低的 Feedback Latency 和可接受的 Recovery Cost。
比较时使用同一个变化请求和同一组边界。设计 A 可能把供应商细节散落在业务流程中，设计 B 则将其隔在适配边界；只有把“切换供应商”真正走一遍，记录改动节点、测试等待、数据风险和回滚动作，才能说明 B 更容易变更。
从命题到可失败的因果链
本页主链是 变化目标 → Change Surface → 最小修改 → Feedback Latency → Recovery Cost。每条边要写明传递的是数据、决定、责任还是反馈；每个节点都要有输入、输出、所有者、接受条件和拒绝动作。只有一张没有状态变化的箭头图，不能证明设计质量。
先写预测，再执行正常样本、边界样本和一次故障样本。三类样本共享同一目标、版本和输入，只改变一个设计条件；如果结果不同，记录最早出现的偏离和恢复动作。不要同时改架构、流程和测试，否则无法知道哪个变化造成了结果。
两个设计的对照方法
设计 A：变化穿过业务流程
在设计 A 中，业务规则直接读取供应商字段、全局配置和发布状态。它初期代码少，但 Change Surface 大：字段变化、供应商错误和发布策略变化会同时影响多个业务节点。验证常常要等到集成或用户结果，Feedback Latency 长，失败时还要回滚多个状态。
设计 B：变化停在适配边界
设计 B 让领域规则面对稳定的内部协议，供应商字段、错误映射和发布选择停在适配边界。它需要明确协议和契约测试，但变化通常只触达适配器、测试和相关文档，Feedback Latency 较短，Recovery Cost 也更容易预演。
这不是对所有场景的先验判决。如果适配边界本身不稳定、团队没有验证能力，设计 B 也可能增加成本；结论必须绑定变化命题、当前约束和证据，而不是把“分层”自动当作优秀设计。
三步完成一次设计比较
先固定同一个变化命题
写出要替换的事实、受影响的用户或系统、成功标准和拒绝条件。为当前设计与 Design Alternative 各画一张 Change Surface，标出共享状态、数据出口和所有者。
可重放的设计记录
design_comparison:
unit: tpp20-topic-08-essence-good-design
change_request: 支持第二家支付供应商
shared_boundary: 订单金额、币种和用户结果
design_a_surface: 业务规则、配置、错误处理、发布清单
design_b_surface: 供应商适配器、契约测试、迁移说明
feedback_check: 契约测试、沙盒支付、低风险用户演练
recovery: 保留旧适配器，按租户撤回新路由
first_mismatch: 供应商超时被错误翻译成业务拒绝
decision: B 在本约束下更容易变更，但需补齐超时协议这份记录让结论可重建。若设计 B 的契约测试通过，却没有覆盖用户结果，不能宣布整个变化成功；若回滚需要手工修改多个数据副本，Recovery Cost 就应如实进入结论，而不能被“代码更少”抵消。
边界、反例与迁移
| 场景 | 初步判断 | 需要补的证据 |
|---|---|---|
| 小型一次性脚本 | 简单结构可能更容易变更 | 脚本是否会复用、数据是否可重跑 |
| 高频规则变化 | 稳定适配边界可能降低触达 | 规则 owner、契约和用户反馈时间 |
| 供应商不稳定 | 隔离变化通常更有价值 | 超时、错误语义和退出路径 |
| 团队缺少自动化测试 | 抽象边界可能难以验证 | 先建立最小反馈，再扩大承诺 |
反例不是“我更喜欢另一种风格”。它要在同一变化目标下显示：所谓局部变化实际扩散了，反馈来得太晚，或恢复动作无法在约束内完成。反例出现后，缩小结论范围、更新合同并重放旧样本。
迁移到云服务、数据系统或 AI 辅助开发时，要分别记录团队规模、发布频率、数据敏感性和自动化反馈。工具可以缩短机械检查，却不能替代对 Change Surface、Feedback Latency 和 Recovery Cost 的语义判断。
常见误区
本章回顾
掌握 8 优秀设计的精髓，不是背出一种架构风格，而是能用 提示14：优秀的设计比糟糕的设计更容易变更 解释并测量一个设计的 Change Surface、Feedback Latency 和 Recovery Cost。把同一变化交给两个设计，保存最小修改、首个偏离、恢复动作和未覆盖条件，才足以支持“更容易变更”的结论。
可验证练习
练习
本组练习覆盖 8 优秀设计的精髓 和 提示14：优秀的设计比糟糕的设计更容易变更，要求提交 Changeability Contract、Change Surface、Feedback Latency、Recovery Cost 和 Design Alternative 的证据。
问题 1： 两个设计都能完成当前需求，怎样比较它们面对下一次供应商替换时谁更容易变更？
问题 2： 如何实践“提示14：优秀的设计比糟糕的设计更容易变更”？
问题 3： 一个低层适配器改动导致用户流程和发布清单同时失败，如何诊断并恢复？
名词解释
名词解释
本章出现的专业名词，用大白话再讲一遍。
- Change Surface
一次变化需要触达的模块、数据、接口、角色和交付工件集合。
- Changeability Contract
记录变化目标、触达范围、反馈方式、接受条件和恢复动作的可复查合同。
- Feedback Latency
从修改开始到取得足够证据判断接受或拒绝所经过的时间和等待环节。
- Recovery Cost
变化失败后通过回滚、重放、迁移、通知和复核恢复的步骤与协作代价。
- Design Alternative
针对同一变化目标提出的另一种边界、依赖和回退安排。
前后导航
来源与改写范围
- Pragmatic Programmer 作者页面：核对 Topic 8 与提示14的版本位置和主题范围。
- 中文目录页面：核对 8 优秀设计的精髓、提示14：优秀的设计比糟糕的设计更容易变更的公开目录范围。
- 出版社书目信息：交叉核对中文译本的出版信息与版次边界。