What Is Refactoring?

1Concept / Definition

Martin Fowler defines refactoring in two forms:

• Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour.
• Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behaviour.

2Why It Exists

The term emerged in the Smalltalk community (Opdyke's 1992 thesis, Beck and Cunningham's practice) and was popularised by Fowler's Refactoring (1999, 2nd edition 2018). Before it, "cleaning up code" meant risky, informal edits or big rewrites. Refactoring made improvement systematic: a catalogue of named transformations with precise mechanics, each safe on its own. This allowed Extreme Programming's idea of evolutionary design — design that grows incrementally with the code instead of being completed up front.

3Core Concepts

3.1 Behaviour preservation

"Observable behaviour" means what the users of the code can see: return values, outputs, side effects, exceptions and — for APIs — the public contract. Internal details (method names, class structure, private fields) may change freely.

Behaviour preservation is judged at a boundary you choose. Renaming a public method is behaviour-preserving for the whole application (all callers updated) but not for external consumers of a published library. The wider the audience of an interface, the stricter the rules — which is why published APIs need deprecation cycles rather than refactorings.

// Before — correct, but hard to read
public double total(List<Line> lines, String code) {
    double t = 0;
    for (Line l : lines) t += l.qty() * l.price();
    if ("VIP".equals(code)) t *= 0.9;
    return Math.round(t * 100) / 100.0;
}
 
// After — same results for every input, clearer structure
public double total(List<Line> lines, String customerCode) {
    double subtotal = subtotal(lines);
    double discounted = applyVipDiscount(subtotal, customerCode);
    return roundToCents(discounted);
}
private double subtotal(List<Line> lines) {
    return lines.stream().mapToDouble(l -> l.qty() * l.price()).sum();
}
private double applyVipDiscount(double amount, String customerCode) {
    return "VIP".equals(customerCode) ? amount * 0.9 : amount;
}
private double roundToCents(double amount) { return Math.round(amount * 100) / 100.0; }

Note a subtle trap: replacing the loop with mapToDouble(...).sum() changes the order of floating-point additions in some implementations, which can alter results in the last digit. Refactoring with doubles needs tests that pin the exact results — one reason money should be BigDecimal or a Money value object (a change that does alter behaviour and belongs in a separate commit).

3.2 Structural improvement

Refactoring aims at structure that makes the next change easier.

Structural improvement is directional — towards a design that fits the current and next requirements, not towards an abstract ideal. Refactoring the same code "back" (Inline Method after Extract Method) is legitimate when the earlier structure no longer fits.

4How It Works Internally — The Two Hats and the Micro-Cycle

Kent Beck's two hats metaphor: when adding function, you add tests and behaviour but don't restructure; when refactoring, you restructure but don't add behaviour. You switch hats often — sometimes every few minutes — but wear only one at a time.

1. Spot a smell or an obstacle to the next change.

2. Green: make sure the relevant tests pass.

3. Step: apply one small refactoring (ideally an IDE-automated one).

4. Verify: compile and run fast tests.

5. Commit (or continue with the next step); repeat until the structure is right.

Separating commits makes reviews faster (refactoring diffs can be large but mechanical) and makes rollbacks precise.

4ADeep Dive — Refactoring vs Rewriting vs Re-architecting

The lesson from decades of failed rewrites (Netscape 6 is the classic example) is that incremental refactoring and strangling almost always beat a rewrite: the system keeps delivering value, knowledge embedded in the old code is preserved, and each step can be verified. Large-scale structural changes are therefore best treated as long sequences of refactorings with a clear direction (see Chapter 4 and Volume VII).

Refactoring at scale with tools. OpenRewrite applies refactorings as recipes across many repositories — for example migrating JUnit 4 to 5 or javax.* to jakarta.* — producing behaviour-preserving diffs reviewed like manual refactorings.

5APIs / Features / Syntax

<!-- OpenRewrite: run a recipe that modernises code across a project -->
<plugin>
  <groupId>org.openrewrite.maven</groupId>
  <artifactId>rewrite-maven-plugin</artifactId>
  <configuration>
    <activeRecipes>
      <recipe>org.openrewrite.java.migrate.UpgradeToJava25</recipe>
    </activeRecipes>
  </configuration>
</plugin>

6Practical Examples

6.1 Classifying changes in a pull request

A pull request titled "Refactor pricing" contains: extracted methods, renamed classes, and a changed discount threshold. Reviewers ask the author to split it: the threshold change is a behaviour change needing its own tests and product approval.

6.2 Refactoring a record's accessor usage

// Before: callers compute the same derived value everywhere
long nights = ChronoUnit.DAYS.between(stay.checkIn(), stay.checkOut());
 
// After: Move the computation into the record (behaviour-preserving)
public record Stay(LocalDate checkIn, LocalDate checkOut) {
    public long nights() { return ChronoUnit.DAYS.between(checkIn, checkOut); }
}
long nights = stay.nights();

6.3 Worked example — a refactoring session step by step

The task: add a "corporate" discount to InvoiceCalculator.total(). The method is 90 lines with nested conditionals. With the two hats:

public sealed interface DiscountPolicy
        permits NoDiscount, VipDiscount, CorporateDiscount {
    Money apply(Money subtotal);
}
public record NoDiscount() implements DiscountPolicy {
    public Money apply(Money s) { return s; }
}
public record VipDiscount() implements DiscountPolicy {
    public Money apply(Money s) { return s.times(new BigDecimal("0.90")); }
}
// step 5: the feature
public record CorporateDiscount(BigDecimal rate) implements DiscountPolicy {
    public Money apply(Money s) { return s.times(BigDecimal.ONE.subtract(rate)); }
}

Kent Beck's summary of this approach: make the change easy (this may be hard), then make the easy change. Steps 1–4 took most of the time; step 5 took minutes and touched no existing logic.

6.4 Worked example — what went wrong in a "refactoring" that broke production

In Java/Spring applications, observable behaviour includes framework semantics: persistence mappings, serialisation names, proxy-based annotations, reflection-based wiring. Refactorings touching these need integration tests, not only unit tests.

6.5 The core refactoring catalogue at a glance

Fowler's catalogue (2nd edition) names more than 60 refactorings. The table below lists the ones used most often in Java codebases, grouped by the structural improvement they achieve, with IntelliJ IDEA support.

Knowing the names matters: they make intentions explicit in commit messages and reviews ("Extract Class: PriceCalculator from OrderService"), and each name implies known mechanics and risks.

6.6 Measuring the impact of refactoring

Refactoring is justified by its effect on future change. Useful before/after evidence:

Combining one structural metric with one delivery metric is usually enough to show stakeholders that refactoring time was an investment, not a cost.

7Common Problems & Mistakes

• Calling any change "refactoring" — hiding behaviour changes in refactoring commits.
• Mixing hats — adding features while restructuring.
• Large, long-lived refactoring branches — merge conflicts and risk.
• Refactoring without tests — no way to know behaviour was preserved.
• Ignoring framework-level behaviour (JPA, Jackson, Spring proxies).
• Refactoring code that will be deleted or never changed again.

8Performance & Production Considerations

9Architecture & Design Considerations

• Treat refactoring as part of every task, not as a separate project needing permission.
• Use evolutionary design: defer structure until requirements justify it, then refactor towards it.
• Define team conventions: separate commits, refactoring-friendly reviews, tests first.
• At system scale, plan large restructurings as sequences of small refactorings with a target architecture.

10Interview Questions & Answers