Code Refactoring in Practice: From "It Works" to "Easy to Change"

The Bottom Line: Refactoring Is Not “Rewriting” — It Is “Improving”

Many developers react to bad code with “let’s rewrite it,” but rewriting carries much higher risk than refactoring — you may lose edge case handling, introduce new bugs, and business stakeholders will not wait for you to “finish the rewrite.”

The core principle of refactoring: change one thing at a time, and make sure it still works after each change.

---

1. When to Refactor

Signals Worth Acting On

Signal	Symptom	Solution
Duplicated code	Same logic in multiple places	Extract function or class
Long function	Over 50 lines	Split into smaller functions
Large class	Over 500 lines	Split responsibilities
Tight coupling	Changing one thing breaks many	Introduce interfaces or DI
Poor naming	Variable names do not express intent	Rename

When NOT to Refactor

• Code is about to be replaced (scheduled for decommission)
• Code is rarely modified (stable, untouched)
• No test coverage and cannot be added (legacy system nearing end of life)

---

2. Safe Refactoring Steps

2.1 Write Tests First

describe('formatPrice', () => {
  it('formats price correctly', () => {
    expect(formatPrice(1000)).toBe('¥1,000.00');
    expect(formatPrice(2500.5)).toBe('¥2,500.50');
  });
});

2.2 Small Steps

One refactoring operation at a time, run tests after each:

// Step 1: Rename
function calc(a: number, b: number) { ... }
// → function calculateDiscount(originalPrice: number, level: string) { ... }

// Step 2: Extract function
const total = items.reduce((sum, i) => sum + i.price * i.qty, 0);
const tax = total * 0.1;
// → function calculateSubtotal(items: Item[]): number { ... }
// → function calculateTax(subtotal: number): number { ... }

2.3 Commit Each Step

git commit -m "refactor: extract calculateDiscount function, replace inline calculation"

---

3. Common Refactoring Techniques

Technique	Best For	Note
Rename	Poor naming	IDE auto-refactoring, safe
Extract Function	Long functions, duplication	Extract logic into independent function
Extract Variable	Hard-to-understand expressions	Use meaningful variable names
Decompose Condition	Long conditionals	Split into multiple functions
Introduce Parameter	Hard-coded values	Replace with parameter
Move Method	Method in wrong class	Move to more appropriate class

---

4. Make Refactoring a Habit

The Boy Scout Rule

“Leave the camp cleaner than you found it” — every time you modify code, improve it slightly. No need to schedule dedicated refactoring time.

Time Budget

Scenario	Suggested Time
Bug fix	5-10 min of refactoring
Small feature	15-30 min refactoring affected code first
Large feature	Plan 1-2 days for refactoring
Code Review	Note smells for next refactoring session

---

Summary

Principle	Note
Test first	Refactoring without tests is gambling
Small steps	One refactoring operation at a time
Frequent commits	One commit per step, easy to rollback
Daily habit	No “refactoring month”
Boy Scout rule	Improve a little every time

Refactoring is not about “waiting until the code is terrible and then doing a big overhaul” — it is about “making it a little better every time you pass through.” A codebase that improves 1% every day, versus one that accumulates 1% technical debt every day, will be vastly different in six months.

Need code refactoring or technical consulting? Contact us — tell us about your project scale and pain points, feasibility within 24 hours.