Рефакторинг или полная переработка: как выбрать стратегию

Ключевые выводы

• Рефакторинг улучшает внутреннюю структуру кода, не меняя внешнего поведения; полная переработка создаёт новую систему с нуля и меняет архитектуру.
• Граница между ними проходит не по объёму работ, а по одному вопросу: меняется ли внешнее поведение системы.
• Критерии выбора: состояние кода, актуальность стека, тестовое покрытие, бизнес-требования, бюджет и экспертиза команды.
• Выбор не всегда бинарен и не всегда нужен: работающую систему иногда выгоднее не трогать, а когда изменения оправданы, паттерн Strangler Fig позволяет мигрировать по частям без остановки бизнеса.
• Три главные ошибки: называть переработку рефакторингом, рефакторить без тестов и решать без диагностики.

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

Рефакторинг кода:
суть и границы применения

Мартин Фаулер (автор книги «Рефакторинг») определил рефакторинг как изменение внутренней структуры кода без изменения внешнего поведения. Цель рефакторинга — читаемость и поддерживаемость (атрибуты качества кода). Измеримый результат: код, который легче понять и дешевле менять. Типичные техники: Extract Method (выделение метода), Rename (переименование) и Replace Conditional with Polymorphism (замена условий полиморфизмом). Рефакторинг не добавляет функции и не перестраивает архитектуру.

Обязательное предусловие: тестирование ПО, без тестов любое изменение превращается в риск

Не рефакторинг

• добавление новой функциональности
• исправление багов (это меняет поведение)
• переход на другую архитектуру или язык
• оптимизация, меняющая результат

Полная переработка системы: когда это не рефакторинг

Полная переработка (rewrite) — создание новой кодовой базы с кардинально иной архитектурой. Ключевые атрибуты подхода: высокие риски и длительные сроки. Стейкхолдеры чаще всего ошибаются, называя переработкой то, что задумано как рефакторинг: отсюда нереалистичные сроки. Типичным триггером становится масштабируемость: когда система упирается в потолок нагрузки, а старая архитектура не даёт расти, переработка превращается в вынужденную, а не желаемую.

Любое решение о стратегии без диагностики — это угадывание. Технический долг и качество кода нужно измерить объективными метриками: цикломатической сложностью, покрытием тестами, частотой инцидентов. ИИ-агенты ускоряют этап: анализируют кодовую базу целиком и подсвечивают проблемные зоны и масштаб долга. Иногда диагностика показывает, что система в приемлемом состоянии и вмешательство пока не окупается, и это тоже валидный результат. Диагностика остаётся нулевым этапом, а не опцией.

Сигналы, указывающие на необходимость изменений

Деградацию системы видно на трёх уровнях. Абстракции вроде «код стал сложным» бесполезны; важны конкретные проявления: например, добавление одной функции требует правок в 7 и более файлах.

Технические сигналы

• высокая цикломатическая сложность модулей
• отсутствие тестового покрытия
• дублирование кода свыше 30%

Командные сигналы

• разработчики боятся трогать определённые модули
• онбординг нового инженера занимает месяцы

Бизнесовые сигналы

• time-to-market растёт квартал за кварталом
• частые инциденты (программные ошибки) в продакшене

Оценка технического долга как бизнес-риска

Технический долг перестаёт быть абстракцией, когда его переводят в деньги. Три метрики делают это наглядным для стейкхолдеров: доля времени на «борьбу с системой»; стоимость инцидентов за 6 месяцев; влияние простоев (uptime) на выручку.

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

Кейс Аксмор:
фоновый рефакторинг платформы авиакомпании

Матрица работает не только на бумаге: в одном из проектов Аксмор она отвела заказчика от полного переписывания. Авиакомпания (детали изменены по условиям NDA) пришла с API на Java 1.8 и устаревшем Spring, а мобильные приложения несли легаси: iOS на Objective-C, Android на классических View.

