Code Refactoring Techniques That Actually Ship Clean

Messy code ships. Clean code also ships. The difference is what happens six months later when the requirements change and nobody wants to touch the module you wrote.

Code refactoring techniques are not about aesthetics. They are about the time you get back, or do not, when a function that was supposed to take 20 lines has quietly grown to 300 and nobody remembers why.

Here is what I have actually used over four years of Rust and Go backend work, ordered by how disruptive they are to a running codebase. Low blast radius first.

The One Rule Before You Start

Refactor only code that has tests. Not "probably tested somewhere," not "the integration suite hits it." Green unit tests that run in under 30 seconds and tell you exactly what broke.

This is not a suggestion. It is the only thing separating a productive refactoring session from a two-day debugging session that reintroduces the original bug in a different location. If the code has no tests, write them first. That is also refactoring work. It is just the kind nobody calls refactoring.

One more rule: version control with atomic commits. Every technique below should be one commit. The message says what technique you applied, not "cleanup." If something breaks on staging, you roll back one commit, not three.

Extract Method: The One You Use Every Day

Extract Method is what you reach for first. You have a function doing three things. You pull out one of them into its own function with a name that says what it does.

The trigger: any method longer than you can read on one screen without scrolling. The practical threshold I use is 40 lines. Beyond that, something can be named and extracted.

The mechanics:

// Before: one function doing three unrelated things
func processOrder(order Order) error {
    // validate fields (15 lines)
    // calculate totals (20 lines)
    // persist to database (12 lines)
    return nil
}

// After: each concern is named and testable
func processOrder(order Order) error {
    if err := validateOrder(order); err != nil {
        return err
    }
    total := calculateOrderTotal(order)
    return persistOrder(order, total)
}

Extract Method also does something most developers miss: it forces you to name things. If you cannot name the extracted function without using "and" or "or," it is still doing too much.

Skip if: the function is genuinely simple and extraction would scatter logic across three files for no gain. Not every 30-line function needs surgery. The test is whether the extracted piece has a meaningful name on its own.

In practice, I run Extract Method at least twice a week. It is the lowest-risk, highest-payoff technique on this list. An IDE does it in two keystrokes. The resulting code is smaller, each piece is individually testable, and the next developer reading it does not need to hold the whole function in their head at once.

Rename Variable: Free Cognitive Load Reduction

This costs nothing and pays back immediately. A well-named variable eliminates the need for a comment explaining what it holds. A variable called d in a function that runs for 200 lines is technical debt measured in minutes per future reader.

The rename: d becomes invoiceDueDate. Done.

Modern IDEs handle this in one keystroke: F2 in VS Code, Shift+F6 in IntelliJ. The refactoring is instant. The compounding benefit persists for the lifetime of the codebase.

Where this matters most: code that crosses module boundaries, code that other developers touch, code you will read six months from now in a pull request review under time pressure. The cognitive overhead of decoding abbreviated names is real and cumulative.

A naming rule I keep: if the variable name describes its type rather than its role, rename it. string becomes customerEmail. list becomes pendingInvoices. data becomes whatever the data actually represents.

Replace Temp with Query

You have a temporary variable that holds the result of an expression. The variable is used once or twice. Replace it with a method call.

// Before
basePrice := item.Quantity * item.UnitPrice
if basePrice > 1000 {
    return basePrice * 0.95
}
return basePrice

// After
if basePrice() > 1000 {
    return basePrice() * 0.95
}
return basePrice()

func (item Item) basePrice() float64 {
    return item.Quantity * item.UnitPrice
}

The gain: the calculation is now testable in isolation and reusable across any method that needs it. The cost: one extra function call. In any language with a compiler or JIT, this cost is zero in production. If you are writing performance-critical hot paths, profiler-verified ones, skip this technique there and document why.

I use this most in domain logic where the same derived value appears across multiple methods. Three functions all recalculating basePrice differently is a bug waiting to happen when the pricing formula changes. One method means one place to update.

The secondary benefit is readability in conditions. if basePrice() > discountThreshold() reads as an intention, not a computation. You understand the condition without parsing the arithmetic.

Replace Conditional with Polymorphism

You have a switch statement or a chain of if/else blocks branching on object type. Each branch does something different for each type. This is the pattern that signals a missing abstraction.

The fix: create a base class or interface that handles the common contract. Each type gets its own implementation.

// Before: type switch with growing branches
func calculateShipping(order Order) float64 {
    switch order.ShippingType {
    case "standard":
        return order.Weight * 0.5
    case "express":
        return order.Weight * 1.2
    case "overnight":
        return order.Weight * 2.5
    }
    return 0
}

// After: each type owns its behavior
type ShippingCalculator interface {
    Calculate(weight float64) float64
}

