Длинный метод, большой класс

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

Эта переформулировка важна, потому что говорит, где резать. Будь проблема в размере, ты бы делил по середине. Поскольку проблема в смешанных обязанностях, ты режешь там, где обязанности меняются, — даже если это оставит один кусок на 80 строк, а другой на 8. Цель — шов, а не число строк.

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

// Сигнал 1: ты листаешь, чтобы прочитать один логический юнит (он не влезает на экран)
// Сигнал 2: "and" прячется в имени → две работы в одной
function validateAndPersistAndNotify(order: Order) { /* ... */ }

// Сигнал 3: класс копит поля экземпляра, которые делят немногие методы
class OrderService {
  private db; private mailer; private taxRates; private inventory;
  private pdfRenderer; private analytics; private retryPolicy;
  // 7 коллабораторов → это как минимум 7 вещей
}

// Сигнал 4: глубокая вложенность — блоки на 4+ уровня означают скрытые подпроцедуры
if (a) { for (const x of xs) { if (b) { try { /* ... */ } catch {} } } }

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

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

// до: одна стена, ты читаешь строку за строкой, чтобы узнать, что он делает
function checkout(cart: Cart, user: User) {
  // ...40 строк валидации...
  // ...30 строк расчёта цены...
  // ...25 строк платежа...
  // ...20 строк исполнения заказа...
}

// после: тело — это рассказ; детали уходят на уровень ниже
function checkout(cart: Cart, user: User) {
  validate(cart, user);
  const price = priceOf(cart, user);
  const charge = chargePayment(user, price);
  fulfil(cart, charge);
}

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

Выделение класса: когда поля группируются, второй объект просится наружу. Большой класс — обычно два или три класса, носящих одно имя. Подсказка — в сигнале 3 из шага 2: если половина полей и трогающих их методов касается налога, а другая половина — письма, то это два связных подмножества, делящих scope по случайности. Выдели кластер в собственный класс и пусть оригинал делегирует.

// до: OrderService знает расчёт налога И форматирование письма И аналитику
class OrderService { /* taxRates, mailer, templates, analytics, ...  */ }

// после: каждая обязанность — собственный связный юнит
class TaxCalculator { taxFor(amount: number, region: Region): number { /* ... */ } }
class OrderMailer   { sendConfirmation(order: Order): void { /* ... */ } }

class OrderService {
  constructor(private tax: TaxCalculator, private mailer: OrderMailer) {}
  place(order: Order) {
    const total = this.tax.taxFor(order.subtotal, order.region) + order.subtotal;
    this.mailer.sendConfirmation({ ...order, total });
  }
}

Теперь изменение налогового правила трогает TaxCalculator и больше ничего; команда писем работает в OrderMailer, не читая налоговый код. Радиус поражения каждого вероятного изменения схлопнулся до одного связного юнита — а в этом и весь экономический смысл разбиения раздувателя.

Режим отказа: дробление, а не выделение. Любительское прочтение «разбивай длинные методы» — это сделать всё коротким. Так метод на 200 строк становится двадцатью однострочными методами — step1, step2, doThing, doThingHelper — и теперь ты прыгаешь двадцать раз, чтобы проследить один поток, без концептуального уровня, на котором можно остановиться. Ты переместил сложность в граф вызовов; ты её не уменьшил. Хуже того, фрагменты, не делящие никакой обязанности, теперь маскируются под собратьев, что активно вводит в заблуждение следующего читателя.

Дисциплина, которая это предотвращает: каждый выделенный юнит должен называть обязанность, которую узнал бы доменный человек — validate, priceOf, chargePayment, — а не позицию в исходном файле. Если ты не можешь дать куску честное, односмысловое имя, ты нашёл кусок кода, который ещё не соответствует одной идее, и нарезка лишь прячет это. Режь по швам, которые что-то значат. Когда настоящего шва нет, оставить связный метод на 60 строк целым лучше, чем раздробить его в шум.