Back to Details

kf-refactor-code

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Refactor Code

代码重构

Make a focused structural improvement with behavior preservation as the default.
以保留行为为默认原则，针对性地进行代码结构优化。

Workflow

工作流程

  1. Establish current observable behavior, compatibility constraints, and the specific structural problem to solve.
  2. Inspect repository patterns and define a narrow refactor boundary. Do not expand scope merely because nearby code is imperfect.
  3. Identify available verification before editing: focused tests, types, lint, builds, snapshots, or stable runtime checks.
  4. Plan reversible, incremental changes that keep review and failure diagnosis straightforward.
  5. Refactor consistently with the repository, favoring simplification over new architectural ceremony.
  6. Run meaningful behavior-preservation checks after each risky step and at the end.
  7. Inspect the final diff for accidental behavior changes, compatibility breaks, unrelated formatting, and unnecessary abstractions.
  1. 明确当前可观测行为、兼容性约束以及需要解决的具体结构问题。
  2. 检查代码库的模式，定义狭窄的重构边界。切勿因附近代码存在缺陷就扩大范围。
  3. 在开始编辑前，确定可用的验证手段：针对性测试、类型检查、代码扫描、构建、快照或稳定的运行时检查。
  4. 规划可回滚的增量式变更，确保代码评审和故障诊断过程简单清晰。
  5. 重构时需与代码库保持一致风格，优先选择简化而非引入新的架构仪式。
  6. 在每一个有风险的步骤结束后以及最终阶段，运行有效的行为保留检查。
  7. 检查最终的代码差异，确认是否存在意外的行为变更、兼容性破坏、无关的格式调整以及不必要的抽象。

Constraints

约束条件

  • A refactor needs a concrete reason: duplicated logic, unclear boundaries, excessive complexity, poor testability, or a repeated error-prone pattern.
  • Do not mix feature work or unrelated defect fixes into the refactor.
  • Preserve APIs, data formats, ordering, side effects, and error behavior unless the user explicitly requests a compatibility change.
  • Do not add dependencies or abstraction layers solely for stylistic preference.
  • Report validation limits and any behavior that could not be proven equivalent.
  • 重构必须有明确的理由：逻辑重复、边界模糊、过度复杂、可测试性差或存在反复出现的易出错模式。
  • 请勿在重构中混入功能开发或无关的缺陷修复工作。
  • 除非用户明确要求变更兼容性，否则需保留API、数据格式、执行顺序、副作用和错误行为。
  • 请勿仅因风格偏好就添加依赖或抽象层。
  • 需报告验证的局限性以及任何无法证明等价的行为。