Refactor — Expert Code Restructuring

When to Use

• 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

1. Behavior is Preserved

2. Small Steps

3. Version Control is Your Friend

4. Tests are Essential

5. One Thing at a Time

When NOT to Refactor

Code Smells Catalog

Bloaters

Object-Orientation Abusers

Change Preventers

Dispensables

Couplers

a.getB().getC().getD().doSomething()

Refactoring Techniques Catalog

Composing Methods

Extract Method

1. Create a new method named after what the fragment does (not how)
2. Copy the extracted code into the new method
3. Identify local variables: read-only become parameters, modified become return values
4. Pass parameters and handle return values
5. Replace the original fragment with a call to the new method
6. Test

void printOwing() {
    printBanner();
    // Print details
    System.out.println("name: " + _name);
    System.out.println("amount: " + getOutstanding());
}

void printOwing() {
    printBanner();
    printDetails(getOutstanding());
}

void printDetails(double outstanding) {
    System.out.println("name: " + _name);
    System.out.println("amount: " + outstanding);
}

Inline Method

1. Check the method is not polymorphic (no subclasses override it)
2. Find all callers
3. Replace each call with the method body
4. Delete the method definition
5. Test

Extract Variable

if (platform.toUpperCase().indexOf("MAC") > -1 &&
    browser.toUpperCase().indexOf("IE") > -1 &&
    wasInitialized() && resize > 0) {
    // ...
}

final boolean isMacOs = platform.toUpperCase().indexOf("MAC") > -1;
final boolean isIEBrowser = browser.toUpperCase().indexOf("IE") > -1;
final boolean wasResized = resize > 0;
if (isMacOs && isIEBrowser && wasInitialized() && wasResized) {
    // ...
}

Inline Temp

Replace Temp with Query

Split Temporary Variable

Remove Assignments to Parameters

Replace Method with Method Object

Substitute Algorithm

Moving Features Between Objects

Move Method

1. Check all features used by the method on its current class
2. Check for polymorphism (subclass/superclass methods)
3. Create the method on the target class, adapting as needed
4. Reference the target object from the source
5. Turn the source method into a delegating method, or remove it
6. Test

Move Field

Extract Class

Inline Class

Hide Delegate

manager = person.getDepartment().getManager()

manager = person.getManager()

Remove Middle Man

Introduce Foreign Method

Introduce Local Extension

Organizing Data

Self Encapsulate Field

Replace Data Value with Object

class Order {
    private String customer;  // Just a string
}

class Order {
    private Customer customer;  // Rich object with name, address, credit rating
}

Change Value to Reference

Change Reference to Value

Replace Array with Object

String[] row = new String[3]

Replace Magic Number with Symbolic Constant

Encapsulate Field

Encapsulate Collection

Replace Type Code with Class

Replace Type Code with Subclasses

Replace Type Code with State/Strategy

Replace Subclass with Fields

Simplifying Conditional Expressions

Decompose Conditional

if (date.before(SUMMER_START) || date.after(SUMMER_END)) {
    charge = quantity * _winterRate + _winterServiceCharge;
} else {
    charge = quantity * _summerRate;
}

if (isSummer(date)) {
    charge = summerCharge(quantity);
} else {
    charge = winterCharge(quantity);
}

Consolidate Conditional Expression

Consolidate Duplicate Conditional Fragments

Remove Control Flag

Replace Nested Conditional with Guard Clauses

double getPayAmount() {
    double result;
    if (_isDead) {
        result = deadAmount();
    } else {
        if (_isSeparated) {
            result = separatedAmount();
        } else {
            if (_isRetired) {
                result = retiredAmount();
            } else {
                result = normalPayAmount();
            }
        }
    }
    return result;
}

double getPayAmount() {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();
    return normalPayAmount();
}

Replace Conditional with Polymorphism

Introduce Null Object

Introduce Assertion

Making Method Calls Simpler

Rename Method

Add Parameter / Remove Parameter

Separate Query from Modifier

Parameterize Method

Replace Parameter with Explicit Methods

Preserve Whole Object

Replace Parameter with Method

Introduce Parameter Object

Remove Setting Method

Hide Method

Replace Constructor with Factory Method

Replace Error Code with Exception

Replace Exception with Test

Dealing with Generalization

Pull Up Field/Method/Constructor Body

Push Down Method/Field

Extract Subclass

Extract Superclass

Extract Interface

Collapse Hierarchy

Form Template Method

Replace Inheritance with Delegation

Replace Delegation with Inheritance

The Refactoring Process

Phase 1: Prepare

1. Write characterization tests if they don't exist. These capture current behavior — they don't need to be elegant, just comprehensive enough to catch regressions.
2. Commit current state. Start from a clean working tree.
3. Create a branch for the refactoring. Keep it separate from feature work.

Phase 2: Identify

