Refactoring

Decision Tree

Code looks messy → Should you refactor?
    ├─ Is it blocking the current task? → Yes → Refactor the minimum needed
    ├─ Is it actively causing bugs? → Yes → Refactor with tests first
    ├─ Will you touch this code again soon? → Yes → Refactor now (Boy Scout Rule)
    ├─ Is it working and rarely changed? → Leave it alone
    ├─ Does the user explicitly ask for refactoring? → Yes → Refactor per their scope
    └─ Is it just "not how I'd write it"? → Leave it alone

Code Smells → Refactoring

Safe Refactoring Process

1. Ensure tests exist (write them first if they don't)
2. Make ONE small change
3. Run tests
4. Commit
5. Repeat

Never refactor and change behavior in the same commit. Refactoring = same behavior, better structure. New behavior = new commit.

Common Refactoring Patterns

Extract Early Returns (flatten nesting)

// Before
function process(user) {
  if (user) {
    if (user.active) {
      if (user.hasPermission) {
        return doWork(user);
      }
    }
  }
  return null;
}

// After
function process(user) {
  if (!user) return null;
  if (!user.active) return null;
  if (!user.hasPermission) return null;
  return doWork(user);
}

Replace Conditional with Polymorphism

// Before
function getArea(shape) {
  switch (shape.type) {
    case 'circle': return Math.PI * shape.radius ** 2;
    case 'rectangle': return shape.width * shape.height;
  }
}

// After — each shape knows how to calculate its own area
class Circle { getArea() { return Math.PI * this.radius ** 2; } }
class Rectangle { getArea() { return this.width * this.height; } }

Replace Magic Values with Constants

// Before
if (retries > 3) { setTimeout(fn, 5000); }

// After
const MAX_RETRIES = 3;
const RETRY_DELAY_MS = 5000;
if (retries > MAX_RETRIES) { setTimeout(fn, RETRY_DELAY_MS); }

Anti-Patterns