Диагностика Аксмор шла по четырём направлениям. Статический анализ в SonarQube измерил цикломатическую сложность, дублирование и связанность модулей, а анализ истории изменений в Git наложил на эти данные частоту правок и выделил «горячие зоны» кода. Аудит архитектурных границ вскрыл реальные зависимости между слоями и доменами, разбор инцидентов за год связал сбои с конкретными модулями. Отдельно инженеры Аксмор проверили пути миграции для каждой устаревшей технологии: с Java 1.8 на Java 21, с Objective-C на Swift и с классических View на Jetpack Compose.

Результаты сложились в пользу рефакторинга: система оказалась «больна, но не мертва». Проблемы концентрированы: около 70% замечаний статического анализа и большинство инцидентов за год пришлись на одни и те же 20% модулей при покрытии тестами около 5%, а остальной код стабилен и менялся редко. Границы слоёв и доменов размыты, но сами домены прослеживались, а команда понимала систему, то есть «чёрного ящика» не было. Решающим стал технический факт: Swift сосуществует с Objective-C в одном проекте, Compose встраивается в экраны на View, а путь обновления Java с 1.8 до 21 отработан индустрией, поэтому каждую технологию можно менять поэтапно, не останавливая продукт. Переписывание означало бы полтора года без новых фич и риск потерять недокументированное поведение. Команда Аксмор выбрала плановый фоновый рефакторинг: распутывать зависимости и переписывать проблемные участки, не меняя поведения системы для бизнеса.

Фоновая работа заняла 10 месяцев: модернизация шла параллельно с разработкой фичей, без остановки релизов для бизнеса. API переведён с Java 1.8 на Java 21 с обновлением Spring и ключевых библиотек, iOS-приложение мигрировало с Objective-C на Swift, а Android поэтапно переходит на Jetpack Compose. Качество закрепили линтеры, quality gate SonarQube в CI/CD и Renovate для автообновления зависимостей.

Страховочной сетью рефакторинга стали тесты: нагрузочные, API-тесты и e2e-тесты для Android, а мониторинг ключевых сценариев ловил регрессии до пользователей.

Итог: релизы фич не прерывались ни на спринт, покрытие тестами выросло с 5% до 40%, а регрессионных багов при разработке стало примерно на треть меньше. Сами 40% — осознанный порог, а не компромисс: тесты закрыли весь критичный и жизненно важный для бизнеса функционал, прежде всего «горячие зоны» из диагностики, а оставшийся код стабилен и меняется редко, поэтому гнаться за формальным процентом смысла не было. Прозрачность кода выросла: число замечаний статического анализа сократилось вдвое.

Когда выбирать рефакторинг legacy приложения

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

5 условий, при которых рефакторинг — правильный выбор:

• в коде прослеживается понятная архитектурная логика
• есть базовое тестовое покрытие или его реально добавить
• технологический стек всё ещё поддерживается
• бизнес-процессы работают и меняются эволюционно
• технический долг управляем и не превышает стоимость переписывания

Когда необходима
полная переработка системы

Полная переработка оправдана только при «красных флагах», перечисленных ниже. Но помните про «иллюзию переработки»: новая система не станет лучше автоматически. Так провалился Netscape Navigator (браузер): команда переписала продукт с нуля и потеряла рынок. Решение о переработке нельзя принимать на эмоциях.

Красные флаги, требующие полной переработки системы:

• технический долг превышает стоимость новой разработки
• архитектура фундаментально не соответствует требованиям (например, монолит не масштабируется)
• технологический стек снят с поддержки, специалистов не найти
• система стала «чёрным ящиком»: никто не понимает, как она работает
• целевая архитектура принципиально иная (например, переход на микросервисную архитектуру)

Гибридный подход:
когда нужно и то, и другое

Выбор «рефакторинг ИЛИ переработка» чаще всего ложный. Паттерн Strangler Fig позволяет обойтись без резких движений: новые запросы направляются в новый сервис, старые продолжает обрабатывать легаси, а трафик переключается постепенно. На практике есть три пути: инкрементная реструктуризация, паттерн Strangler и доменно-ориентированный редизайн. Обратная совместимость (сохранение старого поведения для существующих клиентов) — обязательное условие плавного перехода.

Человеческий и организационный аспект выбора стратегии

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

3 организационных вопроса до принятия решения о стратегии:

