Что такое рефакторинг кода и когда он нужен вашему сайту

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

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

Что такое рефакторинг простыми словами

Классическое определение дал Мартин Фаулер, автор книги «Рефакторинг. Улучшение проекта существующего кода» (первое издание — 1999 год, второе — 2018-й): рефакторинг — это изменение внутренней структуры программы, которое делает её проще для понимания и дешевле для модификации, не меняя её наблюдаемого поведения.

В этом определении три важные для заказчика части:

• Внутренняя структура. Меняется то, как код устроен: разбиение на модули, названия, связи между частями, дублирование. Дизайн, тексты и функции сайта остаются прежними.
• Наблюдаемое поведение не меняется. Пользователь после рефакторинга видит тот же сайт, та же корзина, те же цены. Если что-то изменилось для пользователя — это уже не рефакторинг, а доработка или исправление ошибки.
• Цель — удешевить изменения. Рефакторинг не делают ради «красивого кода». Его смысл экономический: чтобы следующие задачи делались быстрее и ломали меньше.

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

Рефакторинг кода, доработка и переписывание с нуля: в чём разница

Эти три вида работ часто путают, в том числе сами подрядчики. Для бюджета и рисков разница принципиальная.

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

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

Термин «технический долг» ввёл программист Уорд Каннингем в 1992 году. Каждый раз, когда команда делает задачу быстро, но «на костылях» — копирует код вместо общего решения, не пишет тесты, откладывает обновление библиотек, — она берёт кредит. Сэкономили время сейчас, но каждая следующая задача в этом месте обходится дороже: это проценты по долгу.

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

Признаки, что сайту пора на рефакторинг

Владельцу не нужно читать код, чтобы заметить проблему. Симптомы видны по работе с подрядчиком и по поведению сайта:

• Каждая правка ломает соседнее. Поменяли форму заявки — перестала работать выгрузка в CRM. Регрессии после релизов стали нормой.
• Мелочи делаются долго. Добавить поле в карточку товара — неделя. Разработчик не может дать оценку без «надо сначала разобраться».
• Устаревшая платформа. Сайт работает на версии PHP или фреймворка, которая больше не получает обновлений безопасности. Например, у PHP 8.2 поддержка безопасности заканчивается 31 декабря 2026 года, а ветки 7.x и 8.0–8.1 уже сняты с поддержки. Обновить версию часто мешает именно старый код.
• Нет автотестов. Проверка после релиза — это «менеджер прокликал главную». Любое изменение — лотерея.
• Знание в одной голове. Только один разработчик понимает, как всё устроено, новые специалисты отказываются брать проект или тратят недели на вход.
• Дублирование логики. Цена считается в трёх местах по-разному, и каждое изменение приходится вносить трижды.
• Производительность падает без роста нагрузки: страницы каталога грузятся всё дольше после каждого обновления.

Если совпадают три и больше пунктов, долг уже влияет на деньги. Особенно часто так выглядят проекты, доставшиеся от ушедшего фрилансера или студии: документации нет, а код писали разные люди в разные годы.

Когда рефакторинг не нужен

Бывают ситуации, когда вкладываться в улучшение кода нерационально:

• сайт почти не меняется — лендинг или визитка, которую правят раз в год;
• проект планируют закрыть или заменить в ближайшие месяцы;
• платформа устарела настолько, что дешевле сделать новую версию, — например, самописная система на PHP 5 без единого теста, где бизнес-логику проще описать заново;
• код и так в хорошем состоянии, а предложение «всё отрефакторить» идёт от вкуса нового разработчика, а не от измеримой проблемы.

Как рефакторить без остановки бизнеса

Правильный рефакторинг незаметен для клиентов сайта. Для этого используют несколько приёмов.

Сначала тесты, потом изменения

Прежде чем трогать модуль, на него пишут автотесты, которые фиксируют текущее поведение: заказ оформляется, скидка считается, письмо уходит. После каждого шага тесты прогоняются. Без этого рефакторинг превращается в угадывание — упомянутое определение Фаулера про «неизменное поведение» можно гарантировать только проверками.

