Refactoring Legacy Java Code: A Step-by-Step Guide

Рефакторинг legacy кода на Java: пошаговое руководство

Working with legacy code in Java is one of the most common and challenging tasks developers face. Such code often lacks tests, is written in a monolithic style, and contains numerous antipatterns. However, completely rewriting the system is expensive and risky. It is much more effective to apply methodical refactoring. In this article, we will break down a practical approach to refactoring legacy Java code that will make it cleaner, safer, and more maintainable.

1. Preparation: Analysis and Creating a "Safety Net"

Before changing the code, it is necessary to understand what it does and how not to break the existing logic. The main principle of refactoring legacy code is not to change behavior. To do this, we need to create a "safety net" — a set of tests.

Start by studying the code. Find the entry points (methods that are called from outside) and try to determine the expected results. Even if the code is poorly written, it does something correctly.

After analysis, write Characterization Tests. These are tests that capture the current behavior of the code. They do not check if the logic works correctly, but only document what is happening now.

Example: we have a monster class that processes orders.

public class OrderProcessor {    public void process(Order order) {        // 200 lines of spaghetti code        if (order.getTotal() > 100) {            order.setStatus("VIP");        } else {            order.setStatus("STANDARD");        }        // ... a lot of other logic    }}

We don't know what's inside, but we can write a test:

@Testpublic void testProcessOrderWithHighTotal() {    // Given    Order order = new Order();    order.setTotal(150);    OrderProcessor processor = new OrderProcessor();

    // When    processor.process(order);

    // Then (capturing current behavior)    assertEquals("VIP", order.getStatus());}

Run the tests. If they pass, you have captured the current behavior. Now you have protection against regression.

2. Extract Method

The safest and most effective refactoring for large methods. The idea is simple: take a fragment of code that does one thing and extract it into a separate method with a clear name.

Consider an example of bad code:

public double calculateEmployeePay(Employee emp) {    double basePay = emp.getBasePay();    double overtimePay = 0;    if (emp.getHoursWorked() > 40) {        overtimePay = (emp.getHoursWorked() - 40) * basePay * 1.5;    }    double tax = basePay * 0.13;    double insurance = 5000;    return basePay + overtimePay - tax - insurance;}

Here, the calculation of overtime, taxes, and insurance are mixed together. Let's separate them:

public double calculateEmployeePay(Employee emp) {    double basePay = emp.getBasePay();    double overtimePay = calculateOvertimePay(emp, basePay);    double tax = calculateTax(basePay);    double insurance = getInsuranceCost();    return basePay + overtimePay - tax - insurance;}

private double calculateOvertimePay(Employee emp, double basePay) {    if (emp.getHoursWorked() > 40) {        return (emp.getHoursWorked() - 40) * basePay * 1.5;    }    return 0;}

private double calculateTax(double basePay) {    return basePay * 0.13;}

private double getInsuranceCost() {    return 5000;}

Now each method is responsible for one task. The code has become more readable and easier to test individually.

3. Removing Duplication (DRY)

Legacy code often suffers from copy-paste. The same piece of logic can appear in different classes. This is dangerous: when requirements change, you might forget to fix one of the duplicates.

Suppose, in two different servic