Рефакторинг: экономим бюджет на поддержку IT-продукта

В основу статьи легло выступление на конференции Tagline в декабре 2024 года, где мы — Алина Ваниева и Максим Мишанин — рассказали о рефакторинге на доступном бизнесу языке.

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

IT-компания Red Collar. Разрабатывает цифровые решения для бизнеса в разных отраслях (логистика, туризм, энергетика, телеком, финтех и других) и на разных технологических стеках (Java, Python, PHP, Bitrix; React, Next.js) с 2011 года. В портфолио компании кейсы разной продолжительности — и крупные многолетние проекты, и запуски стартапов.

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

Зачем еще нужен рефакторинг:

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

Переезд затрагивает глобальные аспекты системы вроде фреймворков, языков программирования или баз данных. Сюда мы включаем всё, что можно назвать переездом: с одной базы данных на другую, с React на Angular и т.д. И, конечно, переезд в облако или, наоборот, из облака во внутреннюю инфраструктуру.

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

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

Это, как правило, самые масштабные изменения системы, а потому — самые дорогостоящие. Особенно потому что они всегда выполняются только вручную.

На что тратится бюджет разработки:

Кейс 1.1. «Переезд» блокирует создание новой функциональности. Переезд нельзя параллелить с разработкой новых фичей. Если решили переезжать на новый фреймворк, на новый сервис или менять архитектурный паттерн поведения системы, нужно отложить разработку и внедрение новых функциональностей до конца переезда. Это постулат.

Агентский опыт Red Collar: «Приходил заказчик с готовой системой и желанием ее улучшить и развивать. Получилось два флоу:

Что сделали: оценили сложность и возможность реализации каждой из фичей на старой архитектуре. Соотнесли с приоритезацией заказчика. Оценили «переезд». Исходя из оценок и приоритетов, построили план на год для всех активностей. Это был самый оптимальный и правильный подход».

Продуктовый опыт Авто.ру: «Похожие кейсы у нас случаются, когда нужно поменять инструмент, который больше не поддерживается. Что делаем:

Когда проект развивается годами, такие переезды неизбежны. И решение тут принимается в срезе “в каком квартале будем переезжать”, а не “переезжать ли”».

Кейс 1.2. Без «переезда» поддержка работоспособности становится дорогой. Система кажется стабильной, вы не вносите в нее никакие изменения? Не факт, что вы при этом экономите.

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

Агентский опыт Red Collar: «Это частый кейс в агентском опыте. Некоторые проекты переходят к нам с легаси, собранные на разных языках и разных фреймворках, в том числе устаревших.

Был заказчик с системой на Java, где один из сервисов был написан на С++. Поддерживать его инхаус было невозможно — поэтому обратились к нам. Мы предложили нанять специалиста на С++, который временно поддержит текущее решение, а мы параллельно перевезем этот сервис на Java и будем поддерживать его после переезда.

Переписали сервис на новом языке, появилась возможность поддерживать его командой и консистентно, а не урывками и разными специалистами».

Продуктовый опыт Авто.ру: «Авто.ру — давно не MVP. Мы можем подсчитать количество багов и инцидентов, которые связаны, и прикинуть, сколько будем экономить, если сменим часть системы на новую, более устойчивую».

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

Продуктовый опыт Авто.ру: «Когда Авто.ру поселился в Яндексе, сервис переписали на фреймворке, разработанном в Яндексе. За пределами компании этот фреймворк использовался не так активно, как популярный React. Поэтому через время нам стало сложно развиваться теми же темпами.

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

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

Кейс 2.1. Без оптимизации много платим за трафик и/или удержание пользователей. Агентский опыт Red Collar: «Агентства сталкиваются с оптимизацией в каждом проекте, где есть разработка. В ТЗ часто встречаются требования вроде “страница должна загружаться не более ХХ миллисекунд”.

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

Продуктовый опыт Авто.ру: «В большой и долгой продуктовой разработке среди требований есть не только “должно загружаться быстрее ХХ миллисекунд”. Сервис в целом должен быть быстрее конкурентов, особенно, если игроков на рынке несколько, и кто-то — лидер по скорости.

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

Кейс 2.2. Без оптимизации дорого платим за обнаруженные уязвимости. Агентский опыт Red Collar: «Мы разрабатываем не только промо- и корпсайты, но и сложные системы — в том числе на широкую публику, для банков и других масштабных вендоров услуг на рынке. Большая часть из них работает с персональными данными. Каждая такая система должна, как минимум, соответствовать 152-ФЗ.

