Refactoring

Refactoring is the process of changing a software system’s internal structure without altering its observable behaviour. Martin Fowler’s Refactoring: Improving the Design of Existing Code (1st ed. 1999, 2nd ed. 2018) catalogued over 60 named refactorings, each a small, safe, behaviour-preserving transformation. The discipline exists because code degrades: quick fixes, changing requirements, and time pressure produce structures that were reasonable when written but become obstacles to future work.

When to Refactor

Refactoring is not a separate phase — it is continuous. The most effective model is the rule of three:

1. First time doing something: just do it.
2. Second time doing something similar: notice the duplication.
3. Third time: refactor.

Refactor just before adding a feature when the current structure makes the feature hard. Refactor just after fixing a bug when you notice the code that hid the bug. Refactor during code review when a reviewer spots a clearer structure.

Core Refactorings

Extract Function

When a block of code can be grouped by intention, extract it into a named function. The name is the comment.

// Before
function printInvoice(invoice: Invoice) {
  // calculate outstanding
  let outstanding = 0;
  for (const order of invoice.orders) {
    outstanding += order.amount;
  }
  console.log(`Customer: ${invoice.customer}`);
  console.log(`Amount owed: ${outstanding}`);
}

// After
function calculateOutstanding(invoice: Invoice): number {
  return invoice.orders.reduce((sum, order) => sum + order.amount, 0);
}

function printInvoice(invoice: Invoice) {
  const outstanding = calculateOutstanding(invoice);
  console.log(`Customer: ${invoice.customer}`);
  console.log(`Amount owed: ${outstanding}`);
}

Rename Variable

A variable’s name should communicate its purpose fully. Renaming is the most frequently applied refactoring and pays the most per keystroke.

// Before — what is d? what is arr?
const d = computeDelta(arr);

// After — unambiguous
const priceDelta = computeDelta(historicalPrices);

Introduce Parameter Object

When the same cluster of parameters appears together in multiple functions, group them into a named type.

// Before — three parameters always travel together
function createReport(startDate: Date, endDate: Date, userId: string) { ... }
function exportReport(startDate: Date, endDate: Date, userId: string) { ... }

// After
interface ReportCriteria {
  startDate: Date;
  endDate: Date;
  userId: string;
}

function createReport(criteria: ReportCriteria) { ... }
function exportReport(criteria: ReportCriteria) { ... }

Replace Conditional with Polymorphism

A switch or if/else if chain that checks a type field and branches on it is a sign that the type field should be a class hierarchy.

// Before
function getShippingCost(order: Order): number {
  switch (order.shippingType) {
    case "standard": return order.weight * 2;
    case "express":  return order.weight * 5;
    case "overnight": return order.weight * 10;
  }
}

// After — each type encapsulates its own calculation
abstract class ShippingMethod {
  abstract cost(order: Order): number;
}

class StandardShipping extends ShippingMethod {
  cost(order: Order) { return order.weight * 2; }
}

class ExpressShipping extends ShippingMethod {
  cost(order: Order) { return order.weight * 5; }
}

Refactoring Safely with Tests

Refactoring without tests is reckless. The only way to verify behaviour is preserved is to run an automated test suite before and after every change. The workflow is:

1. Run the test suite — it must be green before you start.
2. Make one small refactoring.
3. Run the tests again. If they pass, commit. If they fail, undo immediately.
4. Repeat.

Technical Debt

Ward Cunningham coined the term “technical debt” in 1992. Like financial debt, it accrues interest: code that was written hastily needs to be understood and worked around on every future change. Debt is not always bad — sometimes a quick solution is the right choice when speed matters. The problem is debt that is never repaid.

Further Learning

Search these terms to go deeper:

• “Refactoring Martin Fowler second edition” — the canonical catalogue; the online version at refactoring.com lists all refactorings
• “technical debt Ward Cunningham origin” — the original 1992 OOPSLA talk introducing the metaphor
• “characterisation tests Michael Feathers Working Effectively with Legacy Code” — the definitive book on adding tests to untested code
• “refactoring to patterns Joshua Kerievsky” — how refactoring and design patterns connect
• “continuous refactoring ThoughtWorks” — the industry perspective on embedding refactoring in everyday work

Refactoring

Refactoring means improving the structure of code without changing what it does. Same behavior, cleaner insides — like tidying a messy room without throwing anything out. It’s how you keep a codebase from slowly rotting.

When to do it

Refactoring isn’t a big separate project — it’s a little-and-often habit. A handy guideline is the rule of three: the first time, just write it; the second time you see similar code, notice it; the third time, refactor to remove the duplication.

A few everyday refactorings

Extract a function — pull a chunk of code into a well-named function. The name replaces a comment:

// before: a loop buried inside a bigger function
let total = 0
for (const o of invoice.orders) total += o.amount

// after: give it a name
const total = calculateTotal(invoice)

Rename for clarity — the cheapest, highest-value refactor:

const d = compute(arr)              // ❌ what are these?
const priceDelta = compute(prices)  // ✅ clear

Group related parameters — when the same 3 arguments always travel together, bundle them into one object:

// before
createReport(startDate, endDate, userId)
// after
createReport({ startDate, endDate, userId })

Refactor safely: lean on tests

The whole point is “same behavior” — so how do you know you didn’t break anything? Tests. The safe rhythm:

1. Make sure tests pass (green) before you start.
2. Make one small change.
3. Run tests again. Pass → keep going. Fail → undo immediately.

Technical debt

Technical debt is the messiness you take on to ship fast — like a loan. A little is fine and sometimes smart, but if you never “pay it back” by cleaning up, it charges “interest”: every future change gets harder.

In one sentence

Refactoring improves code’s structure while keeping its behavior identical — do it little and often (rule of three), keep it separate from feature commits, and rely on tests to prove you didn’t break anything.

Want to go deeper?

Switch to Expert mode above for replacing conditionals with polymorphism, characterization tests, and categorizing technical debt.