System Design (LLD)Refactoring Toward Better Design

Refactoring Toward Better Design

LevelAdvanced

Duration75 mins

TopicRefactoring Toward Better Design

1 / 4

When to Refactor

The Art of Knowing When

Refactoring is one of the most powerful yet misunderstood practices in software engineering. Every seasoned developer has seen codebases paralyzed by premature refactoring—teams endlessly restructuring code that worked perfectly well. They've also witnessed the opposite disaster: systems so calcified by technical debt accumulation that adding a simple feature requires weeks of archaeological excavation.

The difference between these outcomes rarely lies in technical skill. It lies in judgment—the ability to recognize when refactoring delivers genuine value and when it becomes an expensive form of procrastination.

This distinction is what separates engineers who maintain healthy, evolving systems from those who either over-engineer simple solutions or let complexity overwhelm their codebases. Mastering this judgment is essential for both day-to-day development and LLD interviews, where interviewers frequently probe candidates' understanding of when—and when not—to restructure code.

What You Will Learn

By the end of this page, you will understand the precise criteria for when refactoring is necessary and beneficial. You'll learn to recognize code smells that signal refactoring opportunities, understand the economic calculus of refactoring decisions, and develop the professional judgment to balance improvement against delivery.

Defining Refactoring Precisely

Before discussing when to refactor, we must establish a rigorous definition of what refactoring actually is. The term is frequently misused, leading to confusion and poor decisions.

Martin Fowler's canonical definition:

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior."

This definition contains several critical constraints that distinguish refactoring from other forms of code modification:

Key Characteristics of True Refactoring

•Behavior-Preserving — The external observable behavior remains identical. All existing tests pass without modification. Clients of the code experience no difference.
•Disciplined and Incremental — Changes are small, verified, and reversible. Each step is a complete, working state. This isn't a 'rewrite from scratch' disguised as refactoring.
•Structure-Focused — The goal is improving internal quality metrics: readability, maintainability, extensibility, testability. Not adding features or fixing bugs.
•Intentional and Purposeful — Each refactoring step addresses a specific design issue. Random restructuring without clear motivation is not refactoring—it's churn.

What Refactoring Is NOT

Refactoring is not: rewriting functionality from scratch, adding new features while restructuring, fixing bugs while reorganizing, or performance optimization (which may change behavior in subtle ways). These activities may be valuable, but conflating them with refactoring leads to uncontrolled scope expansion and incomplete work.

Why this precision matters:

When developers blur the line between refactoring and feature work, they introduce risk. A 'refactoring' that also fixes bugs might mask regressions. A 'refactoring' that adds functionality creates coupling between structure changes and feature requirements. In LLD interviews, demonstrating this precise understanding signals professional maturity.

The discipline of separating these concerns is not pedantry—it's risk management. Each type of change has different testing requirements, different review standards, and different rollback implications. Keeping them separate makes each safer.

The Code Smell Signal: Recognizing Refactoring Opportunities

Code smells are surface-level indicators that often point to deeper structural problems. Developed by Kent Beck and popularized by Martin Fowler, code smells provide a vocabulary for articulating design concerns and triggering refactoring discussions.

Critically, code smells are heuristics, not rules. A smell suggests investigation, not automatic action. Sometimes the 'smelly' code is the best solution for the given constraints. Professional judgment means knowing when a smell indicates genuine rot versus acceptable trade-offs.

Critical Code Smells That Signal Refactoring Opportunities
Code Smell	Description	What It Often Indicates	Refactoring Response
Duplicated Code	Same or very similar code appears in multiple places	Missed abstraction; changes require updates in multiple locations	Extract Method, Extract Class, Pull Up Method
Long Method	Methods exceeding 20-30 lines; doing too many things	Violation of Single Responsibility; hard to test, understand, modify	Extract Method, Decompose Conditional, Replace Method with Method Object
Large Class	Classes with too many instance variables or methods	Multiple responsibilities bundled together; God Class anti-pattern	Extract Class, Extract Subclass, Extract Interface
Long Parameter List	Methods requiring 4+ parameters	Missing object abstraction; may indicate procedural thinking	Introduce Parameter Object, Preserve Whole Object, Replace Parameter with Method Call
Feature Envy	Method uses data from another class more than its own	Logic misplaced; belongs in the class whose data it uses	Move Method, Move Field, Extract Method
Data Clumps	Same groups of data appear together repeatedly	Missing object that should encapsulate the data	Extract Class, Introduce Parameter Object
Primitive Obsession	Over-reliance on primitives instead of small domain objects	Missing value objects; scattered validation logic	Replace Type Code with Class, Replace Primitive with Object
Switch Statements	Complex switch/case or if-else chains based on type codes	Missing polymorphism; adding new types requires changing existing code	Replace Conditional with Polymorphism, Replace Type Code with Strategy/State

