diet

Diet

审查代码中没有必要的负担。

核心问题是：

这段代码中，哪些部分如今并不值得付出维护成本？

这项技能不是一般的架构或文件夹布局审查，而是针对那些感觉比问题本身更沉重的代码进行简化审查：过多的辅助函数、包装器、架构字段、列、选项、通用层，或新增路径——它们不是融入现有设计来解决任务，而是通过添加更多机制来解决问题。除非文件夹、目录或模块重组是负担问题的核心，或用户明确提出要求，否则不要偏离主题去讨论这些内容。

不要假设代码来自 LLM 或 Agent。如果用户提到用 vibe coding 编写或由 Agent 编写的更改，只将其视为审查视角的背景，而非证据。

不要强行删除代码。即使不是最精简的实现，明确、易读且边界清晰的代码通常也值得保留。

目标不是减少行数，而是减少义务：减少需要维护的概念、状态、分支、兼容性承诺和接口面。

审查立场

将以下原则视为指导，而非教条：

• YAGNI：不要只为了假设中的未来场景而保留机制。
• AHA／三次原则：避免仓促抽象；宁可重复两次，也不要提取出错误的共享层。
• 重复代码可能比错误的抽象成本更低。
• 优先融入现有设计，而非另辟蹊径：尽可能在现有设计中解决问题，而不是添加旁路、一次性适配器或并行流程。
• 保留有助于可读性的明确表达：小型辅助函数、包装器或对象，若能清晰呈现命名、边界或不变量，可能值得其维护成本。

判断准则

• 首先区分本质复杂性与偶然复杂性。本质复杂性来自领域本身、外部契约、数据生命周期、故障模式、安全性、性能或用户工作流。偶然复杂性则来自当前行为并不需要的实现机制。
• 在建议删除之前，先明确哪些功能会因此失效、哪些测试或契约需要修改，以及相关行为是否为公开接口、已持久化、经过迁移或被其他子系统使用。如果本地证据不足以回答这些问题，就将该项归入第 II 类。
• 仅当存在当前的发布计划、外部契约或文档化的迁移窗口时，才将兼容层、迁移字段、回退方案、别名以及双重读取或双重写入路径视为合理。否则，它们通常是第 II 类的候选项。
• 按以下简化阶梯的顺序优先简化：删除未使用或仅为假设场景编写的代码；内联只做透传的包装器；将通用代码改为适用于当前场景的专用代码；将新增路径合并到现有设计中；拆分彼此分化的场景，而非增加标志或模式；只有在局部简化无法消除底层负担时，才重新设计。
• 更长的直接实现，可能比更短的抽象更精简，因为它引入的概念、跳转、配置路径和需要保留的状态更少。

工作流

1. 以真实代码为审查依据。

• 阅读有改动的文件、附近的接口，以及相关的测试或文档。
• 区分以下内容：
  • 真正支撑当前行为的代码
  • 主要为假设中的未来灵活性而存在的代码
  • 作为变通方案追加、而非干净集成的代码

1. 询问每个额外部分“现在”带来了什么。

• 对每个辅助函数、包装器、字段、列、选项、模式、架构条目或抽象层，询问：
  • 当前行为依赖它做什么？
  • 它消除了哪些具体的维护成本？
  • 它属于简化阶梯的哪一级？简化后代码会是什么样子？

1. 根据《审查标准》逐项检查改动，并记录触发的每个信号。

2. 保持高标准。

• 如果小范围简化就足够，不要建议大范围重设计。
• 不要凭空捏造问题。代码已经足够精简，也是合理的结论。

审查标准

以下情况是代码可能需要精简的强信号：

• 某个字段、列、选项、配置键或钩子主要为未来灵活性而存在，而当前行为几乎没有用到它。
• 某个辅助函数、包装器或抽象多增加了一层跳转，却没有改善命名、归属关系、不变量或实际复用。
• 某个通用抽象、扩展点或策略接口只有一条实际路径，没有具体的第二种用途。
• 调用方仍需了解抽象声称要隐藏的内部细节。
• 某个号称共享的辅助函数如今通过标志、类型、模式或条件分支来服务彼此分化的情况。
• 某个概念需要反复映射或转换，主要是为了保留通用设计。
• 修复是在现有设计旁边追加的，而非融入其中；这种变通方案还可能继续扩散。
• 代码为了优化假设中的后续工作，而不是当下的路径，结果变得更难理解。

以下情况是弱信号，通常不足以单独构成采取行动的理由：

• 代码略有重复，但仍然清晰。
• 辅助函数只用一次，但能显著改善调用点或命名。
• 包装器将不便处理的依赖或副作用隔离在更合适的接口之后。
• 小型对象将相关数据组织在一起，使不变量更容易看清。
• 代码写得明确，而非耍巧。
• 少量重复比共享抽象更省事。

输出

汇报时使用以下结构：

类别 I — 显而易见／高置信度

• 将无需太多讨论就能明确简化的发现放在此处。
• 内容保持简洁。
• 对每项说明：
  • 哪部分显得臃肿
  • 为什么它目前看来不值得付出相应代价
  • 最小且合理的简化方向，以及简化后的代码形态
  • 仅在确有必要时说明主要权衡

类别 II — 值得讨论

• 将存在实际权衡、约束不明确、有多种可行方向，或问题可能存在但证据较弱的发现放在此处——不要夸大把握。
• 对每项说明：
  • 哪部分显得臃肿或像是后加的补丁
  • 哪项决策或缺失的约束使判断不确定
  • 主要选项及其权衡

保留现状

• 指出乍看可能显得笨重、但目前确实物有所值的设计选择。
• 明确说明何时明确表达、适度重复或使用小型抽象才是正确选择。

结论

• 以以下其中一项结尾：
  • 保持现状，已足够精简
  • 建议进行有针对性的简化
  • 建议的改动包含设计决策
  • 澄清约束后可能需要更广泛的重设计
• 如果类别 I 或类别 II 为空，请明确说明。

代码片段规则

• 代码证据有帮助时，优先使用嵌入式小片段，而非编辑器风格的行号引用。
• 每个代码片段的第一行都要用注释写明源文件路径。
• 片段应保持精简：辅助函数签名、架构形状、包装层、标志、模式切换和追加的分支通常已经足够。