scoping-changes

变更范围

必备背景： principal-engineering 技能。

概述

范围控制可能朝两个方向失当：过度完善会让修复超出触发它的问题；悄然缩减范围则会让已批准的任务缩水到低于约定内容。这两者是同一个缺陷：交付的变更不再与其成因相符。核心原则：修复的规模应与触发它的问题相称；现实迫使你删减时，应明确拆分，而不是悄悄删减。

按触发原因确定规模

• 触发原因是缺陷或需求本身，而不是工单中描述它的那句话。 在第二条路径上发现的同一缺陷也属于范围内（如果问题仍在其他地方，却报告说“已修复”，那就是半真半假的报告）；因为文件正好打开而发现的相邻改进则不属于范围。
• 修复的规模应与触发它的问题相称。不要过度完善，不要为不可达的边界情况加防护，也不要因为文件正好打开就顺带重构。
• 你注意到的相邻改进确实存在，应记入跟踪系统，而不是放进本次差异中。
• 判断边界情况新增内容的标准：如果主要修复不存在，这项改动是否仍会基于自身价值发布？如果不会，它就是搭别人差异的便车。如果会，就应独立发布：通过这项测试只意味着可以单独变更，绝不意味着可以顺带加入。
• 负责人可以重新确定范围，但不能合并不同范围。负责该工作的人员提出“顺手加上”时，确实会增加第二项任务，但它仍应作为独立变更发布。这些规则规定了如何组织工作；负责人决定有哪些工作。
• 未经请求的结构设计，是披着设计模式外衣的范围蔓延：只有一个实现者的接口、永远只创建一种对象的工厂、没人会更改其值的配置。等第二种情况出现时再增加结构，不要在它尚未出现时就设想出来。
• 如果有意简化并接受了真实存在的限制，应在注释中写明限制：上限是什么，以及什么情况会构成提高上限的理由（“一个共享队列；当单个消费者无法再跟上时，按租户分片”）。上限是当前约束：注释描述系统现在的行为，而不是当初作出这一决定的原因。
• 编写新代码前，先彻底检查代码库、标准库、平台和已安装的依赖；考虑引入新包前，请参阅 adding-dependencies。

明确拆分，绝不悄然缩减范围

• 已批准的任务如果实际规模过大，负责人应将其拆分成具名部分，并明确说明删减范围的界限；绝不交付看起来完整的“务实最低限度”。
• 作者应将每个延期部分作为跟踪项登记并指定负责人；如果目前尚无负责人，则应明确标注“负责人待分诊”。安装了 technical-writer 插件时，跟踪事项的规范见其中的 writing-issues。只留在作者记忆中的延期工作属于缩减范围，而非延期。
• 报告应明确说明哪些部分已交付、哪些未交付。诚实标注的部分交付是一项计划；标注为完整的部分交付则是一个缺陷。

推动工作完成

• 已批准的计划应持续执行直至完成，不要设置“要我继续吗？”之类的检查点；只有遇到真正的阻碍、破坏性操作或需要操作人员处理的硬性关卡时才停止。
• 某个部分受阻时，完成未受阻的部分，并说明阻碍及所需条件；绝不能让一项停滞的任务悄然拖住其余工作。
• 执行过程中，已经敲定的决定仍然有效。只有真正足以重新考虑某项决定的新信息，才应明确重新决策，而不是悄然改变方向；安装了 technical-writer 插件时，请通过 recording-decisions 记录。

评审中的范围

• 评审他人代码时：顺带发现的无关缺陷不属于你的评审意见；记录一次以供跟踪，然后继续聚焦差异。
• 你的代码正接受评审时：针对差异的意见应予以修复或明确回应；差异以外的问题应记录以供跟踪，不要并入本次变更。

常见错误

• 用“顺便做一下”作为理由。你来此是为了处理触发任务。
• 为赶截止时间而缩小范围，却报告已完成。截止时间带来的压力确实存在；诚实的做法是拆解任务，并说明完成了哪一半。
• 为了显得周全而防范系统无法触及的边缘情况。无法触及的防御代码，只是怀着好意编写的死代码。
• 实施过程中因为出现了一个稍好的点子，就重新争论已获批准的设计。先记下这个点子；完成既定方案；再结合已交付的实际情况提出建议。
• 让评审者提出的范围外要求扩大差异。记录下来，感谢他们，然后交付触发任务。