Капстоун III: измеряем до и после

Выбери метрику, о которой был весь трек: правки на одно логическое изменение. Эстетика («чище», «приятнее») неопровержима и не то, за что платит кодовая база. Честная мера — та, что назвал юнит 00, — усиление изменения: сколько мест нужно найти и поправить ради одного концептуального изменения и сколько из них легко пропустить. Оцени два целевых изменения по обоим вариантам.

// BEFORE — "add a new payment method (Klarna)"
//   touch PaymentForm.tsx      (new branch in a switch)
//   touch checkout.ts          (new branch in a switch)
//   touch refund.ts            (new branch in a switch)
//   touch reconcile.ts         (new branch — easy to forget → silent bug)
//   → 4 edits, 4 chances to miss one

// AFTER
//   add  KlarnaProvider implements PaymentProvider   (1 new file)
//   register it in the providers map                 (1 line)
//   → 1 localized add + 1 registration, 0 existing switches touched

Число, которое упало — с 4 разбросанных правок до одного локального добавления, — и есть результат. Всё остальное в этом уроке объясняет, почему оно упало.

Покажи, что связанность упала, конкретно — посчитай вещи, которые обязаны меняться вместе. «Слабее связано» — это утверждение; коннасценция и направление зависимостей — это доказательство. Раньше четыре модуля были конаскентны строкам с именами способов оплаты: каждый switch обязан был знать каждый тип оплаты, поэтому четыре менялись вместе. После они зависят от одной абстракции PaymentProvider и ничего не знают ни друг о друге, ни о Klarna.

// BEFORE: every site is coupled to the full set of payment names
function fee(method: string) {
  switch (method) {            // checkout.ts knows: card, paypal, klarna…
    case "card":   return 0.029;
    case "paypal": return 0.034;
    // add klarna here AND in three other switches
  }
}

// AFTER: sites depend on the interface; providers are independent
interface PaymentProvider { fee(): number; charge(amt: number): Promise<Receipt>; }
const providers: Record<string, PaymentProvider> = { card, paypal, klarna };

Измеримое падение: число файлов, обязанных меняться вместе ради «нового способа оплаты», ушло с 4 до 0 существующих + 1 новый. Это связанность, выраженная в числах, — не ощущение.

Докажи, что появились новые тестовые швы — написав тест, который раньше был невозможен. Шов — это место, где можно подменить поведение, не редактируя тестируемый код. Раньше комиссии жили внутри switch, к которому добирались только прогоняя весь checkout, поэтому тесту на комиссию нужны были фейковая корзина, фейковый пользователь и заглушка сети. После KlarnaProvider.fee() — чистый юнит, который можно проверить напрямую; шов — это интерфейс.

// AFTER — a test that the BEFORE shape could not express in isolation
test("klarna fee is 1.9%", () => {
  expect(new KlarnaProvider().fee()).toBe(0.019);
});

// region-based tax got a seam too — inject the rate table, no globals
test("tax for EU region", () => {
  const tax = taxFor(100, "EU", { EU: 0.2, US: 0.0 });
  expect(tax).toBe(20);
});

Метрика: тестируемые юниты ушли от «логика комиссии достижима только через полный поток checkout» к «комиссия и налог проверяемы в двухстрочных тестах». Страховочная сеть из юнита 10 — это то, что сделало рефакторинг безопасным; эти швы — то, что рефакторинг произвёл.

Покажи, что связность выросла — сгруппируй второе целевое изменение и смотри, как оно ложится в один модуль. Связность — это «то, что меняется вместе, живёт вместе». Второе изменение капстоуна — налог по региону — это зонд. Раньше литерал 0.2 был размазан по прайсингу, выставлению счетов и отчётам (низкая связность: одно правило, много домов). После правило живёт в tax.ts, поэтому изменение региона — это одна правка там, и больше ничто не двигается.

// AFTER — one home for the tax rule; region change is local to it
// tax.ts
export function taxFor(amount: number, region: Region, rates: RateTable): number {
  return amount * rates[region];          // ← region logic changes ONLY here
}

Измерь это как правки до/после для «добавить налог по региону»: с 3 разбросанных мест (а пропущенное становится багом) до 1. Высокая связность — это ровно то, что делает ожидаемое изменение дешёвым, а это единственное определение «хорошего», которым трек пользуется с юнита 00.

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

// STOP signal: re-score the two target changes.
//   "new payment method"  → 1 local add        ✓ cheap
//   "region-based tax"     → 1 local edit       ✓ cheap
// Both targets met → STOP. Do NOT now abstract currency, rounding,
// or a plugin system "while we're in here" — no change is asking for them.

Критерий остановки конкретен: назови изменения, которые ты ожидаешь, рефактори, пока они не станут одиночными локальными правками, и остановись. «Достаточно хорошо для ожидаемых изменений» бьёт «идеально», потому что идеально тратит сегодняшний бюджет на изменения, которые могут никогда не прийти, — ровно ту ошибку, о которой юнит 00 предупреждал, говоря, что изменяемость — это ставка, а не абсолют.