Graduated severity:

Not all smells are created equal. Some indicate minor inconveniences while others signal architectural rot:

Low Severity: Comments explaining what code does (rather than why), minor duplication in test code, slightly long methods
Medium Severity: Feature envy between closely related classes, parameter lists of 4-5 items, moderate duplication across a few files
High Severity: Large classes with 500+ lines, duplicated logic across subsystems, complex conditional chains, circular dependencies
Critical Severity: God classes, shotgun surgery required for any change, rigid hierarchies that can't accommodate new requirements

The severity guides prioritization. Critical smells often block feature work and should trigger immediate action. Low-severity smells can accumulate as cleanup tasks for slower periods.

The Scout Rule Applied

"Leave the campground cleaner than you found it." — Boy Scout Rule adapted for software. When working on code with minor smells, address them opportunistically as part of your current work. This prevents accumulation without requiring dedicated refactoring sprints.

Economic Triggers: When Refactoring Pays Off

Code smells identify what might need refactoring, but economic analysis determines when refactoring delivers value. Refactoring isn't free—it consumes engineering time, introduces risk, and delays feature work. The decision must account for costs and benefits.

The fundamental economic question:

Will the time saved by cleaner code exceed the time invested in achieving it?

This calculation depends on several factors:

High-Value Refactoring Triggers

•Before Major Feature Work — If the upcoming feature must heavily modify problematic code, refactoring first creates a cleaner foundation. The feature work itself becomes easier and less risky. This is the 'make the change easy, then make the easy change' pattern.
•Repeated Pain Points — If multiple developers have struggled with the same code, or bugs keep emerging from the same area, the accumulated cost justifies investment. Track bug locations and development friction to identify these hotspots.
•Knowledge Preservation — When the original author is leaving or has left, and the code is important but poorly understood, refactoring to improve clarity preserves institutional knowledge. This is particularly valuable for critical business logic.
•Performance Critical Paths — When profiling reveals that poorly structured code is on a hot path, refactoring may be necessary before optimization is possible. Clean structure enables the optimizations that actually matter.
•Testing Gaps — When untestable code needs test coverage, refactoring to improve testability often must come first. This is especially important before major changes to critical functionality.

When to Refactor

•Code must be modified frequently
•Team is actively working in the area
•Business value depends on the code's evolution
•Tests exist or can be written first
•The cost of not refactoring compounds over time
•Risk can be managed with incremental changes

When NOT to Refactor

•Code is stable and rarely touched
•System is scheduled for replacement
•No tests exist and behavior is unclear
•Time pressure is extreme (ship deadline)
•The code's messiness is isolated and contained
•Refactoring scope keeps expanding ('black hole')

The Codebase Lifecycle Consideration

Code scheduled for deprecation or replacement rarely justifies refactoring investment. Similarly, one-time scripts or experimental prototypes may not warrant the polish of production code. Always consider the expected lifespan when deciding on refactoring investment.

The Rule of Three: A Practical Decision Framework

One of the most pragmatic heuristics for refactoring decisions is the Rule of Three, articulated by Don Roberts and popularized in refactoring literature:

"The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor."

This rule provides a simple framework that balances YAGNI (You Aren't Gonna Need It) against DRY (Don't Repeat Yourself):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// First occurrence: Just write it
function formatUserName(user: User): string {
    return `${user.firstName} ${user.lastName}`;
}
 
// Second occurrence: Notice similarity, but don't abstract yet
// Maybe the requirements are slightly different
function formatEmployeeName(employee: Employee): string {
    return `${employee.firstName} ${employee.lastName}`;
}
 
