可修改性战术应用
§1摘要与结论
可修改性指系统在需求或环境变化时，以可接受的代价完成修改的能力。其方法以耦合、内聚与成本动因为依据应用一组战术：推迟绑定时间、局部化变更、防止涟漪效应，使修改集中在局部、缩小受影响模块数与回归风险，从而降低变更成本。判据不是代码是否整齐，而是「改动一个模块时，有多少其它模块必须随之改动」。影响范围由模块之间的相互牵连程度与模块内部职责的聚合程度共同决定：牵连越高、聚合越低，一次改动波及的范围就越广。变更成本等于改动本身的成本加上因耦合被牵连的其它模块的成本，故减少后者往往比减少前者更能显著降低总成本。
别名：modifiability tactics、可修改性战术、推迟绑定、局部化变更、防涟漪 | 英文：Applying Modifiability Tactics | 类型：方法 / tactic
§2局部关系图
§3原理 · 为什么
可修改性战术的靶心是三样东西：变更本身的复杂程度、完成变更所需的时间、以及所耗成本。判断变更影响面大小的两个度量早已有之——模块之间的相互牵连程度，以及模块内部职责的聚合程度：前者越高、后者越低，一次改动波及的范围就越广，代价随之上升。战术不追求某种静态结构，而是调整系统在变化发生时的行为，让影响尽量小、尽量局部。其经济逻辑在于：一次修改的总代价等于改动本身的代价加上被牵连模块的连带代价，而压低后者的收益通常远大于压低前者。因此设计阶段就应把「多少其它模块必须随之改动」显式化，据此预见哪些结构会让未来变更昂贵，提前规避而非事后补救。这条原则还要求把变化的方向而非变化的数量当作设计输入：模块边界应顺着预期的变化轴切分，使同一类变化集中落在同一处，若边界与变化方向错位，再好的封装也只能延缓而非阻止涟漪。代价的四个组成部分——编辑、理解、验证与部署——中，理解与验证通常远大于编辑，因此衡量一次改造是否成功，看的不是改动是否变少，而是必须重新理解与重新验证的范围是否真的缩小。界定上还应区分两类修改：一类是局部参数或逻辑的调整，另一类是模块边界与接口契约的重新划分，两者代价量级不同，若混为一谈就会用大量小改动掩盖结构性缺陷。与之相配，应明确哪些类别的变更是设计所承诺支持的，哪些是明确不支持的，因为无边界地承诺一切变化等于没有承诺。此外，修改的代价不只包含编辑，还包含验证：改动之后必须重新测试的范围决定了实际开销，所以缩小波及范围的价值不仅在于少写代码，更在于少做验证。
§4机制 · 如何运作
机制上，战术分三支。其一提高模块内部的职责聚合度，把预期会变化的部分集中在尽量少的模块内，使一次修改只触及少数位置，模块划分因此应围绕易变的设计决策而非执行步骤。其二削减模块之间的相互牵连，其下含四项手段：封装、引入中间层、把多个模块共用的服务抽取出来、以及限制依赖；共同机理是在原本直接相互牵连的两个模块之间插入某种隔离物或可见性约束，切断变更沿调用关系外溢的路径。其三把取值时点往后挪，即推迟绑定，按时点分层：构建或编译期可用构件替换与参数化，部署与启动期可用配置绑定与资源文件，运行期可用服务发现、参数解释、共享仓库与多态分派；参数化被视为最典型的柔性机制，函数带默认值即是其雏形。三支战术之间存在次序：先确定职责如何切分，再约束切分之后的依赖方向，最后才考虑把哪些取值推迟，因为绑定推迟只能让同一结构承担更多取值，无法弥补边界划错的损失。推迟绑定还按时点带来不同的能力边界：越早的绑定可用的手段越少但机制越确定，越晚的绑定越灵活却越依赖运行期的约定与配置，出错也越难在编译阶段暴露。因此选择绑定时点时应同时评估该决定的可逆性与出错后的可观察性，而不只看灵活性。
§5工程 · 怎么落地
工程落地时，先以假想的一组变更为素材做推演，这是低成本的职责勘定手法：若若干变更场景总是同时牵动某模块的同一片区域，说明该模块内混入了本应独立的职责，宜拆分迁出；若场景反复要求同时改动多个模块，则说明这些职责本属一体，宜聚拢到同一处。推演的输出是职责与依赖的重新分布方案。据此对变化方向明确的部分应用局部化，对需要多种实现并存或切换的部分应用推迟绑定，对可能沿调用链扩散的部分应用防涟漪措施。耦合与内聚度量只作巡诊信号，是提示而非结论，最终仍要结合变更频率与领域语义判断。战术应用后应以真实变更验证：下一次同类修改是否确实只触动了预期范围；对新引入的间接层要设退出条件，当它不再带来可修改性收益时予以拆除。若波及范围未如预期缩小，说明切分判据选错，应回到「变化究竟发生在哪里」重新审视边界。推演时可用两条更细的判据替代凭感觉的归类：同一处修改是否总在同一时间被触发，以及是否会因相同的原因而变化，同因同变者宜聚，异因异变者宜分。战术落地还应设定可核对的约定，例如规定依赖只能指向稳定方向、禁止跨层直接调用、把易变取值集中到少量配置入口，并让这些约定在评审中可被指出违反之处，否则战术会随时间被侵蚀。对于推迟绑定，还要评估配置项的数量与默认值的明确程度，配置项过多或默认值含糊会让系统表面灵活、实际难以运维，错误往往延迟到运行期才显现；
§6权衡卡
- 可修改性与性能之间的张力有明确来源：把绑定时刻往后推、让调用绕经中介、以及增加抽象层次，都会在运行路径上增加开销；而且越晚的绑定通常意味着越昂贵的前置机制准备。
- 于是取舍点落在「晚到何种程度仍划算」这一问上，而非无条件追求最晚绑定。
- 因此战术投入应依据真实变更模式，集中在高频变化处，并接受在稳定区域保留一定重复或不完美。
- 可修改性投资还需随变化热点的迁移而动态调整：今天值得解耦的部分明天可能趋于稳定，今天可容忍的重复明天可能成为瓶颈。
- 因此可修改性的投入应当与变更的真实频率和影响面挂钩，并在结构改动之后安排一次同类变更作为检验，确认波及范围确实按预期收缩。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7冲突 / 对比表
| 对照维度 | 可修改性战术应用 | 可用性战术应用 |
|---|---|---|
| 定位 / 依据层 | 可修改性战术应用 · Applying Modifiability Tactics | 可用性战术应用 · Applying Availability Tactics |
| 核心定义（原文） | 可修改性指系统在需求或环境变化时，以可接受的代价完成修改的能力。 | 可用性讨论的起点是把两个词分清：失效指系统不再按规格交付服务，且这一情况能被参与者观察到；故障指可能导致失效的潜在原因。 |
| 首条机制断言（原文） | 可修改性战术的靶心是三样东西：变更本身的复杂程度、完成变更所需的时间、以及所耗成本。 | 可用性战术的统摄目标是让服务始终与规格相符：要么在故障发生前拦住它，要么在它发生后承受住。 |
| 张力冲突关系 | 冗余可用性措施与可修改性存在张力（张力冲突） | 同一条 张力冲突 边的另一端 |
| 典型反例（原文） | 可修改性与性能之间的张力有明确来源：把绑定时刻往后推、让调用绕经中介、以及增加抽象层次，都会在运行路径上增加开销；而且越晚的绑定通常意味着越昂贵的前置机制准备。 | 另一类反例是把重试当作通用解法：对非幂等操作重试会制造重复副作用，缺少退避与上限的重试会把瞬时故障放大为过载，反而降低可用性。 |
| 处置要点（原文） | 工程落地时，先以假想的一组变更为素材做推演，这是低成本的职责勘定手法：若若干变更场景总是同时牵动某模块的同一片区域，说明该模块内混入了本应独立的职责，宜拆分迁出；若场景反复要求同时改动多个模块，则说明这些职责本属一体，宜聚拢到同一处。 | 工程上先定义可度量的可用性目标与恢复预期，识别系统中的单点与关键依赖，再据此选择战术组合。 |
§8案例带
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
网申 v3 多模块解耦
一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。
网申 v2 深度重构
一次由「改一处漏多处」症状触发的深度重构：定位到接口定义散落 12 个文件、存在 7 种接口形态的根因后，以单一契约源、dispatch 消息表与能力注册中心重建三层契约系统，恢复可审计与可校验性。
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
§9信源与核验
核验结论：可修改性战术分为三类：推迟绑定时间、局部化变更、防止涟漪效应，分别从何时绑定、变化集中何处、影响如何截断三个维度降低变更成本 [OFF-024]
§10原始关系清单
展开：本节点的全部原始关系边（3 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 张力冲突 | ← MTH-M-03 | 可用性战术应用 E-353 | 冗余可用性措施与可修改性存在张力 |
| 依据推导 | → ESS-M-01 | 可维护性本质 E-347 | 可修改性战术服务于可维护性本质 |
| 细化 | → MTH-M-01 | 质量属性战术映射方法 E-351 | 可修改性战术是战术映射的细化 |