Особенности миграции на фронтенде: итоги панельной дискуссии с экспертами Wrike, Яндекс, Kaspersky и Leroy Merlin

Привет, Хабр! Несколько месяцев назад Wrike публично объявил об отказе дальнейшей разработки на Dart и переходе на новый стек.

Это было сложное решение. И, как это часто бывает во времена больших перемен, нам захотелось сравнить и провести параллели. А как происходила миграция у других компаний? Чем она была вызвана, и удалось ли завершить процесс перестройки без серьезных потерь?

Мы попросили коллег поделиться своим опытом миграции на фронтенде, рассказать о всех сомнениях и трудностях, что встретились на этом пути.

Во встрече приняли участие:

• Иван Синеговский, Senior FE Developer, TeamLead, Wrike

• Георгий Конюшков, FE Developer, Leroy Merlin

• Алексей Пименов, Dev.Lead, Kaspersky Lab

• Виталий Косенко, старший разработчик интерфейсов, Яндекс.Поиск

В этом тексте мы подведем итоги панельной дискуссии в виде небольшого конспекта: тезисно и с цитатами. Полную видеозапись встречи вы найдете в конце статьи.

Причины миграции

Причины для смены стека (языка, фреймворка) могут быть разными:

• Изменение приоритетов развития, часто вызванное внешними причинами (например, история Wrike — переключение внимания Google от AngularDart (фактически сансеттинг) в сторону Flutter for Web).

• Желание получить новые конкурентные преимущества на рынке за счет перехода на более прогрессивные технологии (например, сократив time to market — случай Leroy Merlin).

• Желание оставаться на пике технологий, выбирая популярный стек с развитым коммьюнити (случай Kaspersky Lab).

• Проблемы с наймом сотрудников, которые не хотят идти на «несовременный стек».

• Экономическая нецелесообразность поддержки старых решений (обе причины — случай Яндекс.Поиск).

Иван Синеговский: Подавляющая часть нашего фронтенд-кода написана на Dart. Но примерно год назад мы начали поглядывать в сторону альтернативных языков и фреймворков. Главная причина — Google прекращает поддержку Dart Angular, смещая приоритет в сторону Flutter. В течение нескольких месяцев мы рассматривали разные стеки и библиотеки, в итоге остановились на связке TypeScript и React. После этого начался тяжелый период интеграции нового стека в наши процессы.

Георгий Конюшков: Мы хотели сократить time to market. Несколько лет назад на основном сайте мы использовали технологии вроде Adobe Experience Manager. Это крайне неповоротливая и сложная в обращении система, написанная на Java. И при интеграции новых фичей и даже фиксе багов time to market достигал месяца-полтора. Для бизнеса это было абсолютно невалидно, поэтому архитекторы компании решили пойти в сторону нового решения, использующего связку React с TypeScript. Как итог — сейчас time to market снизилось в разы. Мы уже можем доставлять фичи за полспринта.

Алексей Пименов: Когда я пришел в Лабораторию Касперского, там был еще Flow и самописный Redux. Чуть позже стало понятно, что TypeScript становится суперпопулярен, что появились новые способы борьбы с ненужным кодом в Redux. В итоге мы сначала избавились от Flow, переписав всё на TypeScript маленькими кусочками, а затем подключили Redux Toolkit, переписав всю логику, которая была связана с Redux. Это позволило облегчить жизнь новым сотрудникам. До нашей миграции им приходилось тратить много времени, чтобы погрузиться в самописные решения.

Виталий Косенко: Поисковая страница Яндекса мигрировала с довольно древних технологий на TypeScript и React. Серверная шаблонизация сначала существовала на БЭМ, а на клиенте был jQuery. И при миграции мы хотели решить две проблемы. Первая — с наймом. Стало тяжело искать людей, которые бы хотели работать на наших проприетарных технологиях. Вторая — с опенсорсным движением, которое стало популярно, и все маленькие сервисы в него влились. Теперь инструменты вроде БЭМ мы должны были поддерживать только для себя. Не самое разумное вложение средств. Тогда и пришло решение использовать широкоизвестные технологии, в которые вкладываются все.

Как понять, что миграция вам необходима

В идеальном мире миграция на новый стек происходит в нужный момент и в спокойном режиме. Участники дискуссии выделили несколько факторов, которые подтолкнут к исследованию и переходу на новые технологии:

• Высокий уровень сложности поддержки существующих решений.

• Все те же проблемы с наймом новых сотрудников.

• Жалобы текущих сотрудников компании на используемые технологии.

• Упорство разработчиков в объяснении плюсов миграции и здравая культура аргументации в компании.

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

Виталий Косенко: В нашей компании было несколько попыток, когда разработчики вместе с дизайнерами объединялись и экспериментировали на новом стеке. Из этого ничего не вышло, но людей надо было спасать. Если бы мы не разрешили писать на React официально, они бы делали это по ночам или во время праздников. Это хороший пример упорства со стороны разработчиков. Они как бы вызывают начальство на осознанный разговор. Не на уровне «мы хотим писать на React, потому что это модно», но с аргументами вроде «смотрите, React больше не проигрывает в производительности, другие компании мигрируют». Это такие понятные причины, которые нельзя игнорировать.

