Back to Details

simplify-code-solution

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Simplify Code Solution

简化代码方案

Find the simplest complete production design for a code problem.
为代码问题找到最简单的完整生产级设计方案。

Choose the working mode

选择工作模式

Infer the mode from what the user wants changed and any authorization already given:
  • Recommend: For an assessment, proposal review, or question such as "Could this be simpler?", explain the simpler path, tradeoffs, and validation needed. A question about simplification does not authorize file edits. A request to revise a proposal applies to that proposal, not the production code it describes.
  • Implement: When the user asks to simplify or refactor the code, or to apply a recommended change, make the scoped change and verify it. Honor prior authorization without requesting approval again merely because the analysis produced a recommendation.
When no implementation intent is established, stay in recommendation mode. A preferred design or favorable reaction alone does not authorize implementation. Ask only when a missing decision would materially change the solution or its scope.
根据用户的修改诉求以及已授予的权限推断工作模式：
  • 建议模式： 适用于评估、方案评审或“这个能不能更简单？”这类问题，需说明更简化的路径、权衡取舍以及所需验证。仅询问如何简化并不等同于授权修改文件。修订方案的请求仅适用于方案本身，不涉及方案描述的生产代码。
  • 实施模式： 当用户要求简化或重构代码，或应用某项推荐变更时，在限定范围内完成修改并验证。若已获得前置授权，不要仅仅因为分析过程中产出了建议就再次请求批准。
若未明确实施意图，保持建议模式。仅用户偏好某种设计或给出正面反馈，并不构成实施授权。只有当缺失的决策会实质性改变解决方案或其范围时，才需要向用户询问。

Goal

目标

Prefer direct, boring changes that meet every real requirement. Simpler is valid only when it preserves behavior, keeps responsibilities coherent, fits sound existing patterns, and can be verified. Fewer files, functions, or modules do not by themselves make a solution simpler.
优先选择直接、朴素的变更，满足所有真实需求。简化的有效性前提是：保留原有行为、保持职责连贯、符合现有可靠模式、且可验证。文件、函数或模块数量少，并不代表方案更简单。

Success Criteria

成功标准

  • The actual problem and success criteria are explicit.
  • Requirements are separated from assumptions and nice-to-haves.
  • Relevant code has been inspected before judging the approach.
  • Essential complexity that represents real domain, durability, recovery, or operational requirements is identified and preserved.
  • Every proposed generic abstraction, refactor, dependency, or state change is justified by a real requirement or by current complexity it meaningfully hides from callers.
  • The recommendation or implementation is the simplest production-quality change that preserves behavior and fits sound local patterns.
  • Tradeoffs and validation are stated.
  • 实际问题与成功标准明确清晰。
  • 需求与假设、可选需求相互区分。
  • 判断方案前已检查过相关代码。
  • 代表真实领域、持久性、恢复能力或运维需求的本质复杂度已被识别并保留。
  • 每一项拟议的通用抽象、重构、依赖或状态变更，都有真实需求支撑，或能有效对调用方隐藏现有复杂度。
  • 建议或实施的变更是保留行为、符合本地可靠模式的最简单生产级变更。
  • 明确说明权衡取舍与验证方式。

Constraints

约束条件

  • Reuse existing paths, helpers, types, components, and APIs when they can absorb the behavior without gaining an unrelated responsibility.
  • Avoid rewrites for localized bugs, state machines for simple state, generic frameworks for one caller, speculative migrations, unnecessary dependencies, wide API changes for internal convenience, and tests that only mirror implementation.
  • Compare total lifecycle complexity, not merely initial implementation size. Do not reject justified infrastructure, durable queues, explicit state, or domain distinctions simply because they add code. Complexity is removable only when requirements, operational guarantees, and failure modes remain covered.
  • Do not recommend removing a mechanism until its consumers, operational role, failure behavior, and replacement path are understood. Require a concrete cost and a behavior-preserving alternative.
  • When replacing an interface, find everything that uses it, including tests. Update tests to use the replacement while still checking the same behavior. Do not keep an old production API just to leave tests unchanged. Keep it when callers or rollout requirements still need it, and state when any temporary adapter can be removed.
  • In implementation mode, establish relevant test results before a behavior-preserving refactor and retain the same meaningful cases afterward. Change an expectation only for an authorized contract change or a demonstrated error in the test. Do not simplify fixtures, mocks, or selection in ways that hide a real failure. If the work includes a behavioral fix, observe a practical regression failing before fixing it; explain any unavailable evidence. Preserve a valid failing regression when an unresolved decision or prerequisite blocks completion.
  • 当现有路径、辅助函数、类型、组件和API可承载对应行为且不会新增无关职责时，优先复用这些现有资源。
  • 避免以下行为：为局部bug重写代码、为简单状态引入状态机、为单个调用方搭建通用框架、推测性迁移、引入不必要的依赖、为了内部便利大幅修改API、编写仅镜像实现逻辑的测试。
  • 要对比全生命周期复杂度，而非仅看初始实现的代码量。不要仅仅因为会增加代码就否定合理的基础设施、持久化队列、显式状态或领域划分。只有在需求、运维保障和故障模式都仍被覆盖的前提下，才能移除复杂度。
  • 在理解某个机制的所有消费方、运维作用、故障表现和替代方案之前，不要建议移除该机制。需有明确的成本分析和保留行为的替代方案。
  • 替换接口时，要找出所有使用该接口的代码，包括测试。更新测试以使用新的替代方案，同时仍校验相同的行为。不要为了不改动测试就保留旧的生产API。如果调用方或上线需求仍需要旧API则保留，并说明临时适配器的可移除时机。
  • 在实施模式下，进行保留行为的重构前先确认相关测试结果，重构后保留相同的有效测试用例。仅当有授权的契约变更或测试本身存在已证实的错误时，才可修改测试预期。不要以简化fixture、mock或筛选逻辑的方式掩盖真实故障。如果工作包含行为修复，需在修复前先复现可观测的回归测试失败；若无法获取相关证据需作出说明。当未解决的决策或前置条件阻碍完成时，保留有效的失败回归测试用例。

