/refactor

name: refactor
description: "Expert code refactoring based on Martin Fowler's catalog — improve maintainability without changing behavior. Covers code smells, composing methods, moving features, organizing data, simplifying conditionals, method calls, and generalization. Triggers on: refactor, 重构, clean up, improve code, code smell, extract method, rename, simplify."
user-invocable: true

Refactor — Expert Code Restructuring

Surgical code refactoring based on Martin Fowler's <Refactoring> (2nd Edition) catalog. Improve structure, readability, and maintainability without changing external behavior. Gradual evolution, not revolution.

---

When to Use

This skill activates when:

• Code is hard to understand or maintain
• Functions/classes have grown too large
• Code smells are detected
• Adding features is difficult due to poor structure
• User explicitly requests refactoring, cleanup, or improvement
• User says: refactor, 重构, clean up, improve code, code smell, extract method, rename, simplify

---

The Golden Rules

These five rules are non-negotiable. Violating any of them turns refactoring into reckless editing.

1. Behavior is Preserved

Only *how* the code works changes, never *what* it does. If tests existed before, they must pass after. If the refactoring introduces a behavioral change, it's not refactoring — it's rewriting.

2. Small Steps

Each change should be the smallest possible transformation that compiles and passes tests. If a step breaks, you know exactly which change caused it. Refactoring is a series of tiny, safe transformations, not one big rewrite.

3. Version Control is Your Friend

Commit before starting. Commit after each successful step. This gives you infinite undo. Branch from a clean state so you can abandon the refactoring without consequences.

4. Tests are Essential

"Without tests, you're not refactoring — you're just editing." If tests don't exist for the target code, write characterization tests first. These tests capture the current behavior so you can detect regressions.

5. One Thing at a Time

Never mix refactoring with feature changes. Never refactor two unrelated things simultaneously. Each commit should contain exactly one refactoring operation.

---

When NOT to Refactor

| Scenario | Action | |----------|--------| | Code works and won't change again | Leave it alone | | Critical production path with no tests | Write characterization tests first | | Under tight deadline pressure | Document the smell, refactor later | | No clear purpose or benefit | Don't refactor for refactoring's sake | | Code is fundamentally wrong | This is a rewrite, not a refactoring |

---

Code Smells Catalog

Based on Fowler's taxonomy. Before refactoring, identify which smell is present.

Bloaters

| Smell | Description | Primary Refactoring | |-------|-------------|-------------------| | **Long Method** | Method > 10-15 lines, doing multiple things | Extract Method, Replace Temp with Query | | **Large Class** | Class with too many fields/methods (God Object) | Extract Class, Extract Subclass | | **Primitive Obsession** | Using primitives instead of small objects | Replace Data Value with Object, Replace Type Code with Class | | **Long Parameter List** | Method with > 3-4 parameters | Introduce Parameter Object, Preserve Whole Object | | **Data Clumps** | Same group of data appearing together | Extract Class, Introduce Parameter Object |

Object-Orientation Abusers

| Smell | Description | Primary Refactoring | |-------|-------------|-------------------| | **Switch Statements** | Repeated switch/if-else on type codes | Replace Conditional with Polymorphism, Replace Type Code with Subclasses | | **Temporary Field** | Field only set in certain circumstances | Extract Class, Introduce Null Object | | **Refused Bequest** | Subclass doesn't use inherited members | Replace Inheritance with Delegation, Push Down Method/Field | | **Alternative Classes with Different Interfaces** | Classes doing similar things with different names | Rename Method, Move Method, Extract Superclass |

Change Preventers

| Smell | Description | Primary Refactoring | |-------|-------------|-------------------| | **Divergent Change** | One class changed for different reasons | Extract Class | | **Shotgun Surgery** | One change requires many small changes across classes | Move Method, Move Field, Inline Class | | **Parallel Inheritance Hierarchies** | Adding a subclass to one hierarchy forces adding to another | Move Method, Move Field |

Dispensables

| Smell | Description | Primary Refactoring | |-------|-------------|-------------------| | **Comments** | Comments explaining what code does (not why) | Extract Method, Rename Variable, Introduce Assertion | | **Duplicate Code** | Same code structure in multiple places | Extract Method, Pull Up Method, Form Template Method | | **Lazy Class** | Class doing too little to justify existence | Inline Class, Collapse Hierarchy | | **Data Class** | Class with only fields and getters/setters | Move Method, Encapsulate Field, Encapsulate Collection | | **Dead Code** | Unused code, imports, commented-out blocks | Delete it (git history has it) | | **Speculative Generality** | Code built for "someday" that never came | Inline Class, Collapse Hierarchy, Remove Parameter |

Couplers

| Smell | Description | Primary Refactoring | |-------|-------------|-------------------| | **Feature Envy** | Method uses another class's data more than its own | Move Method, Extract Method + Move Method | | **Inappropriate Intimacy** | Classes know too much about each other's internals | Move Method, Move Field, Replace Delegation with Hidden Delegate | | **Message Chains** | `a.getB().getC().getD().doSomething()` | Hide Delegate, Extract Method | | **Middle Man** | Class delegates everything to another class | Remove Middle Man, Inline Method | | **Incomplete Library Class** | Library missing methods you need | Introduce