type StandardShipping struct{}
func (s StandardShipping) Calculate(weight float64) float64 { return weight * 0.5 }

type ExpressShipping struct{}
func (e ExpressShipping) Calculate(weight float64) float64 { return weight * 1.2 }

type OvernightShipping struct{}
func (o OvernightShipping) Calculate(weight float64) float64 { return weight * 2.5 }

Adding a new shipping type now means adding a new struct. It does not mean touching the existing switch and risking a regression in the standard case. The Open/Closed Principle, in practice.

This technique has a higher blast radius than Extract Method. It reorganizes responsibilities between types. Apply it when the switch statement has more than three branches and when new branches are being added regularly. If it is a stable two-case condition, a simple if/else is fine. Do not reach for polymorphism because it sounds more sophisticated.

The tell that this refactoring is warranted: you just added a fourth branch and noticed you also had to scroll through the function to find where the third one was. The cognitive cost of reading that switch grows linearly with the number of cases. An interface grows by one file.

Introduce Parameter Object

You have a method that takes six parameters. Three of them always appear together and relate to the same concept. Group the three into a struct.

// Before
func createInvoice(
    customerId string,
    dueDate time.Time,
    currency string,
    lines []InvoiceLine,
) Invoice

// After
type InvoiceParams struct {
    CustomerID string
    DueDate    time.Time
    Currency   string
}

func createInvoice(params InvoiceParams, lines []InvoiceLine) Invoice

The practical benefit is not just cleaner call sites. It is that InvoiceParams becomes a stable type you can validate, log, and pass around. You can add a Region field later without changing the signature of every function that calls createInvoice. The call sites pass a struct, not a positional argument list where swapping dueDate and customerId compiles fine and is wrong.

Skip this when the parameters are genuinely unrelated and grouping them would create an artificial object with no real cohesion. A struct named MiscParams is not an improvement.

I reach for this technique when I see tests constructing the same parameter combination more than three times. That repetition signals that the combination has a name worth assigning.

Substitute Algorithm

The existing implementation works. It is also wrong, not logically, but architecturally. You learned a better way to structure the computation. You want to replace the whole thing, not patch it.

This is the highest blast radius refactoring on this list. You are not adjusting a method. You are replacing how a problem is solved.

The prerequisite: a complete test suite that describes what the algorithm must do, independent of how it does it. You run the old implementation against the tests: green. You write the new implementation. You run the tests again: green. You delete the old code.

I used this once last year, migrating a hand-rolled pagination cursor implementation to a keyset-based approach. The tests caught two edge cases the old implementation had accidentally correct behavior for. Without the tests, the migration would have shipped with two silent regressions that only surfaced under load.

Substitute Algorithm is not for Tuesday afternoon. It is for when you have a clear design reason, full test coverage, and a timeboxed window with staging verification before the next deploy.

On AI-Assisted Refactoring

The tooling is genuinely useful for Extract Method and Rename Variable at scale: finding every call site, generating the replacement, opening a PR across multiple files. Sourcegraph Batch Changes and OpenRewrite for JVM projects do this across a repo of any size without the human-error rate of manual search-and-replace.

The honest picture on AI and code quality: a 2025 study from the METR alignment research group found experienced developers using AI assistance were measurably slower on tasks involving fundamental structural changes. The tooling improved output on mechanical tasks and hurt it on design-level tasks. That finding is consistent with my experience.

For Replace Conditional with Polymorphism or Substitute Algorithm, the design judgment is yours. The AI can generate the boilerplate once you know what you want. That division of labor works. Do not reverse it and expect the tool to decide when polymorphism is the right abstraction.

What AI does well in this context: it can spot candidate methods for extraction by surfacing high cyclomatic complexity, flag variables named with single letters, and identify duplicated expressions across files. SonarQube and CodeScene do this without the hallucination risk. Use them in your CI pipeline to surface where to look, not to decide what to do.

When Refactoring Is the Wrong Move

Not every messy function deserves cleanup this week.

If the code is scheduled to be deleted in the next quarter, skip the refactoring. If there are no tests and no time to write them, document the debt and move on. If you are the only person who will ever touch this module, the cost-benefit calculus changes.

Refactoring is a bet on future change. The bet pays off when the code is touched again. Legacy code that has been stable for three years and will remain stable is not a problem to solve. It is a stable system doing its job.

The code that deserves the most attention is the code that is changing. Your most active modules, your most-touched files, your most-reviewed functions. That is where clarity compounds the fastest.

The Order Matters

Start with Rename Variable and Extract Method. They are safe, fast, and compound over time. Move to Replace Temp with Query and Introduce Parameter Object when the codebase is stable and tested. Use Replace Conditional with Polymorphism and Substitute Algorithm only when test coverage is solid and the design problem is clear.

Six techniques. One rule: tests first, always. No shortcuts on that part.