360 Secure SkillHub
360 安全技能中心

Refactoring

这是一套六阶段代码深度重构工作流,核心是在保障外部行为不变的前提下优化代码结构。适用于代码耦合度高、需为新功能铺路、需无用户可见变化地偿还技术债等场景。流程含明确目标范围、搭建安全验证机制、规划小步增量、提交可审查修改、验证行为一致性、文档跟进等环节,通过小步提交、测试保障降低重构风险。

mike47512
mike47512
热度 64.15
最近更新 2026-05-11 17:36:03
分类:开发依赖:纯提示词应用场景:代码审查 / 工作流

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add refactoring
Metadata
name
refactoring
description
Deep refactoring workflow—characterization tests, incremental steps, behavior preservation, design direction, and verification. Use when improving structure without changing external behavior, or paying down tech debt safely.

Refactoring (Deep Workflow)

Refactoring changes structure, not behavior. Safety comes from small steps, fast feedback, and verification (tests, golden outputs, or controlled manual checks).

When to Offer This Workflow

Trigger conditions:

  • Code is hard to change; duplication; unclear module boundaries
  • Need to prepare an area for a new feature without mixing behavior change
  • Paying down tech debt with management expecting “no user-visible change”

Initial offer:

Use six stages: (1) clarify goal & scope, (2) establish safety net, (3) plan increments, (4) execute with reviewable commits, (5) verify behavior, (6) document & follow-ups). Confirm test coverage and release pressure.


Stage 1: Clarify Goal & Scope

Goal: Why refactor now—reduce coupling, enable feature X, remove dead code, improve naming.

Exit condition: Explicit non-goals (no feature changes in this effort unless separately scoped).


Stage 2: Establish Safety Net

Goal: Prefer characterization tests for legacy; golden outputs for data pipelines; use snapshot tests sparingly.

If tests are weak

  • Approval tests, short exploratory scripts, or pair review with domain expert

Stage 3: Plan Increments

Goal: Small commits, each leaving the codebase working (not necessarily perfect).

Practices

  • Move code, then change behavior in separate steps (Fowler-style when helpful)
  • Separate mechanical renames from logic edits for reviewability

Stage 4: Execute With Reviewable Commits

Goal: Each PR/commit tells a story; avoid thousand-line “cleanup” dumps.


Stage 5: Verify Behavior

Goal: CI green; compare outputs for batch jobs; manual smoke on critical paths when needed.


Stage 6: Document & Follow-Ups

Goal: ADR or short module README for new boundaries; tickets for remaining debt accepted consciously.


Final Review Checklist

  • Scope and non-goals explicit
  • Safety net matches risk
  • Incremental, reviewable steps
  • Behavior verified
  • Follow-up debt tracked

Tips for Effective Guidance

  • Keep refactor commits separate from feature commits when possible.
  • If behavior must change, it is not “pure refactoring”—plan as a migration with communication.
  • Under hotfix pressure, minimize refactor scope or defer.

Handling Deviations

  • Strangler refactors: maintain adapters at boundaries until cutover is complete.