Если мы допустим ошибку, и через нашу систему случится слив данных, репутационные риски будут и у нас, и у клиента. Поэтому перед тем, как отдавать проект заказчику на какой-то стадии продакшена, мы проводим все возможные проверки на уязвимость, AST (Application Security Testing).

Кейсом, когда нашли уязвимость и потеряли персональные данные, поделиться не смогу — такого не было :)»

Продуктовый опыт Авто.ру: «В продуктовой разработке, тем более в контуре Яндекса, мы можем опереться на службу безопасности — именно они у нас занимаются поиском уязвимостей.

У нас есть практика Bug Bounty: если пользователь нашел уязвимость в нашем сервисе, и рассказал об этом нам, он получит вознаграждение. Этот подход используется во многих крупных компаниях. Суммы могут быть совершенно разные, в зависимости от типа найденной уязвимости, — до миллионов рублей».

Кейс 2.3. Без оптимизации мы переплачиваем за «железо». Контекст тут одинаков и для продуктов, и для агентств — серверами пользуются все, а стоят они дорого.

В проекты недостаточно только заносить новые фичи — иногда нужно удалять старые. Для продуктов вроде Авто.ру, существующих десятилетиями, клининг — очень актуальная задача. При таком рефакторинге 90% времени уходит на удаление ресурсов. И исследования, и сам рефакторинг часто производятся автоматически.

Кейс 3.1. Клининг легаси, то есть старого кода. Продуктовый опыт Авто.ру: «Для нас это очень актуально: последние пару лет мы активно вычищаем тот самый легаси, который, кажется, лежит и никого не трогает, а по факту влияет на многое.

Мы запускали эксперимент, проводили его 2 недели. Решили, что перезапустим еще спустя полгода, когда доберемся. В итоге перезапуска не произошло, ресурсов на снос этого кода не выделили, — и все думают, что код просто лежит, как в файлике, и ничего с ним не происходит. Но это не так.

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

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

Агентский опыт Red Collar: «В агентстве неработающий код — не настолько частый кейс, потому что проекты не такие долгосрочные.

Я бы в таком случае считал количество манипуляций с неиспользуемым кодом за период N. Нужно накопить некоторый процент такого кода на проекте, — чтобы постоянно не заниматься клинингом. И при достижении определенного объема выделить время и заняться уборкой».

Кейс 3.2. Клининг неиспользуемого API. Код не только требует поддержки, но и хранит уязвимости. Агентский опыт Red Collar: «Если не чистить старый api, будут риски для системы. Получим монстра Франкенштейна: сервис работает хорошо, но при этом имеет много дыр».

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

Кейс 3.3. Клининг неиспользуемых частей сервиса или отпиливание целых разделов. Это самый глобальный кейс, который не укладывается в определение «результат рефакторинга не виден пользователю». Если вы уберете целый раздел, пользователи могут заметить, особенно если на место старого вы не выкатили что-то новое — ссылки побьются, или по ним пользователь не найдет то, чего ожидал.

Агентский опыт Red Collar: «Cо временем любой долгосрочный проект обрастает новыми фичами или разделами, которые могут полностью заменять старые.

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

Продуктовый опыт Авто.ру: «Мы часто пересматриваем нашу микросервисную архитектуру. Если копнуть, можно найти много взаимосвязей, потому что большие старые сервисы написаны на старых технологиях. Это мешает некоторым видам рефакторинга, — например, переезду на новый фреймворк. И выливается в затраты ресурсов, ведь под каждый микросервис выделяются отдельные инстансы.

Когда проекту 29 лет, в нем постоянно что-то отпиливается. Был кейс, когда «отпиливание» было видно пользователю — мы закрыли целый раздел, связанный с продажей запчастей и шин. Было очень много взаимосвязей, рефакторинг пронизывал весь проект».

Собрали все типы рефакторинга в сводную таблицу.

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

Если применимы все три вида рефакторинга, лучше придерживаться такой последовательности. Сначала вычистить все, что мешает → только потом переезжать на новый инструмент (после клининга переезд обойдется гораздо дешевле) → после этого можно заниматься оптимизацией → со временем при необходимости инициировать новый «клининг».

Но это не значит, что во всех случаях обязательны все три этапа. Можно свободно выбрасывать один из них, если он не нужен. Главное — посчитать параметры, которые мы перечислили в каждом блоке, и выстроить стратегию по рефакторингу системы, чтобы избежать лишних затрат.

Памятка от Авто.ру и Red Collar: как правильно провести рефакторинг: