Anti-Patterns to Avoid

Analogy categoryAnalogies

What Is an Anti-Pattern?

An anti-pattern is a commonly repeated solution to a problem that looks reasonable in the short term but produces more problems than it solves over time. Unlike a random bad decision, an anti-pattern is a named, recognizable pattern of failure — it has a shape, root causes, and a documented refactoring path. Studying anti-patterns is as valuable as studying the Gang of Four patterns because it teaches you to spot decay before it spreads through a codebase.

🏏

Cricket analogy: A captain who always brings on his strike bowler for the last over regardless of match-up looks decisive early in his career, but as batting orders adapt to the pattern, the tactic becomes predictable and costly — exactly how an anti-pattern seems fine until the codebase 'reads' your habits and exploits the weakness.

Structural Anti-Patterns: God Object and Singleton Abuse

The God Object anti-pattern occurs when a single class accumulates responsibilities — data access, validation, business rules, formatting, notifications — until it knows and does too much. It violates the Single Responsibility Principle and becomes a magnet for merge conflicts because every feature touches the same file. A close cousin is Singleton abuse: using the Singleton pattern not because global, single-instance state is genuinely required, but as a lazy substitute for proper dependency injection, which makes unit testing painful because the singleton's hidden state leaks between tests.

🏏

Cricket analogy: A team that insists one all-rounder bat at three, bowl the powerplay, keep wicket in emergencies, and captain the side is over-concentrating responsibility in one player — exactly like a God Object — and if that player has an off day, the whole team's structure collapses.

Behavioral Anti-Patterns: Spaghetti Code and Callback Hell

Spaghetti code emerges when control flow branches unpredictably — deeply nested conditionals, goto-like jumps via flags, and functions that mutate shared state from many call sites — until tracing a single execution path requires holding the whole file in your head. Callback hell is its asynchronous sibling: nesting callback inside callback inside callback for sequential async steps, producing a rightward-drifting pyramid of code that is nearly impossible to read, error-handle, or modify safely. Both share the same root cause — control flow that isn't linearized or named, so the reader must simulate the interpreter mentally instead of reading intent.

🏏

Cricket analogy: Spaghetti code is like a fielding captain who shouts contradictory instructions mid-over — move square leg, no wait cover, no slip — until fielders are running in circles; nobody can reconstruct the intended field placement after the fact.

javascript

// ANTI-PATTERN: Callback hell + God Object mixing concerns
class OrderManager {
  placeOrder(orderId, cb) {
    db.getOrder(orderId, (err, order) => {
      if (err) return cb(err);
      inventory.reserve(order.items, (err, reserved) => {
        if (err) return cb(err);
        payment.charge(order.total, (err, receipt) => {
          if (err) return cb(err);
          email.send(order.customerEmail, receipt, (err) => {
            if (err) return cb(err);
            cb(null, receipt);
          });
        });
      });
    });
  }
}

// REFACTORED: linear async/await, responsibilities separated
class OrderService {
  constructor(orders, inventory, payments, notifier) {
    this.orders = orders;
    this.inventory = inventory;
    this.payments = payments;
    this.notifier = notifier;
  }

  async placeOrder(orderId) {
    const order = await this.orders.get(orderId);
    await this.inventory.reserve(order.items);
    const receipt = await this.payments.charge(order.total);
    await this.notifier.send(order.customerEmail, receipt);
    return receipt;
  }
}

A useful smell-test: if you cannot describe a class's job in one short sentence without using the word 'and', it is drifting toward God Object territory. Split it along the seams where 'and' appears.

Detecting and Refactoring Anti-Patterns

Detection usually starts with metrics that correlate with anti-patterns: cyclomatic complexity spikes, classes with dozens of public methods, files that show up in nearly every commit's diff, and functions with more than three or four levels of nesting. Once found, the fix is rarely a rewrite — it is a sequence of small, behavior-preserving refactorings: Extract Class to peel responsibilities off a God Object, Extract Method to name nested conditionals, and converting callback pyramids to Promises or async/await to flatten control flow. The discipline is to refactor under a passing test suite so each extraction can be verified as behavior-neutral before the next one begins.

🏏

Cricket analogy: A team analyst spotting that a batter's average has quietly dropped whenever facing left-arm spin is running the cricketing equivalent of a complexity metric — the pattern shows up in the numbers before anyone consciously notices the flaw in technique.

Never attempt to fix an anti-pattern and add a new feature in the same commit. Refactoring changes structure, not behavior; mixing the two makes it impossible to tell whether a regression came from the cleanup or the new logic, and it makes code review far harder.

An anti-pattern is a recognizable, named, recurring bad solution — not just a one-off mistake.
God Object concentrates too many responsibilities in one class, violating Single Responsibility.
Singleton abuse substitutes a lazy global for proper dependency injection and hurts testability.
Spaghetti code and callback hell both stem from unlinearized, unnamed control flow.
Detect anti-patterns with metrics: cyclomatic complexity, churn/commit frequency, method count, nesting depth.
Refactor via small, behavior-preserving steps (Extract Class, Extract Method) under a passing test suite.
Never mix refactoring with new feature work in the same commit.