Frontend Meetup от OneTwoTrip: рефакторинг — реставрация без сноса

20 марта 2025 года в Москве мы провели офлайн-митап для фронтендеров, на котором эксперты OneTwoTrip выступили с интересными докладами. В этой статье хотим подробнее рассмотреть презентацию Азата Шаймухаметова. Он подробно рассказал о рефакторинге и о том, как именно его проводят у нас, с примерами кода и ссылками на полезные инструменты. Получился краткий, но исчерпывающий ликбез.

Ссылка на выступление: https://vkvideo.ru/video-229335646_456239089

Азат Шаймухаметов — Team Lead в команде «Партнёры b2b», которая занимается тем, что делает White Label, то есть адаптирует тревел-продукты сервиса для сайтов партнёров. Среди них на сегодняшний момент Аэрофлот, Т-Банк, Альфа-Банк, Газпромбанк, X5 Клуб и многие другие компании.

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

Зачем же что-то менять, если всё и так работает? В первую очередь рефакторинг позволяет быстрее находить нужные части кода, определять баги и легко добавлять, менять или удалять код без ошибок. Также рефакторинг упрощает знакомство новых разработчиков с проектом.

Рефакторинг нужен, если код:

Чтобы провести идеальный рефакторинг, нужно для начала очертить границы и определить, какие есть сложности и какова цель (удобная схема на 6:25). Важно понять, стоит ли вообще перерабатывать весь код или проблема в одном небольшом модуле — и можно заняться только им. Далее определяем, каковы будут последствия, если не сделать рефакторинг, выясняем возможные подводные камни и оцениваем ресурсы команды.

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

Проще всего — с внедрения автоматических инструментов типа линтеров. Нам нужно актуализировать ESLint config и ужесточить правила. Список плагинов, которые вам могут помочь в этом деле, ищите на 8:42. А если вы уже перешли не последнюю версию ESLint, то можете попробовать новый инструмент config inspector — о нём с 9:10. Он помогает увидеть, какие правила уже исполь��уются, а какие из рекомендуемых можно добавить.

Также можно заняться анализом зависимостей (с 10:00), провести его поможет инструмент node modules inspector. Он показывает, что дублируется, что уже не поддерживается (а значит, стоит поискать альтернативу) и какие зависимости тяжёлые.

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

Обращайте внимание и на стоп-слова в именах функций — and, or, if, with и другие (их полный перечень на 12:12). Они могут сигнализировать о том, что функция выполняет слишком много действий.

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

Поговорим и про абстракции на примере кода OneTwoTrip (13:20). Абстракция в данном случае — это выделение главного и скрытие несущественного. Функции с большим количеством деталей выглядят «шумно», в таком коде сложно сфокусироваться на отдельных моментах.

Проверьте и сайд-эффекты — это, например, запросы к бэкенду, работа с выводом на экран и так далее. Их сложно тестировать, а ещё они непредсказуемы, так что мы, например, стараемся их абстрагировать и выделять куда-то в отдельное место.

Если у функции длинный список параметров, это может указывать на то, что она выполняет слишком много действий, а ещё в ней можно что-то перепутать местами. Эту проблему проще всего решить созданием параметрического объекта и разбиением функции на несколько более простых.

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

Часто встречается в проектах проблема чрезмерно сложных условий. Такие моменты можно упрощать, вывернув их наизнанку с помощью законов де Моргана — примеры на 16:40.

Ещё нужно поработать с todo-комментариями, которые периодически встречаются в проектах. Фактически это технический долг — некие обещания что-то сделать в будущем. В них самих ничего плохого нет, они показывают, что сейчас мы не можем решить какую-то проблему, но планируем вернуться к этому в будущем. Сложности возникают, когда таких комментариев становится всё больше, и со временем другие разработчики просто перестают обращать на них внимание. Для решения этих проблем мы стараемся документировать контекст и создавать задачи в таск-трекере, чтобы они не терялись. Мы разработали отдельный инструмент для анализа todo-комментариев, узнать о нём можно на 18:31.

И наконец, полезным будет инструмент для удаления мёртвого кода. С его помощью можно обнаружить неиспользуемые файлы, зависимости и экспорты. Он называется knip, qr-код для его скачивания ищите на 19:13.

Я считаю, что развивать культуру рефакторинга в команде очень важно. Создавайте безопасную среду, чтобы каждый участник команды мог спокойно высказаться и внести своё предложение. Например, мы еженедельно проводим небольшие встречи, на которых обсуждаем рабочие проблемы, которые у нас возникают, и обмениваемся знаниями.

Полезная практика — регулярный код-ревью, его мы тоже проводим. А ещё не забываем о документации. И тогда проводить глобальный рефакторинг может и не понадобиться.