// Third occurrence: NOW refactor - this is clearly a pattern
// Before: formatCustomerName repeating the same logic
// After: Extract the abstraction
 
interface Named {
    firstName: string;
    lastName: string;
}
 
function formatFullName(entity: Named): string {
    return `${entity.firstName} ${entity.lastName}`;
}
 
// All three call sites now use the abstraction

Why wait for the third occurrence?

First occurrence: You don't yet know if this will ever repeat. Abstracting prematurely creates complexity for hypothetical future needs.
Second occurrence: The pattern is emerging, but two instances may share coincidental similarity that will diverge. The cost of wrong abstraction may exceed the cost of duplication.
Third occurrence: Now you have strong evidence of a genuine pattern. You understand the variations, the common core, and the likely future direction. Abstraction is grounded in reality, not speculation.

Variations on the rule:

Some organizations use 'Rule of Two' for critical code paths or 'Rule of Four' for highly volatile domains. The principle adapts to context: when changes are expensive or risky, abstract earlier; when requirements are unstable, wait longer.

Watch for Forced Generalization

The rule doesn't mean 'always abstract on the third occurrence.' If the third instance has different enough requirements, forcing it into a shared abstraction creates a worse design than three separate implementations. The pattern must be genuine, not manufactured.

Preparatory Refactoring: Making the Change Easy

One of the most valuable refactoring patterns is preparatory refactoring—restructuring code specifically to make an upcoming change easier, safer, or more localized. Kent Beck articulated this principle memorably:

"Make the change easy (warning: this may be hard), then make the easy change."

This pattern inverts the typical workflow. Instead of wrestling with resistant code to implement a feature, you first invest in improving the code's structure, then implement the feature in a now-welcoming environment.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// SCENARIO: Need to add a third payment method (crypto)
// Current code handles cards and bank transfers in a messy if-else
 
// BEFORE: Resistant structure
class PaymentProcessor {
    processPayment(method: string, amount: number) {
        if (method === 'card') {
            // 50 lines of card-specific logic
            this.validateCard();
            this.chargeCard(amount);
            this.sendCardReceipt();
        } else if (method === 'bank') {
            // 40 lines of bank-specific logic
            this.validateBank();
            this.initiateBankTransfer(amount);
            this.sendBankReceipt();
        }
        // Adding crypto here would make this worse
    }
}
 
// PREPARATORY REFACTORING: Make the change easy first
interface PaymentMethod {
    validate(): void;
    process(amount: number): void;
    sendReceipt(): void;
}
 
class CardPayment implements PaymentMethod {
    validate() { /* moved */ }
    process(amount: number) { /* moved */ }
    sendReceipt() { /* moved */ }
}
 
class BankPayment implements PaymentMethod {
    validate() { /* moved */ }
    process(amount: number) { /* moved */ }
    sendReceipt() { /* moved */ }
}
 
class PaymentProcessor {
    constructor(private methods: Map<string, PaymentMethod>) {}
 
    processPayment(method: string, amount: number) {
        const handler = this.methods.get(method);
        if (!handler) throw new Error(`Unknown payment method: ${method}`);
        handler.validate();
        handler.process(amount);
        handler.sendReceipt();
    }
}
 
// NOW: Adding crypto is trivial
class CryptoPayment implements PaymentMethod {
    validate() { /* new */ }
    process(amount: number) { /* new */ }
    sendReceipt() { /* new */ }
}
// Just register it: methods.set('crypto', new CryptoPayment())

The two-step rhythm:

Refactoring Phase (behavior-preserving): Restructure the code so that the new feature's implementation location is obvious and the required changes are minimal. All existing tests pass.
Feature Phase (behavior-changing): Add the new functionality to the prepared structure. Write new tests for the new behavior. The change is small and targeted.

This separation provides clean git history, simpler code review, and easier rollback. If the feature is cut, the preparatory refactoring may still have value. If the refactoring introduces issues, they're isolated from the feature code.

Interview Application

In LLD interviews, when asked to extend a design, explicitly discussing preparatory refactoring demonstrates mature engineering thinking. 'Before adding this feature, I would first refactor the existing structure to make this extension natural, isolating the behavior change from the structure change.'

Comprehension Refactoring: Understanding Through Improvement

