Представьте: ваш продукт работает. Заказы идут, клиенты платят. Но каждая новая фича превращается в трёхнедельный квест. Один разработчик уходит — и уносит в голове четверть бизнес-логики. Баги в production фиксируются заплатками поверх заплаток. Вы понимаете, что система гниёт изнутри — но останавливать её страшно.
Это не паранойя. Это классическая стадия, когда технический долг из абстрактной метрики превращается в реальные деньги. В Fortech мы проходили через это с командами из финтеха, логистики и корпоративного сектора. И знаем: рефакторинг — это не «блажь разработчиков». Это инвестиция в выживание продукта. Статья основана на реальном опыте наших команд в проектах по мониторингу автопарка, финансовым платформам и корпоративным системам.
Legacy — это не обязательно код, написанный десять лет назад. Legacy — это любая система, которую страшно трогать.
Технически это выглядит так: отсутствие документации, спагетти-код с запутанными зависимостями, устаревшие версии фреймворков, которые давно не получают обновлений безопасности. Монолит, где правка в одном месте ломает три других.
С точки зрения бизнеса это ощущается иначе: новая фича занимает месяц вместо недели. Time-to-Market растёт, конкуренты вас обгоняют. Ключевой разработчик увольняется — и вдруг выясняется, что никто больше не понимает, как работает модуль расчёта тарифов.
Как понять, что пора? Есть несколько сигналов:
Один из наших клиентов — платформа управления автопарком — столкнулся именно с этим: устаревший код, неоднородная структура, и задача масштабироваться под растущий объём данных о геолокации, страховках и поведении водителей. Прежде чем внедрять новый функционал, нужно было сначала стабилизировать то, что есть.
Самая опасная идея в рефакторинге — «снести всё и написать заново». Это заманчиво. Это кажется чистым решением. Но на практике это почти всегда катастрофа.
Почему нельзя просто переписать:
Рабочий подход — поэтапная замена. В разработке это называется Strangler Fig Pattern (метод «Душителя»): по аналогии с тропическим растением, которое постепенно обвивает дерево-хозяина и в итоге заменяет его, не давая ему упасть.
Суть: вы не убиваете старую систему сразу. Вы создаёте новые модули рядом, постепенно перенаправляете на них трафик и логику, а старые части отмирают сами — когда уже не нужны.
Anti-Corruption Layer — второй ключевой инструмент. Это прослойка между старым и новым кодом, которая не даёт «заразе» распространяться. Новые модули взаимодействуют со старыми через чётко определённый интерфейс — и не знают о внутреннем хаосе за ним.
Анализ рисков перед стартом — обязательный этап. Нужно понять: какие части системы «горячие» (изменения в них ломают всё), какие можно безопасно изолировать, где есть тесты, а где их нет совсем. Без этой карты рефакторинг превращается в блуждание в тёмной комнате.
Это не гипотетический пример. Именно с таким проектом работала наша аутстафф-команда.
Входные данные: многофункциональная веб-платформа, объединяющая сервисы продажи, каршеринга и администрирования транспорта. Тысячи объектов в реальном времени: геолокация, состояние узлов автомобиля, поведение водителей. Фронтенд — нестабильный, с устаревшим кодом и неоднородной структурой. Бизнес хотел масштабироваться, но архитектура не позволяла.
Проблема: провести глубокий рефакторинг так, чтобы операторы продолжали работать с системой в штатном режиме, а новый функционал появлялся параллельно с починкой старого.
Этап 1: Аудит и «заморозка» критических участков
Первое, что сделала команда — провела полный аудит кодовой базы. Не для того, чтобы переписать всё сразу, а чтобы составить карту: что трогать нельзя (высокий риск поломки), что можно изолировать, а что уже сейчас критически нестабильно. Параллельно зафиксировали «красные зоны» — участки, которые в процессе рефакторинга не должны изменяться до тех пор, пока новая версия не готова принять нагрузку.
Этап 2: Внедрение стейт-менеджмента
Ключевое решение — переход на централизованное управление состоянием через NgRx/NGXS. Это не просто технический выбор, это архитектурный фундамент. Без предсказуемого потока данных система с тысячами объектов ведет себя непредсказуемо. Стейт-менеджмент убирает этот класс проблем.
Этап 3: Поэтапный перенос бизнес-логики
Модуль за модулем. Сначала — таблицы с кастомными фильтрами и динамическими колонками, затем — геомониторинг и визуализация маршрутов. Потом — панель оператора с real-time статусами. На каждом этапе: старый код работает, новый разрабатывается рядом, переключение происходит тихо.
Результаты:
После завершения рефакторинга платформа получила гибкую фронтенд-архитектуру. Интерфейс стал интуитивно понятным — время обучения персонала сократилось. Операторы начали быстрее обрабатывать инциденты. Критические ошибки в маршрутизации устранены, отклик системы ускорился. Это измеримый результат: меньше инцидентов, быстрее обработка, проще масштабирование.
Другой показательный пример — приложение для финансового агрегатора.
Задача: за 90 дней создать платформу, которая объединит 500+ верифицированных обменных пунктов.
Команда получила legacy-кодовую базу с 14 800 строками дублирующейся логики. Первое решение — сначала убрать лишнее.
Что было сделано: Полный рефакторинг: удалены тысячи строк дублей, внедрена строгая типизация и компонентная архитектура. Параллельно — разработка модульной UI-библиотеки из 42 компонентов на React/TypeScript.
Результаты:
Почему внутренняя команда часто не может провести рефакторинг самостоятельно?
Что даёт аутстафф:
Экономика вопроса: Аренда Senior-разработчика кажется дорогой, пока вы не считаете цену каждого бага в production и задержки фич. По данным SkillStaff, рынок аутстаффинга в РФ вырос до 265 млрд руб. в 2024 году. Это быстро и предсказуемо: Senior через аутстафф — 2–3 недели, через найм — 3–4 месяца.
Главный страх — «начнём трогать — всё сломается». Но рефакторинг с опытной командой — это хирургия по чёткому плану: аудит, карта рисков, поэтапные изменения.
В обоих кейсах — бизнес не останавливался ни на день. Операторы работали, транзакции шли, а система под капотом становилась другой. Если архитектура тормозит рост — это сигнал к аудиту. Понять масштаб проблемы — первый шаг.
Сколько времени занимает рефакторинг?
От 2–4 недель за модуль до 3–9 месяцев за крупную платформу. Это постоянный процесс поддержания гигиены кода.
Можно ли делать рефакторинг частями, не останавливая выпуск фич?
Да — через Strangler Fig Pattern. Вы добавляете новые модули рядом со старыми, постепенно перенаправляя нагрузку.
Как убедить бизнес выделить бюджет?
Переведите техдолг в деньги: стоимость регрессионных багов, цена задержки фич и стоимость увольнения сотрудников из-за работы с плохим кодом. В кейсе Exsun рефакторинг ускорил выпуск фич на 73%.
Нужно ли останавливать выпуск новых фич на время рефакторинга?
Идеально — частично. Критические фичи продолжаются, остальное замораживается до стабилизации ядра.
В чём отличие вашего подхода от полной переработки системы?
Полная переработка — это риск «все или ничего» через год. Наш подход дает измеримые улучшения на каждом этапе, сохраняя непрерывность сервиса.
