Капстоун II: инкрементальный рефакторинг

Сначала сеть: характеризационные тесты фиксируют, что модуль делает сегодня, ещё до того как ты поймёшь почему. Нетестированный легаси не рефакторят, читая его пристальнее. Его фиксируют. Характеризационный тест утверждает текущее наблюдаемое поведение модуля — не то поведение, которое ты бы хотел, — так что любой последующий структурный ход, меняющий вывод, мгновенно делает тест красным.

// characterize.test.ts — написан ДО любого структурного изменения.
// Мы пока не доверяем округлению или арифметике комиссии; мы фиксируем то, что код ДЕЛАЕТ.
test("card order total with tax and fee", () => {
  const out = processOrder({ items: [{ price: 1000, qty: 2 }], paymentType: "card" });
  expect(out.total).toBe(2070);   // 2000 + 5% налога + 2% комиссии карты, как есть
  expect(out.currency).toBe("USD");
});

test("invoice order skips the card fee", () => {
  const out = processOrder({ items: [{ price: 999, qty: 3 }], paymentType: "invoice" });
  expect(out.total).toBe(3147);   // что бы он сейчас ни считал — зафиксируй это
});

Число 2070 может кодировать баг. И это нормально — ты сейчас его не чинишь, ты его фиксируешь. Характеризационный тест, закрепляющий неверное значение, всё равно делает свою работу: он гарантирует, что твой рефакторинг сохраняет поведение. Баг почини позже, отдельным коммитом, когда структура станет достаточно чистой, чтобы чинить безопасно. Ни одной структурной правки не происходит, пока сеть не зелёная.

Выделяй под зелёным, по одному ходу на коммит — и пиши сообщение, которое говорит «refactor». Когда сеть на месте, первые ходы — дешёвые механические из каталога. Вытащи переплетённые блоки processOrder в именованные методы, затем подними связный кластер в класс. Каждый — свой коммит; набор зелёный до и после каждого.

// commit "refactor: extract calcTax / calcFee"  — поведение идентично
function calcTax(subtotal: number): number { return Math.round(subtotal * 0.05); }
function calcFee(subtotal: number, paymentType: string): number {
  return paymentType === "card" ? Math.round(subtotal * 0.02) : 0;
}

// commit "refactor: extract OrderProcessor class"  — то же тело, новый дом
class OrderProcessor {
  process(order: OrderInput): OrderResult {
    const subtotal = order.items.reduce((s, i) => s + i.price * i.qty, 0);
    const tax = calcTax(subtotal);
    const fee = calcFee(subtotal, order.paymentType);
    return { total: subtotal + tax + fee, currency: "USD" };
  }
}

Ничего хитрого здесь нет, и в этом весь смысл. Это сохраняющие поведение ходы; зелёная сеть доказывает это после каждого. Если тест краснеет, ты откатил один маленький коммит, а не неделю работы — радиус поражения любой ошибки ровно один ход.

Введи объекты-значения, чтобы убрать одержимость примитивами — поведение всё ещё не меняется. Модуль передаёт сырые number для денег и сырые string для id; это одержимость примитивами, и именно поэтому логика округления и валюты протекла повсюду. Заверни их. Ход всё ещё рефакторинг: Money обязан вычислять те же числа, что уже зафиксировала сеть.

// commit "refactor: introduce Money value object"
class Money {
  private constructor(readonly cents: number, readonly currency: "USD") {}
  static usd(cents: number): Money { return new Money(Math.round(cents), "USD"); }
  add(o: Money): Money { return Money.usd(this.cents + o.cents); }
  percent(p: number): Money { return Money.usd(Math.round(this.cents * p)); }
}

// commit "refactor: introduce OrderId" — типизированный id, больше никаких голых string
class OrderId { private constructor(readonly value: string) {}
  static of(v: string): OrderId { return new OrderId(v); } }

Поскольку Money.usd округляет ровно там же, где это делал старый код, зафиксированное 2070 по-прежнему держится — тест остаётся зелёным. Выигрыш в том, что округление теперь живёт в одном месте, а не выводится заново на каждом месте вызова, — именно это удешевляет следующее изменение. Принципиально, что ты не «починил» округление, раз уж был там; если округление неверно, это отдельный, более поздний, меняющий поведение коммит.

Замени switch по типу платежа полиморфизмом, затем инвертируй зависимость хранилища за портом. Остаются два структурных хода, и они — высокоценные. Сначала switch по paymentType, расползающийся по модулю, становится маленькой иерархией стратегий — Open/Closed: новый тип платежа — это новый класс, а не правка switch в пяти файлах.

// commit "refactor: replace paymentType switch with PaymentMethod polymorphism"
interface PaymentMethod { fee(subtotal: Money): Money; }
class Card    implements PaymentMethod { fee(s: Money) { return s.percent(0.02); } }
class Invoice implements PaymentMethod { fee(s: Money) { return Money.usd(0); } }
const methods: Record<string, PaymentMethod> = { card: new Card(), invoice: new Invoice() };

Затем инвертируй зависимость хранилища. OrderProcessor сейчас import-ит конкретный db; это стрелка в неправильную сторону. Определи порт OrderRepository, которым владеет процессор, и сделай базу адаптером, его реализующим, — высокоуровневая политика перестаёт зависеть от низкоуровневой детали.

// commit "refactor: introduce OrderRepository port"
interface OrderRepository { save(id: OrderId, result: OrderResult): Promise<void>; }
// адаптер живёт на краю; процессор зависит от интерфейса, а не от `db`
class PostgresOrderRepository implements OrderRepository { /* старый SQL, перенесён */ }

Оба хода сохраняют поведение: те же комиссии, те же сохранённые строки, та же зелёная сеть. Они меняют лишь кто от кого зависит.