Refactoring Legacy Code: The Jedi Move of Extracting Pure...

The Quest Begins (The “Why”)

Picture this: I’m deep in a codebase that looks like the junkyard planet from Star Wars—tangled wires, rusted droids, and a mysterious hum coming from somewhere I can’t quite locate. My task? Add a simple discount rule to an e‑commerce checkout. Sounds easy, right?

I opened the file and found a 200‑line monster called calculateOrderTotal. Inside, there were nested if statements that checked user type, coupon validity, tax rules, and even a weird side‑effect that wrote to a global audit log. Changing one line felt like trying to replace a single tile in the Death Star’s trench while dodging laser fire. After three hours of stepping through the debugger, I realized the real problem wasn’t the discount logic—it was that the function was doing everything at once, mutating state, and hiding its intentions behind a wall of imperative code.

That moment hit me like Neo seeing the Matrix for the first time: if I could isolate the pure calculations, the rest would become trivial. I needed a lightsaber, not a sledgehammer.

The Revelation (The Insight)

The treasure I uncovered? Extracting pure functions—small, deterministic pieces that take inputs, return outputs, and never touch the outside world. A pure function is like a Jedi’s lightsaber swing: predictable, repeatable, and free of side‑effects. When you isolate the “what” (the calculation) from the “how” (state changes, I/O, logging), you gain:

Testability – you can call the function with any inputs and assert the output, no mocks needed.
Reasoning – you can look at the function in isolation and know exactly what it does.
Composability – you can plug pure functions together like LEGO bricks to build complex behavior.

In legacy code, the opposite is common: a function that reads a global config, writes to a file, updates a database, and returns a value all at once. Change one requirement, and you risk breaking three unrelated things. Pure functions eliminate that coupling.

Wielding the Power (Code & Examples)

Let’s look at a realistic before/after scenario. Imagine we’re working on a reporting module that calculates a user’s “engagement score” based on login frequency, post count, and reaction weight. The original function looks like this (the “trap” we want to avoid):

// BEFORE: a classic legacy monster
function calculateEngagementScore(userId) {
  // 1️⃣ fetch data – side effect!
  const user = db.getUserById(userId);
  const logs = db.getLoginLogs(userId);
  const posts = db.getPostsByUserId(userId);
  const reactions = db.getReactionsByUserId(userId);

  // 2️⃣ mutable state that we keep tweaking
  let score = 0;

  // 3️⃣ tangled logic with side effects
  if (user.isPremium) {
    score += 50; // arbitrary bonus
  }

  logs.forEach(log => {
    if (log.timestamp > Date.now() - 86400000) { // last 24h
      score += 10;
      // 🙈 side effect: we update a cache here!
      cache.set(`engagement:${userId}:today`, score);
    }
  });

  posts.forEach(post => {
    score += post.length * 0.1;
    // 🙈 another side effect: increment a counter
    metrics.increment('postsProcessed');
  });

  reactions.forEach(reaction => {
    score += reaction.weight * 2;
    // 🙈 yet another side effect: write to an audit table
    db.auditLog({ userId, action: 'reactionCounted', weight: reaction.weight });
  });

  // 4️⃣ final mutating step: clamp the score
  if (score > 1000) score = 1000;
  if (score < 0) score = 0;

  return score;
}

What’s wrong?

The function reaches out to the database, cache, metrics, and audit log—all side effects.
It mutates a local score variable in many places, making the flow hard to follow.
Testing it means spinning up a DB, mocking the cache, and verifying a dozen external calls.

Now, watch the transformation after we extract pure functions. The idea is simple: each distinct calculation gets its own pure helper. The main orchestrator becomes a thin pipeline that calls those helpers and then deals with side effects only at the edges.

// PURE: login bonus – depends only on logs
function loginBonus(logs) {
  const now = Date.now();
  return logs.reduce((acc, log) => {
    return log.timestamp > now - 86400000 ? acc + 10 : acc;
  }, 0);
}

// PURE: post score – depends only on posts
function postScore(posts) {
  return posts.reduce((acc, p) => acc + p.length * 0.1, 0);
}

// PURE: reaction score – depends only on reactions
function reactionScore(reactions) {
  return reactions.reduce((acc, r) => acc + r.weight * 2, 0);
}

// PURE: premium bonus – depends only on user flag
function premiumBonus(isPremium) {
  return isPremium ? 50 : 0;
}

// PURE: clamp score to [0, 1000]
function clampScore(value) {
  return Math.min(Math.max(value, 0), 1000);
}

// ORCHESTRATOR: still does the I/O, but the core logic is pure
function calculateEngagementScore(userId) {
  const user = db.getUserById(userId);
  const logs = db.getLoginLogs(userId);
  const posts = db.getPostsByUserId(userId);
  const reactions = db.getReactionsByUserId(userId);

  const rawScore =
    premiumBonus(user.isPremium) +
    loginBonus(logs) +
    postScore(posts) +
    reactionScore(reactions);

  return clampScore(rawScore);
}

Why this feels like a power‑up

Testing becomes a breeze: I can write unit tests for loginBonus, postScore, etc., with plain arrays—no DB, no mocks.
Documentation is self‑evident: the function names tell the story. If I need to tweak how logs contribute, I open loginBonus and see exactly the 10‑point per‑day rule.
Side effects are quarantined: the only places that touch the outside world are the four db.get… calls and the final return. If I ever need to swap the database for a service call, I change those four lines, not the scoring logic.

Common traps to avoid (the “dark side” pitfalls)

Extracting but keeping side effects inside the helper – e.g., moving the cache.set into loginBonus. That defeats the purpose; you’ve just hidden the impurity.
Over‑extracting to the point of nonsense – creating a pure function that adds two numbers when the gain is negligible. Keep the granularity meaningful: each helper should represent a distinct business rule.
Forgetting to handle errors – if a db.get… can throw, wrap those calls, but don’t let the error‑handling leak into the pure functions. Keep error handling at the orchestrator level.

Why This New Power Matters

By embracing pure functions, I turned a terrifying, tightly‑coupled monolith into a set of small, trustworthy building blocks. The immediate payoff? I added the new discount rule in under fifteen minutes, wrote three focused unit tests, and deployed without a single regression bug. The team noticed: the file went from 200 lines to about 80, and the cyclomatic complexity dropped from 12 to 4.

More importantly, the mindset shift stuck. When I now see a function that reaches out to the world and mutates state, I automatically ask: “What part of this is just a calculation?” That question has become my go‑to refactoring trigger, and it’s saved me countless hours of debugging across projects.

Think of it like learning the Force in Star Wars: once you feel it, you can’t un‑feel it. You start seeing the hidden flows, the unnecessary side effects, and you know exactly where to apply a gentle push to restore balance.

Your Turn – Embark on Your Own Quest

I challenge you: pick one legacy function in your codebase that makes you sigh every time you open it. Identify the pure calculation hiding inside it, extract it into a small helper, and watch the rest of the code simplify.

What’s the first function you’ll refactor? Drop a comment below with a before/after snippet (or just the name of the function) and let’s celebrate each other’s victories. May your refactors be clean, your tests be green, and your bugs be as rare as a well‑placed Easter egg in a Marvel post‑credit scene. Happy coding!

推荐订阅源

DEV Community