Context Budget

上下文预算

Inspect the minimum relevant code needed to understand the current path, contract, local patterns, and risk. Continue reading only when a requirement, behavior boundary, local pattern, or validation path is unclear.
仅检查理解当前实现路径、契约、本地模式和风险所需的最少相关代码。只有当需求、行为边界、本地模式或验证路径不明确时，才继续阅读更多代码。

Simplicity Checks

简化检查项

  • Can one existing code path absorb the behavior while remaining coherent, or would a focused module reduce the caller's required context?
  • Can current contracts and data shapes remain unchanged?
  • Is genericity serving demonstrated variation? Separately, does a responsibility extraction hide meaningful existing complexity even if it has one caller?
  • Would removing a wrapper make the code easier to follow, or make callers handle rules, cleanup, or compatibility themselves? Read its callers before recommending removal.
  • What required behavior or operational guarantee does the apparent complexity encode?
  • Would removing local complexity move more complexity, risk, or manual work downstream?
  • Can the edge case be handled by its natural owner without making that owner responsible for an independent workflow or policy?
  • Will a maintainer understand the changed path without holding unrelated responsibilities in mind?
  • Does validation cover behavior users or callers rely on?
  • 现有某条代码路径能否在保持职责连贯的前提下承载该行为？或者一个聚焦的模块能否减少调用方所需的上下文？
  • 当前的契约和数据结构能否保持不变？
  • 通用性是否服务于已证实的变化需求？另外，即使只有一个调用方，职责抽离是否隐藏了有意义的现有复杂度？
  • 移除某个包装层会让代码更易理解，还是会让调用方自行处理规则、清理或兼容性问题？建议移除前先查看其所有调用方。
  • 表面上的复杂度承载了哪些必需的行为或运维保障？
  • 移除局部复杂度是否会将更多复杂度、风险或人工工作转移到下游？
  • 边界情况能否由其天然归属方处理，而不会让该归属方承担独立工作流或策略的职责？
  • 维护人员无需考虑无关职责就能理解修改后的路径吗？
  • 验证是否覆盖了用户或调用方依赖的行为？

Output

输出

For recommendations:
  • Real requirement
  • Complexity to preserve
  • Assumptions to drop
  • Simpler path
  • Tradeoffs
  • Validation
Use only the headings that add decision value. For implementation, report what changed, why it reduces complexity, the verification performed, and any material limitation.
建议模式的输出需包含：
  • 真实需求
  • 需保留的复杂度
  • 可舍弃的假设
  • 更简化的路径
  • 权衡取舍
  • 验证方式
仅使用能提供决策价值的标题。实施模式下，需报告变更内容、简化复杂度的原因、已执行的验证工作以及任何实质性限制。

Stop Rules

停止规则

When you find a way to simplify the code, check whether the same problem occurs elsewhere in the requested scope. Include confirmed cases in the recommendation or authorized cleanup before calling the work complete. Report any known cases outside that scope separately.
In recommendation mode, finish when the simpler production-quality path and its validation plan are clear. In implementation mode, continue through the authorized change and verification; do not stop at a proposal. If a genuine blocker prevents completion, state the missing decision or evidence and what remains unfinished.
找到代码简化方法后，检查请求范围内是否还有其他地方存在相同问题。在宣布工作完成前，将已确认的案例纳入建议或授权的清理工作中。范围外的已知案例需单独报告。
建议模式下，当更简化的生产级路径及其验证计划清晰时即可结束。实施模式下，需完成授权的变更和验证，不要停留在方案阶段。如果存在真实阻碍导致无法完成，说明缺失的决策或证据，以及未完成的工作内容。