Рефакторинг JavaScript на сайте: дубли событий, утечки и бесконечные запросы

Обработчики событий, таймеры, сетевые запросы, состояние интерфейса и поиск утечек.

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

Не чинить то, что ещё не диагностировано

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

Первые проверки без переделки сайта

• Проверить повторную регистрацию listeners и таймеров.
• Снять карту темы, плагинов, БД, PHP, cron и интеграций.
• Менять небольшими этапами с тестами.
• Посмотреть Network на дубли запросов и незавершённые fetch/XHR.
• Создать staging и проверить backup.

Что чаще оказывается источником

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

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

Популярные ложные решения

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

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

Проверка после исправления

• время типовой правки
• PHP/JS ошибки
• нагрузка
• частота регрессий

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