complexity-budget

complexity-budget

找出负责该行为的层，然后评估所提复杂性是否值得付出代价。 用这一视角审视有争议的设计选择；日常修改前无需走这套流程。

决策标准

• 找出不变量是在哪一层确立的。在多个调用方重复修复的问题，可能应该由更底层的组件处理。
• 在添加新机制之前，尝试组合现有函数、类型或配置。
• 比较扩展现有行为与单独实现。合并可以减少重复，但跨越所有权或信任边界的耦合，代价可能高于少量重复代码。
• 评估耦合和允许存在的无效状态，而非代码行数。在正确层级进行的较大改动，可能更简单。
• 遵循项目惯用做法。在可行时，优先使用能防止无效状态的类型或构造函数。

审查拟议变更

留意新增的跨模块依赖、重复概念、共享可变状态，以及用于防范无效组合的分支。 通过将行为移至其所属层、复用基础组件、简化状态模型，或说明足以证明新增内容合理的具体结果，来解决相关问题。

只报告实质性的权衡或尚未解决的选择。不要要求逐条口头回答所有标准、采用固定的输出模板，或进行无关重构。

如需深入分析有争议的决策，请阅读 REFERENCE.md。