1. Smell the code. Use the smell catalog above to classify what's wrong.
2. Understand the code. Read it thoroughly. You must understand what it does before changing it.
3. Choose the right refactoring. Pick from the technique catalog. Know what the result looks like before you start.

Phase 3: Refactor (Small Steps)

1. Make one small change. One refactoring technique at a time.
2. Compile. The code should compile after every change.
3. Run tests. All tests must pass. If they don't, you've changed behavior.
4. Commit. Create a commit with a message like

   refactor: extract validateEmail method

   .

Phase 4: Verify

1. All tests pass. Non-negotiable.
2. Manual check. Briefly run the application or review the diff for unintended changes.
3. Performance. Ensure no performance regression. Simple refactorings rarely cause them, but check.

Phase 5: Clean Up

1. Remove stale comments. If a refactoring made a comment obvious, delete the comment.
2. Check for dead code. After refactorings, unused code may emerge.
3. Final commit. Summarize the refactoring sequence.

Refactoring Checklist

Code Quality

• Functions are small (< 20 lines preferred, < 50 lines max)
• Each function does one thing (single responsibility)
• No duplicated code (DRY)
• Names describe what, not how
• No magic numbers or strings
• Dead code removed

Structure

• Related code is grouped together
• Module boundaries are clear
• Dependencies flow in one direction (no cycles)
• No circular dependencies

Conditionals

• Guard clauses replace deep nesting
• Complex conditions extracted to named methods
• Polymorphism replaces type-switching conditionals
• Null Object pattern where appropriate

Type Safety (typed languages)

• Types defined for all public APIs
• No

  any

  usage without qualification
• Nullable types explicitly marked
• Type codes replaced with classes/enums

Testing

• Refactored code is tested
• Edge cases are covered
• All tests pass after each step
• Characterization tests capture pre-refactoring behavior

Language-Specific Guidance

Java

• Prefer

  final

  for locals that shouldn't change
• Use IDE automated refactorings (Eclipse/IntelliJ) for mechanical steps
• Leverage the type system: enums, records (Java 14+), sealed classes (Java 17+)

JavaScript/TypeScript

• Use destructuring to reduce parameter count
• Prefer

  const

  over

  let

  for immutable bindings
• Use TypeScript union types instead of type codes
• Nullish coalescing (

  ??

  ) and optional chaining (

  ?.

  ) eliminate null-check noise

Python

• Use type hints for documenting intent during refactoring
• Use

  dataclasses

  to replace tuple/data-class patterns
• Use

  @property

  to replace getters
• Context managers for resource cleanup patterns

Go

• Small interfaces preferred: accept interfaces, return structs
• Use named return values when they improve clarity
• Table-driven tests pair well with refactoring
• Avoid deep nesting with early returns

Rust

• Use

  Result

  and

  Option

  instead of error codes and null
• Pattern matching replaces if-else chains

• From

  trait implementations clean up type conversions
• Derive macros reduce boilerplate

Common Refactoring Sequences

Extract Method Sequence

1. Create a new method named after intent
2. Copy code fragment into new method
3. Identify local variables → parameters / return values
4. Call new method from original location
5. Test

Replace Conditional with Polymorphism Sequence

1. Create subclasses for each variant
2. Create a factory method that returns the right subclass
3. Move the conditional body to the appropriate subclass method
4. Delete the conditional

Extract Class Sequence

1. Identify a coherent subset of fields and methods
2. Create a new class
3. Create an instance from the old class
4. Move fields and methods one at a time
5. Update references in old class
6. Test after each move

Inline Class Sequence

1. Identify all callers of the target class
2. Move all methods/fields to the absorbing class
3. Redirect all references to the absorbing class
4. Delete the empty class
5. Test

Safety Protocol

Before You Touch Anything

1. Characterization tests  →  capture what the code does now
2. Git commit              →  save a known-good state
3. Branch                  →  isolate refactoring from other work

Every Single Step

1. One change              →  one refactoring technique
2. Compile                 →  must compile clean
3. Tests                   →  every test must pass
4. Commit                  →  message: "refactor: <technique> <what>"

If Tests Break

1. Undo the last change
2. Understand what broke and why
3. Try a smaller step
4. If the test was wrong and behavior was correct, fix the test FIRST, then retry

On Completion

1. Full test suite         →  all tests pass
2. Manual smoke test       →  quick sanity check
3. Self-review diff        →  catch unintended changes
4. Final commit            →  describe the overall transformation

Design Patterns in Refactoring

Strategy Pattern

Template Method

State Pattern

Composite Pattern

Decorator Pattern

Null Object Pattern

if (x == null)

Edge Cases & Gotchas

git stash

git reset --hard

Resources

• Martin Fowler, Refactoring: Improving the Design of Existing Code (2nd Edition, 2018)
• refactoring.com — Fowler's online catalog
• refactoring.guru — Illustrated refactoring patterns