Привет, Хабр! На связи снова Саша Мищенко, тимлид платформенной команды в Профи.ру. И сегодня я хочу поделиться нашей большой и, на мой взгляд, поучительной историей переезда с нативного кода на React Native.

Если кратко, то было интересно и иногда даже страшно. Баги, сложности, неочевидные подводные камни… В общем, история получилась длинная, поехали.

Начало. Большая мечта

Всё началось с мечты компании — стать масштабным маркетплейсом с высокой узнаваемостью. Но это слишком абстрактно, поэтому мы сформулировали цель поконкретнее: вырасти в 10 раз.

Амбициозно, да? Ещё как. Вот и стали думать, как этой цели достичь. Придумали вариант: радикально повысить скорость разработки.

У компании было (и есть) два основных продукта для тестирования этой гипотезы:

1. Бэк-офис — веб- и мобильные приложения для специалистов платформы (техников, электриков, сантехников и т. д.). Для них главное — функциональность приложения, а не продвинутый интерфейс. 

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

Изначально оба этих продукта были написаны нативно: отдельно на iOS, отдельно на Android. Про это время могли бы рассказать старички или экс-сотрудники. Если будет интересно, созвонюсь с ними и расспрошу. 

И вот именно у них появилась идея перевезти бэк-офис-приложение на React Native.

Почему выбрали именно его? 

• Единый стек: у нас бэкенд активно переезжал на Node.js, а фронт всегда был на реакте. И тогда мы подумали, что будет круто, если вообще вся разработка будет на одном языке — на TypeScript: так намного легче управлять ресурсами для задач, проводить онбординг и растить горизонтальность разработчиков.

• Удобная организация команд: вместо разделения по технологиям (на iOS, на Android и на веб) мы перешли к нескольким департаментам. Одни занимаются платформой, другие — продуктом. О них рассказывал в прошлой статье.

Часть 1. Бэк-офис. История успеха

Переезд начали с бэк-офиса. На этом этапе меня ещё не было в команде, поэтому рассказываю со слов коллег. 

В приложении для специалистов не было ни сложных анимаций, ни многоступенчатого интерфейса. Благодать для быстрой и безболезненной миграции! Команда из 2–3 энтузиастов буквально за несколько месяцев переписала нативное приложение на React Native.

И жили дальше. Команды действительно стали работать быстрее. Горизонтальная структура сработала — разработчики могли гибко переключаться между задачами. Ускорения достигли и решили двигаться дальше. И через какое-то время начали думать о миграции клиентского приложения…

Часть 2. Ожидание vs реальность

Тут я уже присоединился к команде, рассказываю от первого лица. Мы загорелись идеей переписать на RN и наше клиентское приложение. Надеялись, что будет примерно так же гладко, как и с бэк-офисом.

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

Итак, с какими проблемами мы столкнулись на практике.

Первая и самая очевидная — производительность. 

Мы упёрлись в классическое узкое горлышко — мостик между нативом и RN. Он должен был бороться со злом, а не примкнуть к нему… Так мы получили лаги и подвисания сначала из-за сериализации данных, потом из-за десериализации и т. д. 

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

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

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

Вторая проблема была уже на уровне экосистемы. 

Комьюнити React Native небольшое и молодое. Мы это особенно прочувствовали, когда нужно было внедрить яндекс-карту. Нативная реализация у ребят очень крутая, а вот под RN библиотек нет. 

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

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

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

Наконец, третья бесячая проблема — это бесконечная борьба с обновлениями.

React Native пока что в версии 0.х.х, и это значит, что любое обновление минорной версии может нести в себе мажорные изменения, которые очень даже могут всё сломать.

Поэтому каждое обновление обязательное, а это недели или даже месяцы работы: нужно проверить все наши кастомные модули, переписать код под изменившиеся API, найти замену сломавшимся библиотекам и провести полное тестирование. 

А отказаться нельзя. Apple и Google ежегодно ужесточают требования к версиям SDK. Не обновишься — твоё приложение просто не пустят в стор. В общем, сложная и рискованная миграция стала для нас не выбором, а вынужденным шагом.

Да, звучит не очень. Но! Когда компания готовилась к миграции, она об этом знала, да и мы были готовы. Собственно, поэтому и создали платформенную команду — группу разрабов, которые могут и хотят брать на себя и технический долг, и архитектурные риски, и проблемы инфраструктуры. 

Думали ли мы ещё о чём-то, кроме RN? Конечно! Например, смотрели в сторону Flutter. У него всё сильно лучше с производительностью и с комьюнити.

Но тогда мы бы потеряли универсальность наших разработчиков. Пришлось бы доучивать старичков новому языку Dart или привлекать новичков. Этого в наших планах не было.

Поэтому отказались.

В общем, пожалели ли мы? Не-а.

Спустя время и с учётом новых реалий я могу сказать вот что: это было правильное решение для нашей компании, но… неидеальное. 

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

Минусы:
— Разработчики тратят часы на обновления RN, поиск библиотек и подбивку решений.
— Есть риск выгорания. Иногда хочется просто писать код, а вместо этого борешься с лагами и багами. Это выматывает.
— Нужно много и часто коммуницировать с дизайнерами и продуктологами. Часть фич приходится упрощать или вовсе убирать, если их нельзя внедрить в несколько шагов.

Вывод

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

А у вас, кстати, был опыт работы с React Native? С какими проблемами столкнулись? Будет интересно почитать и, может быть, даже взять на заметку.