Back to Details

simplify

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Simplify

代码精简

Produce the smallest clear implementation that fully satisfies the required behavior. Minimize concepts and moving parts, not line count.
产出能完全满足所需功能的最精简清晰的实现。尽量减少概念和可变动部分，而非单纯减少代码行数。

Cadence

实施节奏

  • During construction, apply the priorities locally while discovering behavior. Allow clearly temporary instrumentation or scaffolding when it accelerates learning.
  • At convergence, once a logical behavior slice passes, simplify that slice, remove superseded attempts, and rerun focused validation.
  • Before handoff or merge, compare the full branch with its merge base and reconcile code, tests, comments, documentation, configuration, and relevant history.
  • 在开发构建阶段，探索功能的同时局部应用优先级规则。若临时工具或脚手架能加快学习进度，可允许其存在。
  • 当功能收敛时，一旦某个逻辑功能模块验证通过，就对该模块进行精简，移除已被替代的尝试方案，并重新运行针对性验证。
  • 在移交或合并前，将完整分支与其merge base进行对比，协调代码、测试、注释、文档、配置及相关历史记录。

Workflow

工作流程

  1. Identify the required behavior, invariants, constraints, and non-goals.
  2. Inspect the relevant diff and separate it into logical concepts. For a final branch audit, compare the full branch with its merge base and check history for superseded attempts when relevant.
  3. Inspect the existing owners, sources of truth, common path, and decision points before adding anything.
  4. Choose the design with the fewest necessary concepts and the least work at runtime.
  5. When changes are requested, implement directly and reuse existing mechanisms where they fit.
  6. Validate behavior with checks proportional to the risk.
  7. Review the final code, tests, names, comments, documentation, configuration, and relevant history for anything that no longer earns its complexity.
  1. 明确所需功能、不变量、约束条件及非目标内容。
  2. 检查相关代码差异，将其划分为不同的逻辑概念。在最终分支审核时，将完整分支与其merge base对比，并在必要时检查历史记录中已被替代的尝试方案。
  3. 在添加任何内容前，检查现有代码的负责人、可信数据源、通用路径及决策点。
  4. 选择所需概念最少、运行时开销最低的设计方案。
  5. 当接到变更请求时，直接实现，并在合适的地方复用现有机制。
  6. 根据风险程度选择相应的检查方式验证功能。
  7. 审查最终的代码、测试、命名、注释、文档、配置及相关历史记录，移除任何不再需要的复杂内容。

Simplification Priorities

精简优先级

  • Prefer deletion, reuse, or a direct change over a new abstraction.
  • Keep one source of truth; avoid mirrored state, overlapping guards, duplicate registries, and compensating mechanisms.
  • Avoid speculative fallbacks, compatibility paths, configuration, parameters, and generic APIs.
  • Inline one-use helpers when doing so makes the policy clearer at its decision point.
  • Prefer straightforward positive control flow over early-return chains or empty branches.
  • On hot paths, minimize allocations, callback recreation, subscriptions, renders, passes, I/O, and native work.
  • For prose, remove repetition and keep the shortest wording or example that remains self-sufficient.
  • 优先选择删除、复用或直接修改，而非创建新的抽象层。
  • 保持单一可信数据源；避免镜像状态、重叠防护逻辑、重复注册及补偿机制。
  • 避免推测性回退、兼容路径、配置项、参数及通用API。
  • 当内联一次性辅助函数能让决策点的逻辑更清晰时，优先内联。
  • 优先选择直接正向的控制流，而非提前返回链或空分支。
  • 在hot paths上，尽量减少内存分配、回调重建、订阅、渲染、遍历、I/O及原生操作。
  • 对于文档内容，移除重复表述，保留能完整表意的最短措辞或示例。

Existing Work

现有代码处理

Establish a passing baseline before simplifying working code. Test one questionable concept at a time, rerun the relevant validation, and restore it if behavior or meaningful coverage weakens. Do not restructure several accumulated fix attempts before establishing which changes are causally necessary.
When duplicate or ineffective regression coverage is suspected, deliberately break the claimed invariant and confirm the remaining test fails. Passing tests alone do not prove that every test or implementation concept is necessary.
Do not rewrite branch history without authorization.
在精简可运行代码前，先建立一个能通过验证的基准版本。每次仅测试一个存疑的概念，重新运行相关验证，若功能或有效测试覆盖率下降则恢复原状。在确定哪些变更为必要因果变更前，不要重构多个累积的修复尝试。
当怀疑存在重复或无效的回归测试覆盖时，故意破坏声称的不变量，确认剩余测试会失败。仅测试通过并不足以证明每个测试或实现概念都是必要的。
未经授权不得重写分支历史。

Performance Changes

性能优化变更

Name the exact common-path work being removed: allocations, scans, mounts, renders, subscriptions, I/O, or native calls. Control-flow evidence plus regression tests can justify removing work that is structurally unused. Require a benchmark, profile, or repeated repro when an optimization changes semantics or introduces a tradeoff. Do not add complexity for theoretical gains.
明确指出要移除的通用路径操作：内存分配、扫描、挂载、渲染、订阅、I/O或原生调用。控制流证据加上回归测试可作为移除结构上未使用操作的依据。当优化变更语义或引入权衡时，需要提供基准测试、性能分析或可重复的复现案例。不要为了理论上的收益而增加复杂度。

Guardrails

约束规则

  • Preserve correctness, required behavior, type safety, distinct regression coverage, and useful clarity.
  • Do not replace clear code with compressed or clever code merely to reduce lines.
  • Make scoped, behavior-preserving improvements directly. If the better design requires a sweeping API or architecture change, explain and suggest it instead of expanding the task without approval.
  • Leave unrelated and user-authored changes untouched.
Stop when every remaining concept supports a requirement, invariant, clarity, or measured performance need. Report only material simplifications, validation, and unresolved opportunities.
  • 确保正确性、所需功能、类型安全、独特的回归测试覆盖及有用的清晰度。
  • 不要仅仅为了减少行数而用压缩或炫技的代码替代清晰的代码。
  • 直接进行有范围限制、不改变功能的改进。若更好的设计需要全面的API或架构变更，应先说明并提出建议，而非未经批准就扩大任务范围。
  • 不修改无关内容及用户编写的变更。
当所有剩余概念都服务于需求、不变量、清晰度或经测量的性能需求时停止操作。仅报告重要的精简内容、验证结果及未解决的优化机会。