Диагностика БД без магических cleaners.
Рефакторинг нужен не ради красоты кода, а когда архитектура повышает стоимость изменений, вызывает регрессии, нагрузку или мешает бизнесу развивать продукт.
Сначала зафиксировать симптом
Один и тот же внешний симптом может появляться по разным причинам. Сначала стоит записать конкретный сценарий: URL, устройство, шаг, момент появления и последние изменения.
С чего я бы начал проверку
- Проверить запросы к postmeta и отсутствие N+1.
- Менять небольшими этапами с тестами.
- Разделить быстрые фиксы, рефакторинг и переписывание.
- Сначала определить, что не устраивает: UX, код, скорость, SEO или контент.
- Создать staging и проверить backup.
Где обычно находится причина
Рефакторинг я бы начинал с инвентаризации: что уже работает, откуда приходит трафик, какие интеграции завязаны на старый код и какие изменения стали дорогими.
Старый сайт не обязательно выбрасывать. Иногда выгоднее сохранить URL, данные и работающие интеграции, меняя проблемные слои постепенно. В других случаях чистая миграция дешевле спасения legacy.
Что легко сделать хуже
- переписывать без измеримой проблемы
- менять URL без SEO-карты
- лечить CSS сотнями !important
- проверять после релиза только главную
Самая дорогая ошибка — начать с полного переписывания, не сохранив URL, аналитику, формы, данные и рабочие сценарии.
Как понять, что проблема решена
- PHP/JS ошибки
- время типовой правки
- нагрузка
- частота регрессий
Хороший рефакторинг заметен не эффектом, а тем, что сайт перестаёт ломаться от каждой следующей задачи.
Если проблема уже проявляется на рабочем сайте
Можно начать с диагностики текущего состояния и отделить локальный дефект от архитектурной причины.