Код с запашком

Код с запашком — симптом, а не болезнь. За повтором в двух классах может стоять пропущенная абстракция, за длинным методом — смешанные обязанности, за «умным» переключателем — отказ от наследования в пользу условий^[1]. Сам по себе запах не доказывает наличия ошибки и не гарантирует её отсутствия: это признак, требующий анализа в контексте программы.^[2]

Метафора возникла из практики: опытный разработчик замечает проблемный участок за секунды, не формулируя обоснование, — так человек замечает неприятный запах раньше, чем найдёт его источник^[2]. Фаулер подчёркивал, что формальное определение «что такое запашок» невозможно: критерий — субъективная реакция человека, знакомого с чистым кодом, и именно поэтому каталог запахов дополняет, а не заменяет метрики^[1]. Практический смысл термина — общий словарь для обсуждения качества: команда называет запах по имени и знает, к какому рефакторингу он обычно ведёт^[5].

Запах не совпадает ни с нарушением стиля, ни с плохой метрикой. Нарушение стиля — отклонение от формального соглашения о написании, его выявляет простая проверка; запах — признак, требующий осмысления и решения человека^[1]. Показатель даёт число, но не интерпретацию: метод на сто строк в генераторе таблиц и метод на сто строк в платёжной логике «пахнут» по-разному^[6]. Поэтому практики читают метрики и запахи вместе: показатель указывает место, запах — направление исправления^[7].

Предыстория термина — инструменты перестройки Smalltalk-программ: в 1997 году Робертс, Брант и Джонсон описали рефакторинговый браузер, который находил сомнительные места кода и выполнял безопасные преобразования с проверкой корректности^[8]. Термин «запах» закрепился на вики Уорда Каннингема, где сообщество Smalltalk обсуждало признаки плохого кода^[2]. Идеи этого сообщества собрал и довёл до практики Кент Бек: его каталог приёмов Smalltalk-программирования 1997 года учил замечать «неудобные» места кода и исправлять их малыми шагами^[9].

Сам список двадцати двух запахов Фаулер и Бек составили в совместных обсуждениях, и Фаулер отмечал, что каталог появился быстрее, чем любые формальные определения^[1].

Канонический статус понятие получило в 1999 году с книгой Фаулера «Рефакторинг»: её каталог рефакторингов, раздел о запахах в котором был написан Кентом Беком, перечислил двадцать два запаха — от дублирования до иерархий, «отказывающихся» от наследования, — и для каждого подобрал список рефакторингов^[1]. Там же дано рабочее правило: не пытаться составить полный список запахов — важно умение замечать подозрительные места и знать набор преобразований^[1].

Дальнейшая история — превращение эвристики в предмет исследования. В 1998 году вышел каталог антипаттернов Брауна и соавторов, распространивший «запахи» с кода на архитектуры и процессы^[10]. В 2003 году Мянтюля, Ванханен и Лассениус предложили первую таксономию запахов и проверили, как люди реально замечают их при вычитке^[6]. Обзор Менса и Турве 2004 года включил запахи в общую картину автоматизации рефакторинга^[11].

В 2010-е годы появились количественные ответы на вопросы, которые раньше решались мнением: когда именно код начинает пахнуть^[12], насколько запахи влияют на усилия по сопровождению^[13], замечают ли их разработчики в работе^[14]. Исследователи построили детекторы на истории изменений и машинном обучении, и запахи из списка «проверь глазами» стали входом автоматических конвейеров качества^[15][7].

Классический набор примеров составляют структурные признаки. Дублирование кода — одинаковые или почти одинаковые фрагменты в нескольких местах; правка одного экземпляра при забытых остальных порождает расхождение поведения^[1]. Длинный метод — процедура, которая разрослась на десятки строк и смешивает несколько обязанностей; большой класс — «класс-бог», знающий слишком много о системе^[5]. Длинный список параметров затрудняет вызовы и провоцирует ошибки в порядке аргументов; группировка параметров в отдельный объект — типовой ответ^[1].

Другая группа — поведенческие признаки. Завистливая функция — метод, который обращается к данным чужого класса заметно больше, чем к собственным; лекарство — перенос метода в «завидуемый» класс^[5]. Оператор-переключатель, повторяющийся в разных местах, указывает на пропущенный полиморфизм: ветви условий вырождаются в подклассы^[1]. Ленивый класс и мёртвый код — лишние сущности, которые ничего не делают или почти ничего. Отдельно Фаулер трактовал как запах самого кода комментарии, поясняющие запутанный код: «когда чувствуешь потребность написать комментарий, сначала попробуй переписать код так, чтобы он стал понятнее»^[1].

