simplify-code-solution

简化代码解决方案

为代码问题寻找最简单且完整的生产级设计，无论是提议的解决方案还是现有代码。更简单意味着在满足所有实际需求的同时，更易于理解和修改。文件、函数或代码行更少，本身并不意味着解决方案更简单。

1. 选择模式

• 建议： 适用于“能否更简单？”之类的问题，或对提案进行评审。不要编辑文件。要求修改提案时，应修改提案，而不是它所描述的代码。
• 实现： 当用户要求简化或重构代码，或应用某项建议时使用。直接进行修改并验证，无需再次征求批准。

除非用户要求进行修改，否则保持在建议模式；认可某种设计并不代表要求实施。只有当缺失的决定会改变解决方案或其范围时才提问。

2. 了解代码必须实现什么

阅读当前路径上的代码、其调用方、测试和本地模式；需求和风险明确后就停止阅读。然后区分：

• 需求： 调用方依赖的行为和契约，以及成功标准。
• 假设和锦上添花的功能： 可以舍弃的内容。
• 需要保留的复杂性： 编码了实际领域规则、持久性、恢复能力或运维保障的代码。持久队列、显式状态和领域区分往往看起来复杂，但仍然不可或缺。

在提议移除某个机制之前，要先了解它的使用方、它在运维和故障处理中的作用，以及什么机制会取代它。

3. 找到更简单的结构

留意以下方面：

• 是否有现有路径、辅助函数、类型、组件或 API 可以承接该行为，而不承担无关职责
• 是否有代码重复实现了语言、框架或现有依赖已经提供的功能
• 是否有泛型代码、扩展点或配置实际上只有一种变化
• 是否存在为局部问题而重写、用状态机处理简单状态、为单个调用方引入框架、推测性迁移、添加新依赖，或仅为内部便利而大范围更改 API 的情况
• 是否有只增加一次跳转调用的封装；先阅读其调用方，并保留那些处理规则、清理工作或兼容性的封装，避免这些职责落到调用方身上
• 逻辑是否放在了不合适的位置，或某个所有者是否承担了独立的工作流

即使只有一个调用方，只要某个专用模块能隐藏真实复杂性并减少调用方需要了解的内容，它就有存在的理由。比较整个生命周期的成本，而不是初始规模；如果简化只是把复杂性、风险或手动工作转移到下游，就应否决。

替换接口时，要找出所有使用方，包括测试。迁移测试以使用替代方案，同时检查相同的行为；不要仅仅为了测试而保留旧 API。当仍有其他调用方或正在进行迁移时予以保留，并说明何时可以移除临时适配器。

发现某项简化后，检查请求范围内的其余部分是否也存在同样的问题，并一并处理。范围之外的情况应单独报告。

4. 实现

在实现模式下，重构前运行相关测试，并在重构后保留相同且有意义的测试用例。只有在获准更改契约，或证实测试有误时，才更改预期结果。不要以掩盖失败为目的修改测试夹具、模拟对象或测试选择。如果工作包含行为修复，且 tdd 技能可用，就使用该技能；否则，先观察回归测试失败，再修复代码。

完成修改并验证；不要停留在提案阶段。如果遇到阻碍而无法继续，保留任何有效的失败测试，并报告缺少的决定以及尚待完成的事项。

5. 报告

对于建议，使用以下格式，并省略没有实际内容的行：

**Requirements:** what the code must keep doing.

**Complexity to keep:** what stays, and why.

**Assumptions to drop:** what the current design assumes without a requirement.

**Simpler path:** the concrete change, with locations.

**Tradeoffs:** what gets worse or riskier.

**Validation:** how to confirm behavior is preserved.

对于实现，报告修改了什么、为什么更简单、运行了哪些检查及其结果，以及任何限制。