simplify

简化

实现应尽可能小巧清晰，同时完整满足所需行为。减少概念和复杂环节，而非单纯减少代码行数。

节奏

• 添加代码前，先确定满足要求的最小改动；每个新概念都必须有存在的必要。
• 构建过程中，在了解行为的同时就地应用优先级。必要时可使用明显临时的插桩或脚手架来加快探索。
• 收敛时，某个逻辑行为片段通过验证后，就简化该片段，移除已被取代的尝试和脚手架，并重新进行针对性验证。
• 如果明确要求审查分支，则与预期基准进行比较。否则只审查所要求的改动；不要把小型清理扩大成对整个分支的审查。

工作流

1. 明确所需行为、不变量、约束和非目标。
2. 检查相关差异，并将其拆分为逻辑概念。若要对最终分支进行审查，则将整个分支与其合并基准进行比较，并在相关时检查历史记录中是否有已被取代的尝试。
3. 添加任何内容前，检查现有的所有者、事实来源、常用路径、决策点以及附近代码风格。
4. 选择必要概念最少、运行时开销最低的设计。
5. 收到改动请求时，直接实现，并在合适时复用现有机制。
6. 根据风险进行适当的行为验证。
7. 审查最终代码、测试、名称、注释、文档、配置和相关历史，确认没有不再值得保留的复杂性。

简化优先级

• 遵循仓库现有的风格和模式：命名、文件布局、错误处理、测试风格以及现有库。已有模式适用时，不要引入新模式。
• 优先删除、复用或直接修改，而不是添加新的抽象。
• 保持单一事实来源；避免镜像状态、重叠防护、重复注册表和补偿机制。
• 仓库没有约定时，优先采用直观的正向控制流，而不是一连串提前返回或空分支。
• 在热点路径上，尽量减少内存分配、回调重建、订阅、渲染、遍历、I/O 和原生操作。
• 对于说明文字，删除重复内容，并采用仍能独立说明问题的最简措辞或示例。

过度设计检查清单

如果以下内容并非必需行为、不变量、有效说明、经测量的性能需求或仓库现有约定所需，请将其移除：

• 可以直接内联的一次性辅助函数；
• 类型或调用方已排除状态下的防御性空值或类型检查；
• 当前调用方不需要的配置标志、选项或参数；
• 只负责转发的包装类型或类；
• 已有合适所有者时仍新增的文件、模块或抽象；
• 任务不需要的回退、兼容或迁移路径；
• 会吞掉错误或静默回退的 try/catch 块；
• 没有实际使用场景的推测性泛化：扩展点或未使用的情况。

逐行检查

• 阅读每个新增代码块时，结合其周围的现有代码，而不只是差异片段。
• 检查新代码是否重复了周围代码中已有的语句、返回或分支。
• 检查是否可以通过保护、包装或跳过现有代码，取代添加并行路径。
• 检查是否有现有代码行因此变得不可达或多余。
• 对发现的每个问题，采用更精简的改写，或明确报告；仅给出差异整体“精简合理”的结论并不足够。
• 示例：在扫描循环前添加快速路径 if (sortsAfterTail) { queue.push(task); return; }，但循环末尾本就会执行 queue.push(task)，这就重复了入队操作。应使用 if (!sortsAfterTail) 保护循环，让两个路径共用末尾的一次入队操作。

现有工作

简化可正常工作的代码前，先建立通过验证的基线。每次只测试一个存疑的概念，重新运行相关验证；如果行为或有意义的覆盖率变差，就将其恢复。未确认哪些更改确有因果必要性前，不要重构多次累积的修复尝试。

如果怀疑回归覆盖重复或无效，就故意破坏所声称的不变量，并确认剩余测试会失败。测试通过本身并不能证明每项测试或实现概念都是必要的。

未经授权，不要改写分支历史。

性能更改

明确指出要移除的常见路径工作：分配、扫描、挂载、渲染、订阅、I/O 或原生调用。控制流证据加上回归测试，可以作为移除结构上未使用工作的依据。如果优化会改变语义或引入权衡，则必须提供基准测试、性能分析或重复复现。不要为了理论上的收益增加复杂度。

防护原则

• 保持正确性、必要行为、类型安全、独立的回归覆盖和清晰易懂。
• 不要仅为减少代码行数，就用压缩或取巧的代码替换清晰的代码。
• 直接进行范围明确且不改变行为的改进。如果超出请求范围的简化会改变公共 API 或引入新概念，应先解释并提出建议。
• 不要触碰无关更改和用户编写的更改。

当剩余的每个概念都有助于满足需求、保持不变量、提升清晰度、遵循现有仓库约定或满足经过测量的性能需求时，即可停止。只报告实质性的简化、验证结果和未解决的改进机会。