Как правильно выбрать направление миграции

Уже в процессе исследования важно не ошибиться при выборе новой технологии. На что нужно обратить внимание?

• Простота и гибкость новой технологии.

• Ее популярность.

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

Иван Синеговский: Мы практически сразу выбрали новый язык: TypeScript сейчас очень популярен, конкурентов у него нет. А вот с библиотеками было несколько вариантов. Здесь нам пришлось встраивать решение на TypeScript в существующую архитектуру. И Angular, к сожалению, нам не подошел. Это большое enterprise-решение, заточенное под определенный способ разработки. А React — это просто библиотека шаблонизации, к тому же довольно гибкая.

Георгий Конюшков: После проведения ресеча мы остановились на React и TypeScript. В том числе благодаря их популярности, возможности нанимать разработчиков без особого труда. В нашей компании просто нет специалистов, которые бы писали на Angular, Vue или Svelte. Разве что маленькое и тайное сообщество ребят, которые сидят в подвале и тихонько что-то мастерят.

Как не сломать продукт, мигрируя

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

• Поддерживать только новые решения и отказаться от прошлого опыта (осторожно, дорого!).

• Перейти на микрофронтенды и переписывание продукта по кусочкам (дальновидно).

• Уделить большое внимание тестам (обязательно).

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

Иван Синеговский: Мы в Wrike постелили соломку перед миграцией, перейдя на микрофронтенды. Это позволило переписывать продукт по кусочкам, не затрагивая его основные части. Эксперименты мы ставили на тех участках, которыми пользователи пользуются редко. Сначала тестили их на нашем аккаунте, а потом делились с пользователями и отслеживали реакцию. У нас большое покрытие кода тестами. В момент переписывания одного приложения на другое мы проводим регрессионное тестирование, потом немного тестим вручную, и этого достаточно.

Как переписывать не все сразу

Многие компании, включая Wrike, уже успели перейти к микросервисному подходу. Казалось бы, миграция при такой архитектуре должна пройти бесшовно и мягко. Но всем ли компаниям он подходит?

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

Иван Синеговский: Идея разбить продукт на микрофронтенды возникла тогда, когда наша компания начала сильно расти. В отделе инжиниринга оказалось 400-450 человек. В то же время деплои у нас происходят каждый день, со временем этот процесс стал болезненным. Команды заливали в одну ветку кучу инкрементов, возникало много конфликтов. Поэтому мы приняли решение разбивать продукт на независимые части. Сейчас это позволяет командам деплоиться независимо и не стоять в очередях. Плюс это сильно помогает в миграции с Dart на TS: берешь микрофронтенд и переписываешь, не затрагивая остальные приложения и процессы в компании.

Мигрировали. И что дальше?

После миграции наступает нелегкий период адаптации. К новому продукту привыкают разработчики. С продуктом знакомятся и новые сотрудники. Как сделать этот процесс максимально простым и удобным?

Виталий Косенко: Изначально после миграции мы не готовили документацию. И на наших первых Md-страничках было написано что-то вроде: «Тут используется React. Вся информация на react.org». Аналогично и с TS. Но сотрудники стали жаловаться, что нуждаются в четких инструкциях, что им не нравится жизнь по правилам Дикого Запада. Самым трудным было разобраться, как написать документацию на то, на что уже есть документация. В итоге появились тексты: как мы используем React и TypeScript, как заводятся эксперименты и фичи, как пишутся и раскладываются компоненты, как их лучше именовать. После того, как всю эту информацию мы отразили в документации, жить стало легче.

Алексей Пименов: У нас в Confluence не так давно появилась страничка, которая называется Best Practices. В ней по разделам прописаны моменты, которые касаются разных аспектов нашей жизни. В том числе и миграции. Мы даем прочесть буквально 150 строк текста, где содержится информация: какие у нас решения сейчас, какие были раньше, почему мы их поменяли, с какими проблемами сталкивались. Это удобно как для текущих сотрудников, так и для новичков, которые сразу оказываются с нами на одной волне.

Георгий Конюшков: В нашем Confluence находится гигантский массив информации вроде Developer journey, описаний компонентов, данных о дизайн-системе. Это кропотливый труд и разработчиков, и дизайнеров, который закрывает многие боли и экономит время. Недавно в команду пришел новый человек, мы кинули ему весь пакет документации по микрофронтенду. И ему удалось «въехать» в платформу меньше, чем за неделю.

Иван Синеговский: Когда мы переводили на TS наши крупные решения, то максимально вели документацию в Wiki. И сейчас она наполнена информацией. Но мы пошли дальше и записали пять видеолекций, в которых осветили темы: что такое TypeScript и React, чем они отличаются от AngularDart. Раскрыли подробности, как у нас работает webpack, linting. Мы делимся лекциями не только с текущими, но и с новыми разработчиками. Они могут буквально за день понять, с чем им предстоит иметь дело дальше.

Видеозапись круглого стола смотрите на нашем Youtube-канале.