Аудит перед рефакторингом: что проверить до первой строки нового кода

Код, БД, логи, SEO, аналитика, интеграции.

Запрос «переделать сайт» почти никогда не является техническим заданием. За ним могут скрываться устаревший дизайн, плохая конверсия, медленная работа, неудобная админка, SEO-проблемы или код, который страшно менять.

Смысл в одной идее

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

Как это работает на практике

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

• Менять небольшими этапами с тестами.
• Снять карту темы, плагинов, БД, PHP, cron и интеграций.
• Сохранить SEO URL, аналитику и критические сценарии.
• Зафиксировать симптомы человеческим языком.

Где появляется влияние на бизнес

Хороший рефакторинг заметен не эффектом, а тем, что сайт перестаёт ломаться от каждой следующей задачи.

Когда тема становится отдельной задачей

• лечить CSS сотнями !important
• менять URL без SEO-карты
• править production без staging

Самая дорогая ошибка — начать с полного переписывания, не сохранив URL, аналитику, формы, данные и рабочие сценарии.

Что делать с этим знанием

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

• частота регрессий
• время типовой правки
• нагрузка