Comprehension refactoring is restructuring code specifically to understand it better. When encountering unfamiliar or confusing code, actively refactoring it—renaming variables, extracting methods, adding clarifying structure—accelerates understanding more than passive reading.

This approach treats refactoring as a learning tool:

"I don't understand this code. Let me refactor it until I do, then decide if my changes should be kept."

Comprehension Refactoring Techniques

•Rename for Clarity — Replace cryptic variable, method, and class names with intention-revealing ones. 'data' becomes 'userPreferences', 'process' becomes 'validateAndTransformOrder'.
•Extract Explanatory Variables — Break complex expressions into named intermediate values. The names document what each piece does.
•Extract Methods — Identify logical chunks and give them names. The method name explains what the code does; reading the caller tells the story.
•Add Clarifying Structure — Group related fields, reorder methods logically, add section comments for large files. Make the code's organization match its conceptual structure.
•Simplify Conditionals — Complex boolean expressions become extracted predicates with meaningful names like 'isEligibleForDiscount' or 'hasActiveSubscription'.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// BEFORE: What does this do?
function calc(u: any, o: any[]): number {
    let t = 0;
    for (const x of o) {
        if (x.s === 'active' && u.m > 100) {
            t += x.p * 0.9;
        } else if (x.s === 'active') {
            t += x.p * 0.95;
        } else {
            t += x.p;
        }
    }
    return t < 50 ? t + 10 : t;
}
 
// AFTER: Comprehension refactoring reveals intent
interface User {
    membershipPoints: number;
}
 
interface OrderItem {
    status: 'active' | 'pending' | 'cancelled';
    price: number;
}
 
function calculateOrderTotal(user: User, items: OrderItem[]): number {
    let total = 0;
    
    for (const item of items) {
        const itemPrice = calculateItemPrice(user, item);
        total += itemPrice;
    }
    
    return applyMinimumOrderSurcharge(total);
}
 
function calculateItemPrice(user: User, item: OrderItem): number {
    if (item.status !== 'active') {
        return item.price;  // No discount on non-active items
    }
    
    const discount = isPremiumMember(user) ? 0.10 : 0.05;
    return item.price * (1 - discount);
}
 
function isPremiumMember(user: User): boolean {
    return user.membershipPoints > 100;
}
 
function applyMinimumOrderSurcharge(total: number): number {
    const MINIMUM_ORDER_THRESHOLD = 50;
    const SMALL_ORDER_SURCHARGE = 10;
    
    if (total < MINIMUM_ORDER_THRESHOLD) {
        return total + SMALL_ORDER_SURCHARGE;
    }
    return total;
}

The Throw-Away Option

Comprehension refactoring doesn't require committing the changes. If the refactoring reveals that the original code was correct for non-obvious reasons, you can discard your changes while keeping the understanding gained. The investment pays off regardless.

Red Flags: When to Avoid Refactoring

Knowing when not to refactor is as important as knowing when to proceed. Premature or ill-timed refactoring wastes resources, introduces risk, and can damage team trust. Watch for these warning signs:

Critical Red Flags

•No Test Coverage — Refactoring without tests is high-risk surgery without anesthesia. You have no reliable way to verify behavior preservation. Write tests first or accept limited refactoring scope.
•Unclear Current Behavior — If you don't fully understand what the code currently does, including edge cases, you cannot guarantee behavior preservation. Document behavior first, then refactor.
•Imminent Deadline — The week before a major release is not the time for structural changes. Technical debt is real, but shipping is also valuable. Schedule refactoring for the appropriate time.
•Scope Creep — Each refactoring reveals more 'needed' changes. The affected area keeps growing. This is a sign to stop, commit what you have, and plan the rest carefully.
•Solo Crusade — Refactoring that only you believe is necessary, without team buy-in, creates friction. Build consensus first, especially for large-scale changes.
•Aesthetic Preference — Restructuring code because you prefer a different style—without improving any measurable quality attribute—is churn, not refactoring.

The 'Rewrite vs. Refactor' trap:

When code is severely problematic, developers sometimes propose a 'refactoring' that is actually a rewrite in disguise. Signs of hidden rewrites:

Unable to merge incrementally with main branch
Multiple weeks of parallel development
'Just needs a bit more time' repeated indefinitely
New bugs that didn't exist in the old code
Team members unfamiliar with the 'refactored' code