• кто владеет решением и несёт ответственность за результат?
• как синхронизированы бизнес, продукт и разработка в оценке проблемы?
• не является ли желание «всё переписать» следствием выгорания, а не анализа?

Лучший рефакторинг — тот, который бизнес не заметил. Он не требует отдельного «проекта на полгода»: по «правилу бойскаута» команда оставляет код чуть чище, чем нашла, при каждой правке. Так улучшение структуры становится частью каждого спринта, а не разовым авралом.

Инкрементный рефакторинг: шаг за шагом

Обратимость каждого шага делает инкрементный рефакторинг безопасным. Современные ИИ-агенты (AI-инструменты для разработки программного обеспечения) ускоряют этот цикл: предлагают безопасные преобразования, генерируют недостающие тесты и берут на себя рутинные правки, а SonarQube (анализ качества кода) контролирует результат.

5 шагов безопасного инкрементного рефакторинга

1. 1.
   Напишите тесты, фиксирующие текущее поведение
2. 2.
   Сделайте одно минимальное изменение
3. 3.
   Убедитесь, что все тесты проходят
4. 4.
   Зафиксируйте изменение (commit)
5. 5.
   Переходите к следующему шагу

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

Техники — операциональное воплощение рефакторинга; каждая применяется к исходному коду точечно. Главный антипаттерн: «универсальный мегаметод», в который стягивают всю логику. Важное отличие от оптимизации (в информатике): она может менять внешнее поведение ради скорости, а рефакторинг не меняет его никогда.

Техники рефакторинга:
когда применять и чего избегать

Как перевести систему на новый стек без остановки бизнеса

Миграцию на новый стек выполняют по одному из трёх паттернов; feature flags (переключатели функций) позволяют включать новое поведение постепенно и мгновенно откатывать при проблеме. ИИ-агенты ускоряют и саму миграцию: помогают переносить логику на новый стек и восстанавливать понимание недокументированного легаси.

• Strangler Fig: новые запросы идут в новый сервис, трафик переключается частями
• Branch by Abstraction: над старым кодом строится абстракция, за ней появляется новая реализация, старая удаляется
• Parallel Run: обе системы получают одинаковые данные, результаты сравниваются (сравнительное тестирование)

Микросервисная архитектура — типичный результат такого перехода; обратная совместимость остаётся его обязательным условием.

Наблюдаемость системы при трансформации

Наблюдаемость системы — обязательное условие безопасной трансформации. Четыре инструмента дают эту видимость: распределённая трассировка (путь запроса через сервисы), структурированное логирование с correlation ID, circuit breakers (предохранители от каскадных сбоев) и SLO как якорь оценки успеха. Без наблюдаемости поиск бага растягивается на дни вместо минут.

Большинство переработок проваливаются не из-за технологий, а из-за организации. Технически грамотная, но плохо спланированная переработка тонет в размытом объёме работ, отсутствии feature parity (новая система умеет всё то же, что и старая) и войне приоритетов между «старой» и «новой» командами.

Планирование и управление рисками при полной переработке

Переработка — полноценный проект с длительным сроком, а не «перепишем за квартал». До старта нужно зафиксировать: что считается «готово» (Definition of Done), как обеспечивается feature parity со старой системой, кто «владеет» легаси во время разработки новой версии и как пройдёт миграция данных. Резервное копирование перед любыми необратимыми шагами остаётся базовым требованием безопасности.

Управление данными: разделение схем и стратегия миграции

Данные — самый консервативный элемент переработки: код можно переписать, данные потерять нельзя. Три стратегии миграции: Big Bang (одномоментный перенос, максимальный риск), постепенная с двойной записью (данные пишутся в обе системы; здесь критична обратная совместимость) и Event Sourcing (перестройка состояния из истории событий). В микросервисной архитектуре действует принцип ownership: каждый сервис владеет своими данными. Резервная копия перед миграцией обязательна.

Обратная совместимость и миграция при переработке

Обратную совместимость при переработке обеспечивают конкретные паттерны: версионирование API (новая версия публикуется, старая какое-то время живёт рядом), адаптеры и фасады как временный слой совместимости и принцип наименьшего удивления при изменении поведения. Канареечные развёртывания (выкатка на малую долю пользователей) позволяют безопасно переключать трафик и проводить приёмочное тестирование прямо в продакшене.

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