Маленькие шаги и частые релизы

Изменения выкатываются небольшими порциями, каждая из которых сразу попадает в рабочую версию. Если что-то пошло не так, откатывают одну небольшую правку, а не месяц работы. Хорошо, когда у проекта настроена автоматическая сборка и выкладка — CI/CD делает частые безопасные релизы дешёвыми.

Фича-флаги

Новая версия модуля выкладывается на сайт, но включается переключателем: сначала для сотрудников, затем для 5–10% посетителей, потом для всех. Если метрики просели — флаг выключают за минуту, без срочного отката кода.

Подход «фикус-душитель» (strangler fig)

Метафора того же Фаулера: тропический фикус прорастает вокруг дерева-хозяина и постепенно его заменяет. Для сайта это значит: новые части строятся рядом со старой системой, и трафик на них переводится по одному разделу — сначала каталог, потом корзина, потом личный кабинет. Старый код отмирает постепенно, а в каждый момент времени сайт работает целиком.

Как контролировать подрядчика: метрики рефакторинга

Главный вопрос заказчика — как понять, что деньги потрачены не зря, если снаружи ничего не изменилось. Ответ — договориться о метриках до начала работ и снять их «до» и «после».

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

Сколько стоит рефакторинг и как обосновать бюджет

Фиксированной цены у рефакторинга нет: стоимость зависит от объёма кода, стека, наличия тестов и документации, глубины проблем. Ориентиры по рынку:

• Полноценный аудит кода с письменным отчётом о техдолге и планом работ — от 30–50 тыс. ₽ для небольшого сайта, дороже для крупных проектов с интеграциями. Это не то же самое, что короткая оценка задачи перед сметой.
• Рефакторинг отдельного модуля (корзина, импорт из 1С, личный кабинет) — обычно от 40 до 200 часов работы в зависимости от запущенности.
• Постоянный режим — доля в ежемесячных часах поддержки. Распространённая практика — закладывать на погашение техдолга постоянную долю времени команды; конкретный процент зависит от состояния проекта.

Все цифры ориентировочные и зависят от ставки подрядчика и состояния проекта — точную оценку даёт только аудит.

Обосновать бюджет проще всего через экономику изменений. Пример расчёта: если типовая задача сейчас занимает 20 часов, а после рефакторинга модуля — 8, при 10 задачах в месяц экономия составит 120 часов. Рефакторинг на 160 часов окупится меньше чем за два месяца. Добавьте к этому стоимость аварий: сколько заказов теряется за час, когда после релиза не работает корзина.

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

Когда рефакторинг — развод подрядчика: признаки

Рефакторинг действительно бывает способом продать часы. Насторожиться стоит, если:

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

Честный подрядчик показывает, где именно долг, сколько он стоит сейчас и в какие сроки окупится его погашение. Если есть сомнения, закажите независимый аудит кода у другой команды — это дешевле, чем полгода сомнительных работ.

Типичные ошибки при рефакторинге

1. Рефакторинг без тестов. Изменения проверяются вручную, регрессии всплывают у клиентов.
2. Всё и сразу. Масштабная переработка в отдельной ветке, которая через три месяца уже не сливается с рабочей версией.
3. Смешивание с новыми функциями. Невозможно понять, что сломало сайт.
4. Рефакторинг «по вкусу». Код меняют под привычки нового разработчика, а не ради конкретной проблемы.
5. Разовая акция вместо процесса. Провели большой рефакторинг, затем снова два года копили долг без выделенного времени.
6. Забыли про SEO. При переработке шаблонов поменялись адреса страниц, мета-теги или микроразметка — и сайт просел в поиске. Адреса и SEO-элементы должны входить в проверки.

Если проект достался от другого подрядчика

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

Чек-лист владельца перед рефакторингом

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

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