refactor

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Refactor Workflow

重构工作流程

Restructure code without changing behavior. Tests are your safety net.

在不改变代码行为的前提下重构代码。测试是你的安全保障。

1. Sync main

1. 同步主分支

git checkout main && git pull

git checkout main && git pull

2. Verify baseline

2. 验证基准状态

Run full test suite — all tests must pass before you touch anything
If tests fail, fix them first (that's a
```
/fix-bug
```
, not a refactor)

运行完整测试套件——在修改任何代码之前，所有测试必须全部通过
如果测试失败，先修复问题（这属于修复bug，而非重构）

3. Create worktree and branch

3. 创建工作树与分支

git worktree add .claude/worktrees/refactor-<name> -b refactor/<description>
cd .claude/worktrees/refactor-<name>

All work happens in the worktree — main stays clean.

git worktree add .claude/worktrees/refactor-<name> -b refactor/<description>
cd .claude/worktrees/refactor-<name>

所有工作都在工作树中进行——主分支保持干净。

4. Plan the refactor

4. 规划重构方案

Identify what to change and why (readability, performance, deduplication, etc.)
List the files that will be affected
Present the plan to the user for approval

确定要修改的内容及原因（可读性、性能、代码去重等）
列出会受影响的文件
将方案提交给用户审批

5. Refactor incrementally

5. 增量式重构

Make one logical change at a time
Run tests after each change — they must stay green
If a test breaks, your refactor changed behavior — revert and rethink
Commit at each stable point

每次只进行一个逻辑单元的修改
每次修改后运行测试——测试必须保持全部通过
如果测试失败，说明你的重构改变了代码行为——回退修改并重新思考
在每个稳定节点提交代码

6. Verify

6. 验证重构结果

Run full test suite — same pass count as baseline
Verify no behavior change: same inputs produce same outputs
Check no dead code left behind

运行完整测试套件——通过数量与基准状态一致
验证代码行为未改变：相同输入产生相同输出
检查是否遗留无用代码

7. Code Review

7. 代码评审

Self-review via
```
git diff main...HEAD
```
Or dispatch a code-review subagent if available

通过
```
git diff main...HEAD
```
进行自我评审
如果有可用的代码评审子Agent，可调用其进行评审

8. Create PR

8. 创建拉取请求（PR）

Commit with message explaining what was refactored and why
Push and create PR via
```
gh pr create
```
Wait for CI/CD checks to complete:
```
gh pr checks <number> --watch
```
If checks fail, fix the issues and push again — do not notify the user until all checks are green
Once all checks pass, return the PR URL and ask the user to review
DO NOT merge — wait for explicit approval

提交代码时附上说明，解释重构的内容及原因
推送代码并通过
```
gh pr create
```
创建PR
等待CI/CD检查完成：
```
gh pr checks <number> --watch
```
如果检查失败，修复问题后重新推送——在所有检查通过前不要通知用户
所有检查通过后，返回PR链接并请求用户评审
请勿合并——等待用户明确批准

9. Merge (only when approved)

9. 合并（仅在获得批准后）

```
gh pr merge <number> --merge
```

Clean up worktree:

cd <project-root> && git worktree remove .claude/worktrees/refactor-<name>

git checkout main && git pull && git branch -d refactor/<description>

```
gh pr merge <number> --merge
```

清理工作树：

cd <project-root> && git worktree remove .claude/worktrees/refactor-<name>

git checkout main && git pull && git branch -d refactor/<description>

Rules

规则

Tests must pass before AND after — the whole point of refactoring
No behavior changes — if you need to change behavior, that's a feature or bugfix
Never merge without explicit approval
Never push directly to main
Incremental commits — don't lump everything into one giant diff

重构前后测试必须全部通过——这是重构的核心意义
不得改变代码行为——如果需要改变行为，那属于功能开发或bug修复
未经明确批准绝不要合并
绝不要直接推送到主分支
增量式提交——不要将所有修改打包成一个大型差异文件

Quality Checklist

质量检查清单

Before every PR, answer each item and present as a markdown table:

#	Check	Answer
1	What changed — what was refactored and why	[brief]
2	Behavior preserved — does the code behave identically?	[yes/no + evidence]
3	Single source of truth — no duplicate data paths or redundant caches introduced?	[yes/no + evidence]
4	Test regression — do all existing tests pass? Same count as baseline?	[pass count / fail count]
5	Reuse — did you reuse existing patterns/functions, or reinvent something?	[yes/no + evidence]

If any answer is unsatisfactory, fix it before creating the PR
Be honest — don't beautify answers

创建PR前，逐一回答以下问题并以Markdown表格形式呈现：

#	检查项	答案
1	修改内容——重构了什么，原因是什么	[简要说明]
2	行为一致性——代码行为是否完全一致？	[是/否 + 证据]
3	单一数据源——是否引入了重复的数据路径或冗余缓存？	[是/否 + 证据]
4	测试回归——所有现有测试是否通过？通过数量与基准状态一致？	[通过数 / 失败数]
5	代码复用——是否复用了现有模式/函数，还是重新实现了功能？	[是/否 + 证据]

如果任何答案不符合要求，在创建PR前修复问题
请如实回答——不要美化答案