safe-incremental-coding

安全的增量编码

选择模型之前先选择分支。协调工作和确定性命令在调用权限范围内执行。在当前角色中应用此方法。它不会分派工作者。若要分派工作者，请使用 shared/references/model-preview.md 及其唯一获批的路由快照。嵌套技能和运行器会使用该快照，不再进行选择或分派工作者。

使用 Dave Farley 的 The Software Developers' Guidebook 中的旧版变更方法，保护请求变更所需的现有行为。目标是易于变更：受影响的代码可以安全地修改。

在重构前建立一张特征测试网。将工作限制在请求变更所需的范围内。

建立测试网

1. 确定受影响的行为，以及能够对其进行测试的可观察边界。
2. 使用有代表性的输入，捕获当前输出或副作用，包括相关的边界情况和失败情况。即使现有行为包含已知缺陷，也要将其固定下来；有意变更行为是单独的步骤。
3. 控制或规范化时间戳、标识符、种子及其他可变值，但不要掩盖与变更相关的行为。
4. 如果单元测试依赖当前内部结构，优先选择验收或集成边界上的测试。
5. 如果现有边界无法呈现该行为，将初始生产代码修改限制在建立最小观察接缝的范围内。保持其业务逻辑不变，并在进一步修改生产代码前捕获基线。
6. 确认测试在基线上通过，并且能够检测到相关行为的变化。

通过的基线只能保护其所覆盖的情况。如果请求的变更依赖尚未覆盖的情况，就为其补充测试。

消除可测试性障碍

建立测试网后，找出仍有哪些因素阻碍对请求变更进行测试。只使用能够消除该障碍的结构性技术。

障碍	可能的变更
已证实的死代码或注释遮蔽了受影响的路径	在请求范围内移除这些内容。测试覆盖本身并不能证明代码未被使用。
一个代码块组合了变更必须隔离的多个决策	提取一个内聚的操作，并用能说明其用途的名称命名。
控制流掩盖了需要测试的行为	在保持行为不变的前提下，简化受影响的条件或流程。
依赖项导致无法控制输入或观察输出	添加范围狭窄的接缝，或将相关决策与其副作用分离。
无关职责妨碍了有针对性的测试	在受影响的边界内分离这些职责。

选择适合周边代码和所需测试的结构。使用能够降低风险的受支持重构工具。

确保每项结构性变更都保持行为不变。每完成一项连贯的结构性变更，就运行受影响的特征测试，然后再开始下一项。继续之前先调查失败原因。如果变更或失败暴露出更广泛的风险，就扩大检查范围。

完成与交接

满足以下条件后，停止准备工作：

1. 相关现有行为已有通过的特征测试。
2. 可以通过可用的测试边界验证请求的变更。
3. 任何必要的结构性变更都保留了捕获到的行为。

如果建立测试网后这些条件已经满足，就直接开始请求的工作。

例如：“特征测试保护了当前输出，依赖接缝则让 tdd 能够测试请求的变更。”

对有意的行为变更应用 tdd。在更细粒度的测试发挥作用时，继续保留特征测试作为保护。只有在替代测试能明确覆盖相同行为时，才移除对应的特征测试。

报告受保护的行为、所做的可测试性变更、运行的检查，以及仍存在的证据缺口。

边界

1. 将有意的行为变更与特征描述和重构分开。
2. 如果需要先解释意外行为，才能安全地将其固定下来，请使用 diagnose。
3. 对已受测试保护的代码进行局部清理时使用 clean-code；评估测试价值时使用 test-lens；做出模块边界决策时使用 architecture-lens。
4. 不要引用或重构书中的原文。