True refactoring happens in small, frequent merges. If the work can't be structured this way, it's a rewrite—which may be valid, but requires different planning, risk assessment, and organizational approval.

The Strangler Fig Exception

Large legacy systems sometimes genuinely require incremental replacement (the Strangler Fig Pattern), but this is a deliberate architectural strategy, not refactoring. It involves running old and new systems in parallel, gradually routing traffic to the new system. This is rewriting, done carefully.

The Refactoring Decision Checklist

To synthesize the principles covered, here is a practical checklist for refactoring decisions. Before proceeding with significant refactoring, work through these questions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
## Pre-Refactoring Checklist
 
### Justification
- [ ] Can I articulate specific code smells present?
- [ ] Is there concrete evidence of pain (bugs, dev friction, slow changes)?
- [ ] Does this code need to change in the near future?
- [ ] Have at least three instances shown this pattern (Rule of Three)?
 
### Safety
- [ ] Do adequate tests exist to verify behavior preservation?
- [ ] If not, can I write characterization tests first?
- [ ] Do I understand current behavior, including edge cases?
- [ ] Can changes be made in small, mergeable increments?
 
### Economics
- [ ] Will time saved exceed time invested (realistic estimate)?
- [ ] Is this code actively maintained or nearly deprecated?
- [ ] Am I the right person to do this work (knowledge, time, skill)?
- [ ] Does the team agree this is a priority worth investment?
 
### Timing
- [ ] Is this an appropriate time (not near a release deadline)?
- [ ] Can this be done opportunistically with related feature work?
- [ ] Is there enough calendar time for incremental completion?
 
### Scope
- [ ] Have I defined clear, bounded refactoring goals?
- [ ] Can I articulate "done" criteria objectively?
- [ ] Have I resisted the urge to expand scope mid-refactoring?

Scoring interpretation:

All boxes checked: Proceed confidently with well-planned refactoring.
Safety concerns unchecked: Write tests first, or limit scope to safe areas.
Justification weak: Document expected benefits and seek team input before proceeding.
Timing poor: Schedule for a better time; focus on feature work now.
Economics unclear: Time-box a spike to validate assumptions before committing fully.

Page Complete: When to Refactor

You now understand the critical judgment skills for refactoring decisions. You can recognize code smells, apply economic analysis, use the Rule of Three, distinguish preparatory and comprehension refactoring, and identify red flags that signal 'not now'. Next, we'll explore the specific refactoring patterns and techniques—the 'how' that follows the 'when'.

1 / 4

Loading learning content...

System Design (LLD)Refactoring Toward Better Design

Refactoring Toward Better Design

LevelAdvanced

Duration75 mins

TopicRefactoring Toward Better Design

1 / 4

When to Refactor

The Art of Knowing When

What You Will Learn

Defining Refactoring Precisely

Before discussing when to refactor, we must establish a rigorous definition of what refactoring actually is. The term is frequently misused, leading to confusion and poor decisions.

Martin Fowler's canonical definition:

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior."

This definition contains several critical constraints that distinguish refactoring from other forms of code modification:

Key Characteristics of True Refactoring

•Behavior-Preserving — The external observable behavior remains identical. All existing tests pass without modification. Clients of the code experience no difference.
•Disciplined and Incremental — Changes are small, verified, and reversible. Each step is a complete, working state. This isn't a 'rewrite from scratch' disguised as refactoring.
•Structure-Focused — The goal is improving internal quality metrics: readability, maintainability, extensibility, testability. Not adding features or fixing bugs.
•Intentional and Purposeful — Each refactoring step addresses a specific design issue. Random restructuring without clear motivation is not refactoring—it's churn.

What Refactoring Is NOT

Why this precision matters:

The Code Smell Signal: Recognizing Refactoring Opportunities