Отдельная группа — запахи, мешающие изменениям: расходящиеся модификации, когда один класс приходится править по многим разным поводам, и «стрельба дробью», когда одно изменение требует правок во многих классах^[5]. Эти два признака зеркальны и указывают на неверное распределение обязанностей между классами^[1].

К запахам относят и данные, живущие не по адресу. Временное поле — атрибут объекта, нужный лишь в некоторых состояниях: класс притворяется универсальным, а на деле обслуживает один сценарий^[5]. Магические числа — неименованные константы, рассыпанные по коду; их замена именованными значениями — простейший пример рефакторинга «по запаху»^[9]. Нарушенная инкапсуляция — публичные поля и «утёкшие» коллекции — делает невозможным изменение внутреннего устройства класса без правок всех клиентов^[1].

Последнюю группу составляют запахи излишней связанности: сторонние методы, которыми один класс постоянно пользуется через чужой экземпляр, неуместная близость соседних классов, длинные цепочки вызовов вида «объект объекта объекта» и классы-посредники, которые лишь передают вызовы дальше^[5]. Все они описывают одну картину — знание одной части системы о внутреннем устройстве другой — и лечатся переносом методов и сокрытием посредников^[1].

Первая таксономия запахов появилась в 2003 году: Мянтюля и соавторы сгруппировали признаки не по синтаксическому виду, а по характеру работы, которую они осложняют^[6]. Категория «раздувальщики» объединяет методы, классы и списки параметров, разросшиеся сверх разумного; «неправильное объектно-ориентированное использование» — отказ от наследования, переключатели, классы-двойники; «препятствия изменениям» — признаки, из-за которых одна правка разрастается на многие файлы^[6]. Категории «лишнее» и «запутанность» покрывают мёртвый код, лишние комментарии и неоправданные связи между модулями^[6].

По уровню кода различают запахи метода (длинный метод, длинный список параметров), класса (большой класс, ленивый класс) и системы в целом (расходящиеся модификации, параллельные иерархии)^[5]. Уровень определяет и масштаб рефакторинга: локальное преобразование метода обычно требует меньшего числа согласований, а устранение запаха архитектуры затрагивает сборку, тесты и несколько команд^[11]. Запахи более высокого уровня обнаруживаются хуже и автоматизируются позже, поэтому практики выстраивают порядок от простых признаков к сложным^[6].

На уровне объектно-ориентированного проектирования выделяют и архитектурные запахи: класс, знающий устройство всей системы, циклы зависимостей между модулями, слои, обменивающиеся чужими данными. Такие признаки не видны в одном файле — для их поиска строят граф зависимостей проекта и анализируют его структуру^[11].

Проверять эти признаки вручную трудно: архитектурный запах проявляется не в одном файле, а в форме связей, и два инженера одного проекта могут не согласиться, является ли зависимость «чужими данными» или законным контрактом слоя^[6]. Именно поэтому исследования архитектурных запахов идут через метрики связности и зацепления, а не через поиск по тексту кода^[11]. Инструментальная поддержка здесь беднее, чем для запахов метода, и значительная часть архитектурных запахов до сих пор обнаруживается человеком на обзорах дизайна^[6].

Ручное обнаружение — вычитка кода человеком; таксономия Мянтюли выросла из наблюдений, как разработчики замечают запахи в чужом коде, и показала, что опытные инженеры опираются на характер будущих изменений, а не на отдельные строки^[6]. Формализованный путь — метрики: размер метода и класса в строках, цикломатическая сложность, предложенная Маккейбом как мера сложности модуля^[16], число параметров, связность класса^[6] и зацепление между модулями; пороги на метриках превращают «пахнет» в вычислимый сигнал^[7].

Автоматические детекторы строятся по трём схемам. Правила и пороги применяют статический анализ: инструменты со статическим анализом вроде SonarQube накапливают метрики и показывают «худшие» места проекта^[17]. Подходы на истории изменений ищут фрагменты, которые часто правятся вместе или часто ломаются, — Palomba и соавторы показали, что история фиксирует запахи точнее, чем пороги на метриках^[15]. Детекторы на машинном обучении учатся на размеченных примерах и находят запахи по комбинациям признаков, включая те, что не описываются одним правилом^[7].

