top of page

Why Refactor — Refactoring Patterns, Part 1

  • Contributor
  • 1 day ago
  • 2 min read
Refactoring Patterns · Part 1

Refactoring earns interest like compound returns. Or wastes time, if done wrong.

Step 1: Definition (15 min)

Refactor: change code structure without changing behavior.

Same inputs → same outputs. Internal cleaner.

Not refactoring:

  • Adding features

  • Fixing bugs

  • Changing requirements

Step 2: The Payoff (15 min)

Clean code:

  • Faster to read (mostly what engineers do)

  • Faster to change

  • Fewer bugs

  • Easier onboarding

Refactoring = investment in future work. Compounds.

Step 3: When to Refactor (15 min)

Boy Scout rule: as you touch code.

Larger refactors when:

  • About to add feature; current code blocks

  • Pattern is now clear (previously fuzzy)

  • Bug clusters in same area

  • Test or read is painful

Step 4: When Not to Refactor (15 min)

  • Code about to be deleted

  • No tests, no time to add them

  • Hot deadline (defer)

  • You don't understand it yet

  • Just for aesthetics ("I'd write it differently")

Step 5: The Two Hats (15 min)

Kent Beck: you're either:

  • Adding feature (no refactor mixing)

  • Refactoring (no behavior change mixing)

Switching hats: explicit. PRs reflect.

Mixing: hard to review; bugs sneak in.

Step 6: With Tests, Not Without (15 min)

Refactor = change without changing behavior.

How to know behavior unchanged? Tests.

No tests: it's gambling, not refactoring.

Part 9: refactor to tests.

Step 7: Small Steps (15 min)

Refactor in small steps:

  • One name change

  • One extracted method

  • Commit

  • Run tests

  • Next step

Long-lived refactor branches: merge hell.

Step 8: Tools (15 min)

IDE refactoring tools:

  • Rename (safe across files)

  • Extract method

  • Inline

  • Move

  • Change signature

Use them. Manual edits = mistakes.

Step 9: Measuring (15 min)

Hard to measure. Proxies:

  • PR cycle time per area (decreasing = better)

  • Bug rate (decreasing)

  • Engineer survey ("easier to work with")

  • LOC reduction (sometimes)

Or just notice: "this is nicer now."

Step 10: Mental Model (15 min)

Refactoring is constant maintenance, not occasional cleanup.

Like:

  • Brushing teeth

  • Watering plants

  • Putting away groceries

Routine. Pay tiny amounts; avoid big problems.

What You Just Did

Why refactor: definition, the payoff, when to refactor, when not to, the two hats, with tests, small steps, tools, measuring, mental model.

Common Failure Modes

Refactor without tests. Risk regressions.

Big-bang refactor. Long branch; pain.

Refactor + feature in one PR. Hard to review.

Refactor for aesthetics. Wasted time.

Never refactor. Tech debt accumulates.

Continue the Refactoring Patterns path

Part of the Refactoring Patterns learning path.

bottom of page