Critical Code Smells That Signal Refactoring Opportunities
Code Smell	Description	What It Often Indicates	Refactoring Response
Duplicated Code	Same or very similar code appears in multiple places	Missed abstraction; changes require updates in multiple locations	Extract Method, Extract Class, Pull Up Method
Long Method	Methods exceeding 20-30 lines; doing too many things	Violation of Single Responsibility; hard to test, understand, modify	Extract Method, Decompose Conditional, Replace Method with Method Object
Large Class	Classes with too many instance variables or methods	Multiple responsibilities bundled together; God Class anti-pattern	Extract Class, Extract Subclass, Extract Interface
Long Parameter List	Methods requiring 4+ parameters	Missing object abstraction; may indicate procedural thinking	Introduce Parameter Object, Preserve Whole Object, Replace Parameter with Method Call
Feature Envy	Method uses data from another class more than its own	Logic misplaced; belongs in the class whose data it uses	Move Method, Move Field, Extract Method
Data Clumps	Same groups of data appear together repeatedly	Missing object that should encapsulate the data	Extract Class, Introduce Parameter Object
Primitive Obsession	Over-reliance on primitives instead of small domain objects	Missing value objects; scattered validation logic	Replace Type Code with Class, Replace Primitive with Object
Switch Statements	Complex switch/case or if-else chains based on type codes	Missing polymorphism; adding new types requires changing existing code	Replace Conditional with Polymorphism, Replace Type Code with Strategy/State

Graduated severity:

Not all smells are created equal. Some indicate minor inconveniences while others signal architectural rot:

Low Severity: Comments explaining what code does (rather than why), minor duplication in test code, slightly long methods
Medium Severity: Feature envy between closely related classes, parameter lists of 4-5 items, moderate duplication across a few files
High Severity: Large classes with 500+ lines, duplicated logic across subsystems, complex conditional chains, circular dependencies
Critical Severity: God classes, shotgun surgery required for any change, rigid hierarchies that can't accommodate new requirements

The severity guides prioritization. Critical smells often block feature work and should trigger immediate action. Low-severity smells can accumulate as cleanup tasks for slower periods.

The Scout Rule Applied

Economic Triggers: When Refactoring Pays Off

The fundamental economic question:

Will the time saved by cleaner code exceed the time invested in achieving it?

This calculation depends on several factors:

High-Value Refactoring Triggers

•Before Major Feature Work — If the upcoming feature must heavily modify problematic code, refactoring first creates a cleaner foundation. The feature work itself becomes easier and less risky. This is the 'make the change easy, then make the easy change' pattern.
•Repeated Pain Points — If multiple developers have struggled with the same code, or bugs keep emerging from the same area, the accumulated cost justifies investment. Track bug locations and development friction to identify these hotspots.
•Knowledge Preservation — When the original author is leaving or has left, and the code is important but poorly understood, refactoring to improve clarity preserves institutional knowledge. This is particularly valuable for critical business logic.
•Performance Critical Paths — When profiling reveals that poorly structured code is on a hot path, refactoring may be necessary before optimization is possible. Clean structure enables the optimizations that actually matter.
•Testing Gaps — When untestable code needs test coverage, refactoring to improve testability often must come first. This is especially important before major changes to critical functionality.

When to Refactor

•Code must be modified frequently
•Team is actively working in the area
•Business value depends on the code's evolution
•Tests exist or can be written first
•The cost of not refactoring compounds over time
•Risk can be managed with incremental changes

When NOT to Refactor

•Code is stable and rarely touched
•System is scheduled for replacement
•No tests exist and behavior is unclear
•Time pressure is extreme (ship deadline)
•The code's messiness is isolated and contained
•Refactoring scope keeps expanding ('black hole')

The Codebase Lifecycle Consideration

The Rule of Three: A Practical Decision Framework

One of the most pragmatic heuristics for refactoring decisions is the Rule of Three, articulated by Don Roberts and popularized in refactoring literature:

"The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor."

This rule provides a simple framework that balances YAGNI (You Aren't Gonna Need It) against DRY (Don't Repeat Yourself):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// First occurrence: Just write it
function formatUserName(user: User): string {
    return `${user.firstName} ${user.lastName}`;
}
 
// Second occurrence: Notice similarity, but don't abstract yet
// Maybe the requirements are slightly different
function formatEmployeeName(employee: Employee): string {
    return `${employee.firstName} ${employee.lastName}`;
}
 
// Third occurrence: NOW refactor - this is clearly a pattern
// Before: formatCustomerName repeating the same logic
// After: Extract the abstraction
 
interface Named {
    firstName: string;
    lastName: string;
}
 