Точность автоматических детекторов остаётся главной практической проблемой: разные инструменты дают расходящиеся списки, а часть срабатываний — ложные^[7][18].

Пороги приходится настраивать под язык и предметную область: значение, подозрительное для веб-приложения, может быть нормой для научных вычислений, и универсальных настроек не существует^[7].

Машинное обучение в детекции запахов решает ту же проблему настройки: модель, обученная на размеченных примерах одного проекта, улавливает местные представления о «нормальном» коде и переносит их на новые участки^[7]. Ограничение — качество разметки: обучать приходится на человеческих решениях, а они, как показывают опросы, расходятся между разработчиками^[14]. Поэтому конвейеры качества используют запахи как подсказку для ревью, а не как автоматический вердикт^[14].

Ещё один источник сигналов — разговор с автором кода. В обзорах разработчики объясняют «странные» места осознанными компромиссами, и часть помеченного детектором снимается после обсуждения с автором; поэтому детекторы полезнее там, где авторов спросить не у кого, — в унаследованном коде без документации^[14]. Для таких систем применяют приём Фезерса: перед изменением унаследованный участок окружается пробами — тестами, фиксирующими текущее поведение, и лишь затем код правится по запахам^[19].

Главная роль запахов — указать на подходящее рефакторинговое преобразование: каталог Фаулера построен как пары «запах — рефакторинги»^[1]. Дублирование ведёт к выделению метода или подъёму в общий предок, длинный метод — к разбиению и замене временных переменных вызовами, большой класс — к выделению класса и подкласса, переключатель — к замене условия полиморфизмом^[1]. Кериевский связал обе практики с шаблонами проектирования: рефакторинг к шаблонам выполняется постепенно, по мере появления запахов, а не заранее^[20].

Порядок работы задают тесты: перед преобразованием код накрывается юнит-тестами, и лишь затем выполняется серия мелких шагов, каждый из которых оставляет программу работающей^[1]. Запахи указывают и на приоритет: правят в первую очередь те места, которые часто меняются и одновременно пахнут, — так стоимость рефакторинга окупается ближайшими изменениями^[6]. Русскоязычные руководства описывают тот же цикл: распознать запах, выбрать рефакторинг, проверить тестами, зафиксировать результат в системе контроля версий^[5].

Рефакторинг по запахам часто откладывают в двух типовых ситуациях: перед близким выпуском, когда выгоднее не смешивать преобразование с исправлением ошибки, и в коде, который вскоре исчезнет вместе с устаревшей функциональностью^[1].

Обратная ситуация — унаследованный код без тестов — требует осторожности в обратную сторону: там, где поведение не зафиксировано, даже «очевидный» рефакторинг по запаху может незаметно изменить результат, и Фезерс прямо предупреждает, что правка без проб — лотерея^[19]. Поэтому зрелые команды сперва оборачивают сомнительные места тестами и лишь потом улучшают код^[1]. Мартин формулировал то же правило через экономику: чистота кода окупается только на участках, которые продолжают меняться, и вычищать всё подряд — расточительство^[4]. Автоматизация этой цепочки — от детекции до механического преобразования — стала отдельным направлением инженерии программирования^[11].

Инструментальная поддержка выросла из Smalltalk-браузера: сегодня операции рефакторинга встроены в среды разработки для распространённых языков, а отдельные анализаторы — PMD, Checkstyle, SonarQube — проверяют код в непрерывной сборке и помечают подозрительные места до ревью^[8]. Метрическая оценка качества кода применяется и в обучении: экспертные системы для начинающих разработчиков используют базы типовых шаблонов плохого кода и соответствующих рефакторингов^[21].

Первое ограничение — субъективность: что пахнет одному разработчику, другому кажется приемлемым, и списки запахов в книгах пересекаются, но не совпадают^[2]. Опросы показывают, что разработчики в целом доверяют идее запахов, но не соглашаются с конкретными детекторами: инструмент может помечать место, которое команда осознанно оставила как есть^[14].

Второе ограничение — связь с реальными затратами слабее, чем предполагала метафора. Йамашита и Мунен показали, что влияние запаха зависит от того, с какими другими запахами он встречается в коде: отдельные признаки почти не сказываются на сопровождаемости, а сочетания — заметно^[22]. В исследовании Шёберга и соавторов шесть разработчиков выполняли задачи сопровождения четырёх функционально эквивалентных Java-систем. После учёта размера файлов и числа изменений ни один из 12 исследованных запахов не был статистически значимо связан с увеличением трудозатрат; Refused Bequest был связан с их уменьшением. Этот результат ограничен условиями исследования.^[13]

