Капстоун I: инвентаризация запахов

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

// Vague: "the checkout file is a mess" → no agreement possible, no plan.
// Precise (one inventory row):
//   smell:    primitive obsession
//   location: total/tax/discount modelled as bare `number`
//   why:      every site re-derives currency, scale, rounding → bugs disagree
//   refactor: introduce a Money value object

Дисциплина: каждая строка говорит что (запах), где (строки) и почему это дорого — и никогда не прыгает сразу к диффу.

Найди запах — имя без координат бесполезно. «Где-то есть одержимость примитивами» нельзя ни отревьюить, ни отрефакторить, ни проверить. Инвентаризация называет символ, строки и, что критично, разброс: литерал 0.2 в одной функции локален; то же правило, скопированное в рендеринг, выставление счетов и отчётность, — это разрозненные правки: одно логическое изменение, втиснутое во множество физических правок. Именно разброс превращает маленький запах в дорогой.

// Same rule, different cost — locate the SPREAD, not just one instance.
function renderInvoice(o: Order)  { return o.subtotal * 0.2; } // tax here
function emailReceipt(o: Order)   { return o.subtotal * 0.2; } // ...and here
function monthlyReport(o: Order)  { return o.subtotal * 0.2; } // ...and here
// One business decision ("tax is region-based now") → three edits, miss one → silent bug.

Местоположение запаха плюс его разброс — вот что позволяет оценить радиус поражения, а это и есть вход для ранжирования.

Ранжируй по влиянию на стоимость изменения, а не по уродству. Не каждый запах заслуживает одинаковой срочности. Ранжируй каждую строку по вероятность изменения × радиус поражения, если оно придёт. switch (payment.type), разросшийся до пяти веток и продублированный в трёх файлах, в модуле, чья единственная причина существовать — «мы всё время добавляем способы оплаты», — наверху списка: ожидаемое изменение частое, а его радиус поражения широкий. Слегка длинный, но стабильный хелпер, которого не трогали год, ранжируется низко, даже если это самое уродливое на экране, — рефакторить его незачем, потому что изменение не придёт.

// Ranking is a product, not a beauty contest.
//   type-switch on payment, ×3 files   →  likely change: HIGH,  blast radius: WIDE   → P0
//   primitive `Money` everywhere        →  likely change: MED,   blast radius: WIDE   → P1
//   long render function, stable        →  likely change: LOW,   blast radius: LOCAL  → P3

Это и есть senior-ход: ты сортируешь беспорядок относительно роадмапа, чтобы усилия легли туда, где следующее изменение реально болит.

Привяжи инвентаризацию к базе, иначе не докажешь, что что-то улучшил. Причина, по которой диагноз идёт раньше лечения, — не бюрократия, а измеримость. Если начать с правок, исходное поведение и исходный список запахов оба исчезают, и у «стало лучше?» нет ответа. Поэтому до любой структурной правки должны существовать две вещи: записанная инвентаризация (чтобы ты знал, какие дефекты целил) и сеть характеризующих тестов, пришпиливающая текущее поведение (чтобы рефакторинг не смог изменить поведение, пока ты «прибираешься»). Инвентаризация говорит, что ты намерен убрать; тесты говорят, что убрал ты только это.

// Baseline first. Pin behaviour you don't yet understand — bugs included — so the
// refactor is provably behaviour-preserving and the smell list is the scorecard.
test("checkout total for a 2-item USD cart, card payment", () => {
  expect(checkout(sampleCart, { type: "card" })).toEqual(EXPECTED_SNAPSHOT);
});
// Now each refactor either removes an inventory row and stays green, or it's wrong.

Инвентаризация + характеризующие тесты = состояние «до», относительно которого можно рефакторить. Без них рефакторинг неотличим от переписывания по вайбам.