function formatFullName(entity: Named): string {
    return `${entity.firstName} ${entity.lastName}`;
}
 
// All three call sites now use the abstraction

Why wait for the third occurrence?

First occurrence: You don't yet know if this will ever repeat. Abstracting prematurely creates complexity for hypothetical future needs.
Second occurrence: The pattern is emerging, but two instances may share coincidental similarity that will diverge. The cost of wrong abstraction may exceed the cost of duplication.
Third occurrence: Now you have strong evidence of a genuine pattern. You understand the variations, the common core, and the likely future direction. Abstraction is grounded in reality, not speculation.

Variations on the rule:

Watch for Forced Generalization

Preparatory Refactoring: Making the Change Easy

"Make the change easy (warning: this may be hard), then make the easy change."

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// SCENARIO: Need to add a third payment method (crypto)
// Current code handles cards and bank transfers in a messy if-else
 
// BEFORE: Resistant structure
class PaymentProcessor {
    processPayment(method: string, amount: number) {
        if (method === 'card') {
            // 50 lines of card-specific logic
            this.validateCard();
            this.chargeCard(amount);
            this.sendCardReceipt();
        } else if (method === 'bank') {
            // 40 lines of bank-specific logic
            this.validateBank();
            this.initiateBankTransfer(amount);
            this.sendBankReceipt();
        }
        // Adding crypto here would make this worse
    }
}
 
// PREPARATORY REFACTORING: Make the change easy first
interface PaymentMethod {
    validate(): void;
    process(amount: number): void;
    sendReceipt(): void;
}
 
class CardPayment implements PaymentMethod {
    validate() { /* moved */ }
    process(amount: number) { /* moved */ }
    sendReceipt() { /* moved */ }
}
 
class BankPayment implements PaymentMethod {
    validate() { /* moved */ }
    process(amount: number) { /* moved */ }
    sendReceipt() { /* moved */ }
}
 
class PaymentProcessor {
    constructor(private methods: Map<string, PaymentMethod>) {}
 
    processPayment(method: string, amount: number) {
        const handler = this.methods.get(method);
        if (!handler) throw new Error(`Unknown payment method: ${method}`);
        handler.validate();
        handler.process(amount);
        handler.sendReceipt();
    }
}
 
// NOW: Adding crypto is trivial
class CryptoPayment implements PaymentMethod {
    validate() { /* new */ }
    process(amount: number) { /* new */ }
    sendReceipt() { /* new */ }
}
// Just register it: methods.set('crypto', new CryptoPayment())

The two-step rhythm:

Refactoring Phase (behavior-preserving): Restructure the code so that the new feature's implementation location is obvious and the required changes are minimal. All existing tests pass.
Feature Phase (behavior-changing): Add the new functionality to the prepared structure. Write new tests for the new behavior. The change is small and targeted.

Interview Application

Comprehension Refactoring: Understanding Through Improvement

This approach treats refactoring as a learning tool:

"I don't understand this code. Let me refactor it until I do, then decide if my changes should be kept."

Comprehension Refactoring Techniques

•Rename for Clarity — Replace cryptic variable, method, and class names with intention-revealing ones. 'data' becomes 'userPreferences', 'process' becomes 'validateAndTransformOrder'.
•Extract Explanatory Variables — Break complex expressions into named intermediate values. The names document what each piece does.
•Extract Methods — Identify logical chunks and give them names. The method name explains what the code does; reading the caller tells the story.
•Add Clarifying Structure — Group related fields, reorder methods logically, add section comments for large files. Make the code's organization match its conceptual structure.
•Simplify Conditionals — Complex boolean expressions become extracted predicates with meaningful names like 'isEligibleForDiscount' or 'hasActiveSubscription'.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
// BEFORE: What does this do?
function calc(u: any, o: any[]): number {
    let t = 0;
    for (const x of o) {
        if (x.s === 'active' && u.m > 100) {
            t += x.p * 0.9;
        } else if (x.s === 'active') {
            t += x.p * 0.95;
        } else {
            t += x.p;
        }
    }
    return t < 50 ? t + 10 : t;
}
 
// AFTER: Comprehension refactoring reveals intent
interface User {
    membershipPoints: number;
}
 