Туфано и соавторы исследовали историю 200 открытых проектов из разных программных экосистем, обработав более полумиллиона коммитов. Их результаты поставили под сомнение представление, что запахи возникают преимущественно при последующей эволюции кода, и указали на необходимость учитывать историю появления запахов при планировании рефакторинга.^[12]

Исследования согласуются и в том, что не всякий запах должен устраняться. В редких случаях запах удерживается годами без видимого ущерба: команда знает о нём, участок не меняется, и вложения в рефакторинг не возвращаются^[22]. Такие наблюдения сместили практику от «исправить всё, что нашёл детектор» к приоритизации: запахи ранжируют по частоте будущих изменений участка и по стоимости правки^[6]. При этом ничто из сказанного не отменяет сам подход: запахи остаются эвристикой первого взгляда, и их сила — в скорости, а не в точности^[1].

Инструментальный ландшафт делится на три слоя. Статические анализаторы с правилами — PMD^[23], Checkstyle^[24] и встроенные проверки компиляторов — помечают нарушения стиля и простые структурные признаки в момент сборки. Метрические платформы — SonarQube и подобные — собирают метрики по проекту, показывают динамику и список самых «пахнущих» файлов^[17]. В исследовательских подходах используются как структурные признаки, так и история изменений. Например, HIST (Historical Information for Smell deTection) использует историю версий для обнаружения пяти видов запахов^[25].

Среды разработки автоматизируют переименование, выделение метода и другие преобразования. При этом возможны конфликты: например, IntelliJ IDEA показывает их перед выполнением рефакторинга и позволяет пользователю решить, продолжать ли операцию^[26]. Связка «детектор + автоматический рефакторинг» остаётся актуальной задачей: полного автоматизма нет, и окончательное решение о преобразовании принимает человек^[11].

Отдельный пласт инструментов — обучающие. Экспертные системы для начинающих связывают обнаруженный запах с объяснением и примером исправления, воспроизводя роль наставника, который в парной работе подсказал бы, что и почему здесь не так^[21]. Руководства по чистому коду опираются на тот же принцип: имя, которое объясняет намерение, и короткий метод делают запахи видимыми — в понятном коде чужой запах бросается в глаза сразу^[4].

Код с запашком близок к антипаттерну, но не совпадает с ним: антипаттерн — типовое ошибочное решение с описанной структурой и последствиями, а запах — поверхностный признак, который может указывать и на антипаттерн, и на осознанный компромисс^[10]. С техническим долгом запахи связаны как симптом с причиной: Каннингем ввёл метафору долга для объяснения цены поспешного кода, и запахи — то, по чему эта цена видна в коде^[3][27]. По отношению к качеству ПО запахи играют роль раннего сигнала: они не измеряют качество, как метрики, но указывают места, где качество может деградировать при следующем изменении^[22].

Код с запашком следует отличать от ошибки поведения программы: наличие запаха само по себе не устанавливает, работает ли программа правильно.^[2] Обратный пример полезен и для границ понятия: плотный, «умный» код без запахов по формальным признакам может быть менее сопровождаемым, чем развёрнутый, поэтому решения принимают по контексту, а не по списку признаков^[13].

Зато слабость формальных критериев компенсируется социальным механизмом: обсуждение запахов приучает команду к одинаковому пониманию чистого кода, и со временем совместные обзоры помогают инженерам вырабатывать общее понимание проблемных мест^[6]. В этом смысле каталог запахов работает как учебник зрения — он описывает не правила, а то, что должен увидеть опытный взгляд^[2].

Сама процедура группировки запахов субъективна: в исходном исследовании Мянтюля два инженера, сортировавшие одинаковые карточки с признаками, пришли к разным группировкам, и только итерации с обсуждением дали согласованную таксономию^[6]. Это стоит помнить при чтении любых списков запахов: границы категорий — договорённость, а не измерение^[6].

Отдельно запахи связаны с метриками качества кода: там, где метрика фиксирует состояние, запах объясняет его словами, понятными человеку, и именно поэтому отчёты инструментов качества дополняют числовые таблицы списками подозрительных мест с названиями запахов^[22]. Оба языка описания полезны вместе: число задаёт масштаб проблемы, название запаха подсказывает, что с ней делать^[7].