Пирамида тестирования при трансформации

Правило простое: сначала тесты, потом рефакторинг.

4 уровня тестовой защиты при трансформации системы

1. 1.
   Модульные тесты — основание пирамиды, проверяют отдельные функции
2. 2.
   Интеграционные тесты — проверяют взаимодействие компонентов
3. 3.
   Контрактные тесты — фиксируют договорённости между сервисами
4. 4.
   E2E-тесты — вершина, проверяют сценарий целиком (их меньше всего)

Канареечные деплойменты и хаотическое тестирование

Два продвинутых метода проверяют надёжность до того, как проблему увидят все пользователи. Канареечный деплой: новая версия выкатывается на 5% пользователей, метрики под наблюдением, охват растёт постепенно, а старые клиенты изменений не видят благодаря обратной совместимости. Хаотическое тестирование: компоненты намеренно «ломают», чтобы убедиться в graceful degradation (плавной деградации вместо полного отказа). Оба метода требуют зрелого мониторинга.

Перечисленные ниже 8 ошибок команда Аксмор наблюдала в реальных проектах не по одному разу. Список даёт быструю навигацию, таблица ниже разбирает каждую с профилактикой.

8 типичных ошибок

1. 1.
   Называть переработку рефакторингом
2. 2.
   Начинать рефакторинг без тестового покрытия
3. 3.
   Рефакторить всё сразу вместо инкрементов
4. 4.
   Игнорировать бизнес-логику
5. 5.
   Рефакторить перед релизом
6. 6.
   Принимать решение о переработке без диагностики
7. 7.
   Работать без единых стандартов кода
8. 8.
   Рефакторить ради рефакторинга

Ошибки и их последствия: как распознать и предотвратить

Ловушка перфекционизма: рефакторинг ради рефакторинга

«Красивый» код без бизнес-ценности — не цель рефакторинга. Преждевременная оптимизация без данных об узком месте относится к тому же перфекционизму. Прежде чем начинать, прогоните рефакторинг через три вопроса:

• Решает ли это реальную проблему пользователей или бизнеса?
• Есть ли данные, что именно здесь узкое место?
• Стоит ли выигрыш затраченного времени?

Показательный случай из практики Аксмор: команда месяц вылизывала модуль, который затем удалили из-за смены бизнес-требований.

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

Непрерывный мониторинг и адаптация архитектуры

Качество нужно измерять постоянно. Базовый набор — DORA-метрики: частота развёртываний (deployment frequency), время от коммита до релиза (lead time), время восстановления (MTTR) и доля неудачных изменений (change failure rate). Архитектурные ворота в CI/CD (например, gate в SonarQube и порог покрытия тестами) не пропускают деградацию в продакшен, а регулярные «архитектурные спринты» держат систему в фокусе.

Чек-лист действий после завершения рефакторинга

Результат рефакторинга нужно закрепить. Чаще всего команды пропускают ретроспективу и обновление ADR, хотя именно эти пункты дают долгосрочный эффект.

7-шаговый чек-лист после завершения рефакторинга

1. 1.
   Прогнать все тесты
2. 2.
   Провести код-ревью
3. 3.
   Задеплоить в staging
4. 4.
   Задокументировать изменения (ADR, Architecture Decision Record)
5. 5.
   Обновить технический README
6. 6.
   Провести ретроспективу
7. 7.
   Обновить архитектурную дорожную карту

Архитектурные ретроспективы и институциональная память

Ретроспектива (практика из Agile) превращает разовый опыт в знание команды. Формат — три вопроса: что прошло хорошо, что стало неожиданностью, что сделали бы иначе. Участвуют разработчики, архитектор и продукт; на выходе ADR-документы и обновлённая схема архитектуры. Успешный рефакторинг системы часто запускает «рефакторинг компании».

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

Начинать стоит не со спора, а с диагностики: объективная картина технического долга и качества кода обычно снимает эмоции и подсказывает решение сама. Самые дорогие ошибки в практике Аксмор рождались не из выбора между рефакторингом и переработкой, а из отказа честно поставить диагноз до принятия решения.