interface OrderItem {
    status: 'active' | 'pending' | 'cancelled';
    price: number;
}
 
function calculateOrderTotal(user: User, items: OrderItem[]): number {
    let total = 0;
    
    for (const item of items) {
        const itemPrice = calculateItemPrice(user, item);
        total += itemPrice;
    }
    
    return applyMinimumOrderSurcharge(total);
}
 
function calculateItemPrice(user: User, item: OrderItem): number {
    if (item.status !== 'active') {
        return item.price;  // No discount on non-active items
    }
    
    const discount = isPremiumMember(user) ? 0.10 : 0.05;
    return item.price * (1 - discount);
}
 
function isPremiumMember(user: User): boolean {
    return user.membershipPoints > 100;
}
 
function applyMinimumOrderSurcharge(total: number): number {
    const MINIMUM_ORDER_THRESHOLD = 50;
    const SMALL_ORDER_SURCHARGE = 10;
    
    if (total < MINIMUM_ORDER_THRESHOLD) {
        return total + SMALL_ORDER_SURCHARGE;
    }
    return total;
}

The Throw-Away Option

Red Flags: When to Avoid Refactoring

Critical Red Flags

•No Test Coverage — Refactoring without tests is high-risk surgery without anesthesia. You have no reliable way to verify behavior preservation. Write tests first or accept limited refactoring scope.
•Unclear Current Behavior — If you don't fully understand what the code currently does, including edge cases, you cannot guarantee behavior preservation. Document behavior first, then refactor.
•Imminent Deadline — The week before a major release is not the time for structural changes. Technical debt is real, but shipping is also valuable. Schedule refactoring for the appropriate time.
•Scope Creep — Each refactoring reveals more 'needed' changes. The affected area keeps growing. This is a sign to stop, commit what you have, and plan the rest carefully.
•Solo Crusade — Refactoring that only you believe is necessary, without team buy-in, creates friction. Build consensus first, especially for large-scale changes.
•Aesthetic Preference — Restructuring code because you prefer a different style—without improving any measurable quality attribute—is churn, not refactoring.

The 'Rewrite vs. Refactor' trap:

When code is severely problematic, developers sometimes propose a 'refactoring' that is actually a rewrite in disguise. Signs of hidden rewrites:

Unable to merge incrementally with main branch
Multiple weeks of parallel development
'Just needs a bit more time' repeated indefinitely
New bugs that didn't exist in the old code
Team members unfamiliar with the 'refactored' code

The Strangler Fig Exception

The Refactoring Decision Checklist

To synthesize the principles covered, here is a practical checklist for refactoring decisions. Before proceeding with significant refactoring, work through these questions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
## Pre-Refactoring Checklist
 
### Justification
- [ ] Can I articulate specific code smells present?
- [ ] Is there concrete evidence of pain (bugs, dev friction, slow changes)?
- [ ] Does this code need to change in the near future?
- [ ] Have at least three instances shown this pattern (Rule of Three)?
 
### Safety
- [ ] Do adequate tests exist to verify behavior preservation?
- [ ] If not, can I write characterization tests first?
- [ ] Do I understand current behavior, including edge cases?
- [ ] Can changes be made in small, mergeable increments?
 
### Economics
- [ ] Will time saved exceed time invested (realistic estimate)?
- [ ] Is this code actively maintained or nearly deprecated?
- [ ] Am I the right person to do this work (knowledge, time, skill)?
- [ ] Does the team agree this is a priority worth investment?
 
### Timing
- [ ] Is this an appropriate time (not near a release deadline)?
- [ ] Can this be done opportunistically with related feature work?
- [ ] Is there enough calendar time for incremental completion?
 
### Scope
- [ ] Have I defined clear, bounded refactoring goals?
- [ ] Can I articulate "done" criteria objectively?
- [ ] Have I resisted the urge to expand scope mid-refactoring?

Scoring interpretation:

All boxes checked: Proceed confidently with well-planned refactoring.
Safety concerns unchecked: Write tests first, or limit scope to safe areas.
Justification weak: Document expected benefits and seek team input before proceeding.
Timing poor: Schedule for a better time; focus on feature work now.
Economics unclear: Time-box a spike to validate assumptions before committing fully.

Page Complete: When to Refactor

1 / 4