3 软件的熵
把破窗从比喻转成可观察的熵信号、最小修复和能阻断扩散的守护证据。
学习目标
- 能把“3 软件的熵”中的破窗、默认容忍、复制扩散、修复和守护转成可观察的系统信号
- 能用“提示5：不要放任破窗”选择一个小而可交付的修复切片，并说明修复预算、用户影响和回归边界
- 能在缺陷暂时不能修复时记录例外、责任人和期限，用后续数据判断熵是否继续扩散
为什么 3 软件的熵不能只讲技术债
“3 软件的熵”关注的不是代码洁癖，而是被放任的小缺口如何改变团队行为。一个过期的说明、一次被忽略的失败测试、一个模糊的状态名，起初看似无害；当它们被复制、绕过或合理化，修改成本、理解成本和用户风险会一起上升。
这里的熵不是需要伪造精确分数的自然常数。它是一个提醒团队观察趋势的模型：哪里开始需要更多解释，哪里开始需要更多例外，哪里有人为了交付而重复绕过守护，哪里用户承担了本应由系统吸收的复杂性。
↡用户、团队或系统都能看到却被默认接受的小缺口，例如失败测试、过期文档、模糊命名或无监控路径。Broken Window 不是所有缺陷都同样严重，而是一个需要决定的信号：修复、隔离、记录例外，还是明确拒绝继续扩大影响。
↡能够显示缺口是否在复制、绕过、延迟和影响范围上扩大的可观察迹象。Entropy Signal 可以是重复缺陷数量、绕过门禁次数、恢复时间、交接问题、手工步骤或用户投诉，但必须和对象、窗口及阈值绑定。
↡范围足够小、能在当前交付中完成并可证明影响的修复单元，包含基线、触达路径和回退。Repair Slice 让“以后再清理”变成今天可以验证的一步，不要求一次重写全部系统。
↡让同类缺口更早暴露或禁止扩散的测试、检查、监控、流程和责任约定。Guardrail 不是一次性闸门。它要随着失败样本更新，否则团队会学会绕过它。
↡在给定时间和风险范围内允许暂存的缺口额度，超过后必须修复、升级或停止继续扩展。Drift Budget 不是给坏代码颁发许可证，而是让延后决定有明确期限、所有者、补偿措施和停止条件。
破窗如何变成扩散
第一扇窗：缺口可见
记录 Broken Window 的对象、影响、发现时间、责任边界和当前处理。不要用“只是临时的”抹掉事实；临时也需要到期时间和复查者。
第二步：团队默认容忍
当缺口没有所有者或期限，下一次任务会把它当作环境的一部分。开发者绕过失败测试，产品接受模糊状态，运维增加手工步骤，知识就从代码和记录中流失。
第三步：复制与合理化
真正的扩散不是缺陷数量简单增加，而是团队开始认为绕过、复制和隐藏是正常工作方式。Entropy Signal 要观察这些行为，才能在用户受损前发现趋势。
第四步：小修复和守护
提示5：不要放任破窗要求在缺口还小的时候行动。选一个 Repair Slice，修正根路径或减少扩散机会，再增加对应 Guardrail；如果暂时不能修复，就建立 Drift Budget，而不是无限延期。
先预测：一个失败测试连续三周被标记为“暂时跳过”，最早应该观察的是缺陷数量、绕过行为、用户影响还是团队语言？写出理由，再用项目历史记录验证。
熵扩散回路
可运行回路是 Broken Window → 默认容忍 → 复制/绕过 → Entropy Signal → Repair Slice → Guardrail。回路需要一个停止条件：如果修复只让当前检查变绿，却没有减少用户影响、重复绕过或恢复成本，说明触达点选错了。
当多个缺口同时存在时，不要用总数替代判断。优先选择会被复制、影响关键用户、阻碍恢复或迫使团队绕过其他守护的缺口。修复排序也应公开，避免团队用声音最大的人决定所有技术风险。
三步熵控制路径
先发现破窗与扩散信号
记录 Broken Window 的对象、用户影响、重复次数、绕过行为和当前所有者，选择一个可观测的 Entropy Signal。
破窗不是道德指责
团队放任缺口通常有上下文：上线窗口、未知风险、依赖限制、人员变动或用户尚未受影响。理解上下文不代表接受无限延期；它帮助团队选出合适的 Repair Slice，并决定谁需要承担 Drift Budget。
一个好的记录会写：缺口是什么，为什么暂时不修，谁批准，什么信号会触发修复，何时复查，以及超限后是否停止扩展。这样，团队不会把“务实”误解成“任何缺口都能留着”。
修复与守护边界
Guardrail 应保护真正的失败边界。例如，如果一个服务的配置缺少校验，修复可以先为高风险字段增加检查和测试，再把边界输入加入回归；如果流程依赖人工记忆，守护可以增加可见清单和到期告警。守护要能在工具、人员或发布方式改变后继续暴露问题。
回归样本至少包括：原始破窗、相邻变体、正常路径、边界阈值、依赖不可用和回退。若修复只覆盖原始样本，团队很可能把缺口换了一个名字继续复制。
entropy_record:
unit: tpp20-topic-03-software-entropy
claim: 小缺口被默认容忍时会改变复制和绕过行为
broken_window: 配置缺少校验，失败路径依赖人工记忆
entropy_signal: 绕过次数、重复工单、恢复时间、用户投诉
repair_slice: 为高风险字段增加校验、测试和可见告警
guardrail: 边界样本回归、发布检查、超期提醒
drift_budget: 7天，责任人明确，超期停止扩展
decision: 修复、隔离、延期升级或停止选择与拒绝矩阵
| 评审问题 | 可以接受的证据 | 应拒绝当前判断的信号 |
|---|---|---|
| 破窗 | Broken Window 有对象、影响和所有者 | 用“临时”隐藏缺口和期限 |
| 趋势 | Entropy Signal 观察复制、绕过和用户结果 | 只有技术债总数，没有行为信号 |
| 修复 | Repair Slice 可交付、可回退并触达根路径 | 只有大重构愿景，没有今天的动作 |
| 守护 | Guardrail 能覆盖相邻变体并持续暴露问题 | 检查只对原样本有效，团队能轻易绕过 |
| 延期 | Drift Budget 有期限、补偿和超限动作 | “以后再说”没有责任人和停止规则 |
| 结果 | 回归样本证明扩散减少、恢复变容易 | 只让单个测试变绿就宣布完成 |
常见误区
本章回顾
掌握 3 软件的熵，不是把所有技术债都清零，而是能按提示5识别 Broken Window，找到 Entropy Signal，完成小而真实的 Repair Slice，设置 Guardrail，并用 Drift Budget 管理不能立即修复的缺口。务实的团队允许有上下文的延期，但不允许无期限地把例外变成默认行为。
可验证练习
练习
本组练习覆盖 3 软件的熵 和 提示5：不要放任破窗，要求提交熵信号、修复切片和守护证据。
问题 1： 一个失败测试连续三周被跳过，如何判断它是否已经成为破窗？
问题 2： 如何实践“提示5：不要放任破窗”而不承诺一次大重构？
问题 3： 当前迭代无法修复一个缺口，应该怎样延期？
名词解释
名词解释
本章出现的专业名词，用大白话再讲一遍。
- Broken Window
可见但被默认接受的小缺口，会影响后续行为和系统理解。
- Entropy Signal
显示缺口是否在复制、绕过、延迟和影响范围上扩大的观察信号。
- Repair Slice
范围清楚、当前可交付、包含回退和影响证据的最小修复单元。
- Guardrail
让同类缺口更早暴露或禁止扩散的测试、监控、流程和责任约定。
- Drift Budget
对暂时保留缺口设定的期限、所有者、补偿措施和超限动作。
前后导航
来源与改写范围
- Pragmatic Programmer 作者页面：核对 Topic 3 和提示5的版本位置与主题范围。
- 中文目录页面：核对 3 软件的熵与提示5：不要放任破窗的公开目录范围。
- 出版社书目信息：交叉核对中文译本的出版信息与版次边界。