Back to Details

simplify-change

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Simplify a Change

简化变更

Prefer the smallest conventional solution that satisfies the current requirements. Optimize for fewer concepts, dependencies, branches, files, and special cases—not minimum line count.
优先采用满足当前需求的最小且符合惯例的方案。优化目标是减少概念、依赖、分支、文件和特殊情况，而不是单纯追求最少代码行数。

Procedure

步骤

  1. Establish the contract. Identify the requested behavior, constraints, affected code, and relevant project conventions. Do not simplify behavior whose purpose or requirements are still unclear.
  2. Test whether each piece is needed. Ask, in order:
    • Does a current requirement need it?
    • Does the project already provide it?
    • Does the language, standard library, platform, or an existing dependency provide it?
    • If not, what is the smallest clear local solution?
  3. Make the smallest coherent change. Delete, inline, or reuse code when that preserves the contract. Avoid speculative extension points, wrappers, dependencies, configuration, and fallback paths. Keep code conventional and understandable; fewer lines are not automatically simpler.
  4. Review in proportion to risk. For a small, local change with no meaningful new logic or concepts, review the diff directly. For substantial logic, generated code, or changes adding abstractions, dependencies, configuration, or indirection, seek two reviewers with fresh context when separate reviewers are available:
    • Challenge necessity: Assume each addition is unnecessary until a current requirement justifies it. Look for code that can be removed, inlined, reused, or replaced with existing project, language, platform, or dependency features. Report concrete findings and the requirement each addition fails to justify; do not propose new features or architecture.
    • Review as a maintainer: Inspect the repository and diff without relying on implementation rationale that is not recorded there. Flag hidden assumptions, unclear purpose, or unusual complexity. Report concrete findings.
    Treat reviewers as critics; make and verify any accepted changes yourself. If separate reviewers are unavailable, perform the two reviews yourself as distinct passes and do not describe them as independent.
  5. Verify the result. Run the narrowest existing checks that can detect regressions, then broaden them according to risk. Inspect the final diff for accidental scope, broken contracts, stale comments, secrets, and unnecessary complexity. Resolve failures and rerun affected checks; if a check cannot be run, state that limitation rather than claiming verification.
  1. 确定契约。 明确所要求的行为、约束、受影响的代码以及相关项目惯例。对于用途或要求尚不明确的行为，不要进行简化。
  2. 测试每一部分是否必要。 按以下顺序询问：
    • 当前需求是否需要它？
    • 项目中是否已经提供它？
    • 语言、标准库、平台或现有依赖是否已经提供它？
    • 如果没有，什么是最小的明确本地解决方案？
  3. 进行最小且连贯的变更。 在不破坏契约的前提下，删除、内联或复用代码。避免推测性的扩展点、包装层、依赖、配置和回退路径。保持代码符合惯例且易于理解；更少的代码行数并不自动意味着更简单。
  4. 根据风险进行审查。 对于没有引入重要新逻辑或概念的小型局部变更，直接审查 diff。对于大量逻辑、生成代码，或新增抽象、依赖、配置和间接层的变更，如果可以安排单独的审查者，应让两位具有全新上下文的审查者参与：
    • 质疑必要性： 在当前需求尚未证明其必要性之前，假定每项新增内容都是不必要的。查找可以删除、内联、复用或通过现有项目、语言、平台或依赖功能替换的代码。报告具体发现，以及每项新增内容未能证明合理性的对应需求；不要提出新功能或新架构。
    • 以维护者视角审查： 在不依赖未记录于仓库中的实现理由的情况下，检查仓库和 diff。标记隐藏假设、用途不明确或异常复杂之处。报告具体发现。
    将审查者视为批评者；任何被接受的变更都应由你亲自实施并验证。如果没有单独的审查者可用，请自行执行上述两种审查，并将它们视为两个不同的审查过程，不要描述为相互独立的审查。
  5. 验证结果。 运行能够检测回归的最小范围现有检查，然后根据风险扩大检查范围。检查最终 diff，确认不存在意外的范围扩张、契约破坏、过时注释、密钥和不必要的复杂性。解决失败问题并重新运行受影响的检查；如果无法执行某项检查，应说明该限制，而不是声称已经完成验证。

Preserve

保留

Do not simplify away explicitly requested behavior, validation at trust boundaries, security controls, meaningful error handling, accessibility, project conventions, compatibility required by the current contract, or tests that materially protect behavior.
不要通过简化而移除明确要求的行为、信任边界处的验证、安全控制、有意义的错误处理、无障碍支持、项目惯例、当前契约要求的兼容性，或能够实质保护行为的测试。