Всем привет, меня зовут Геворг. Я Head of Mobile в Profi.ru. Хочу поделиться с вами историей нашего эксперимента с React Native. Расскажу, как мы оценивали плюсы и минусы разработки на React Native — в теории и на практике. Статья будет полезна тем, кто интересуется кросс-платформенной мобильной разработкой, но пока не решил, идти в эту сторону или нет.
Всё началось с того, что мы решили ускорить разработку в 10 раз на уровне компании. Поставили невыполнимую цель, чтобы выйти за привычный горизонт событий и попробовать новое. Все команды разработки Profi.ru взялись за эксперименты. На тот момент в компании было 13 нативных мобильных разработчиков, включая меня и двух тимлидов. Моя команда работала над двумя мобильными приложениями. В первом клиенты ищут специалистов, во втором — специалисты клиентов. Для меня этот период был непонятным и эмоционально напряжённым. По моим ощущениям, мы и так много делали, чтобы всё работало быстро.
Использовали общую архитектуру на всём проекте и следили за чистотой кода. Использовали генераторы, которые создают все файлы модулей. Всю бизнес-логику старались выносить на backend. Настроили CI/CD, а приложения покрыли E2E-тестами. За счёт всего этого стабильно релизили некоторые приложения раз в неделю. Я понятия не имел, как ускорить разработку даже в два раза. Куда уж в 10. Поэтому мы определили, что для нас важно.
После небольшого ресёрча появились три кандидата: React Native, Flutter, Kotlin/Native. Ни во Flutter, ни в Kotlin Native релизить быстро нельзя. А мы считали это едва ли не самым важным. Кроме того, эти технологии были совсем сырые на тот момент. Мы остановились на React Native — на нём можно релизить моментально. Плюс большая часть наших разработчиков уже использовала React.
Вообще я негативно относился к кросс-платформенным инструментам — как и большинство нативных мобильных разработчиков. Сходите на любую мобильную конференцию и поговорите об этом — вас сразу же закидают камнями. Сам люблю это дело :-) Поэтому, чтобы подтвердить или опровергнуть опасения, мы провели своё расследование.
Мы изучили примеры использования React Native в разных компаниях — удачные и не очень. С Head of Dev Борей Егоровым внимательно прочитали более трёх десятков статей и других материалов. В некоторых обсуждали каждый абзац. В конце статьи — ссылки на самые интересные. Мы отметили моменты, которые могут нас ускорить, возможные риски и вопросы. После этого пообщались с разработчиками из трёх компаний. В каждой ребята создавали массовый продукт и работали с React Native не меньше года.
С плюсами было всё довольно очевидно.
Список рисков был длиннее :-)
Риск первый. Вместо одной платформы мы в долгосрочной перспективе вынуждены поддерживать три: Android, iOS и React Native.
Иногда экран разработчика выглядит примерно вот так:
Реальность. Один из наших собеседников внедрял React Native в существующий код. Да, появляется полноценная третья платформа, но ты никуда не уходишь от нативной разработки. Его команде приходилось синхронизировать состояние между React Native и нативным кодом. Это влекло за собой много переключений между разными частями кода / разными парадигмами и IDE. Поэтому они решили написать новый проект с нуля, сделать каркас на React Native, а уже в него вставлять нативные куски там, где они нужны. Стало лучше.
Риск второй. React Native Black Box — иногда бывают ситуации, когда разработчик не понимает, из-за чего появился баг. Приходится искать везде: в React Native коде, в нативной части продукта или в самой платформе React Native.
Реальность. Ребята, с которыми мы общались, обкладывали приложение логами и разными инструментами: Crashlytics, Kibana и так далее. Проблемы остаются, но становится понятно, в каком месте они возникают.
Риск третий. В статьях часто встречалось, что React Native подходит для маленьких проектов, но не для больших продуктов с платформенной функциональностью.
Реальность. Мы посмотрели, есть ли на рынке большие компании, которые работают с React Native. Оказалось — их десятки, если не сотни. В том числе Skype, Tesla, Walmart, Uber Eats и «Кухня на районе».
Риск четвёртый. При каждом обновлении операционной системы от Apple или Google проект может сломаться.
Реальность. Решили, что риск вполне допустимый. Такой же риск есть и для нативной разработки. Когда выходит новая OS для iOS и Android, ты адаптируешь своё приложение под неё.
Риск пятый. Нет поддержки 64-битной системы в Android, причем issue открыто с 2015 года. А с августа 2019 года Google Play не принимает в сторы сборки, которые поддерживают только 32-битные системы.
Реальность. Мы посмотрели issue, над которым команда React Native работала летом 2018 года. Они обещали добавить поддержку в следующем релизе, хотя ещё не починили до конца поддержку 64-битной системы. Это сильно огорчало. Поддержку потом добавили, но некоторые Android-устройства падают после перехода. Как мы выяснили потом, процент мизерный, но всё равно это был самый болезненный для меня пункт.
Риск шестой. Вероятность, что завтра Apple или Google выпустят новую версию своей OS и сломают React Native. Или новую технологию, которую Profi.ru в принципе не сможет поддерживать.
Реальность. Тут нет никаких гарантий ни для нас, ни для множества других компаний. Ты либо осознаёшь риск и делаешь, либо пробуешь что-то другое. Мы решили делать, а все проблемы решать по мере поступления.
Риск седьмой. Мы не могли сказать заранее, насколько React Native будет быстрым по сравнению с нативным приложением и какую производительность будет показывать.
Реальность. Дословная цитата одного из наших собеседников — «списки элементов переменной высоты при скролле тормозили». Решили проверить на практике. Немного забегу вперёд — на момент написания первого прототипа приложения мы такой проблемы не увидели, но когда разрабатывали полноценное приложение, возникло множество вопросов по производительности React Native.
Риск восьмой. Непонятно, насколько быстро мы сможем найти разработчиков React Native. На HeadHunter я нашёл около 300 резюме, при том что разработчиков для iOS там было более 150 тысяч.
Реальность. Тут сильно углубляться не стали, так как уже не раз нанимали React-разработчиков и знали, на что обращать внимание. Решили, что в крайнем случае сможем переобучить React-разработчиков в React Native.
Ещё был риск, что кто-то уйдёт из команды, так как эту технологию мобильные разработчики недолюбливают. Кстати, я оказался прав. Кто-то ушел :-(
Я устал писать React Native, поэтому дальше будет просто RN :-)
Мы обсудили результаты расследования с основателями компании Сергеем Кузнецовым и Егором Руди и получили добро на проведение эксперимента.
Решили создавать новый продукт с нуля, а не делать вставки в существующий. А ещё — не трогать наше клиентское приложение. Оно было довольно зрелым, и экономически не имело смысла что-то кардинально менять. Кроме того, нам было важно, чтобы в клиентском приложении был свой нативный опыт и для iOS, и для Android.
А вот приложение для специалистов мы хотели поменять радикально. В отличие от клиентского, нас не смущало, что у специалистов будет одинаковый опыт взаимодействия для приложений iOS и Android. Плюс мы считаем, что в продукте для специалистов можем обойтись без анимации и визуальных эффектов. Но прежде чем перейти всей командой на новую технологию, надо было пощупать, как она работает.
В декабре 2018 года мы собрали команду из трёх человек. Двух React-разработчиков и одного нативного — меня. Я понимаю, как работает Android, и хорошо разбираюсь в iOS-разработке.
В рамках эксперимента мы хотели проверить следующие пункты:
Первые результаты мы получили уже через полтора месяца после погружения в разработку.
В конце статьи хочется вернуться к заголовку. Так является ли RN серебряной пулей для всех проблем? Мы для себя решили, что нет. В то же время получили, что хотели. Мы увеличили в несколько раз скорость доставки фич и теперь можем релизить на всех пользователей каждый день. Также важно, что в компании появились кросс-функциональные команды, где каждый разработчик пишет код, как в Android/iOS, так и в вебе.
И да, приложения в сторах :-)
Максимальное ускорение
Всё началось с того, что мы решили ускорить разработку в 10 раз на уровне компании. Поставили невыполнимую цель, чтобы выйти за привычный горизонт событий и попробовать новое. Все команды разработки Profi.ru взялись за эксперименты. На тот момент в компании было 13 нативных мобильных разработчиков, включая меня и двух тимлидов. Моя команда работала над двумя мобильными приложениями. В первом клиенты ищут специалистов, во втором — специалисты клиентов. Для меня этот период был непонятным и эмоционально напряжённым. По моим ощущениям, мы и так много делали, чтобы всё работало быстро.
Использовали общую архитектуру на всём проекте и следили за чистотой кода. Использовали генераторы, которые создают все файлы модулей. Всю бизнес-логику старались выносить на backend. Настроили CI/CD, а приложения покрыли E2E-тестами. За счёт всего этого стабильно релизили некоторые приложения раз в неделю. Я понятия не имел, как ускорить разработку даже в два раза. Куда уж в 10. Поэтому мы определили, что для нас важно.
- Единая кодовая база. Хотелось, чтобы все наши мобильные разработчики писали один и тот же код. На одном языке, без платформенных отличий iOS и Android. Так мы могли ускорить разработку в два раза.
- Простота в освоении нового инструмента. Чтобы при расширении команды у нас не было проблем с переобучением или наймом.
- Быстрые релизы. Чтобы мы могли релизить не один раз в неделю, а каждый день.
- Моментальные обновления. Чтобы обновления получали все пользователи сразу. Как это сейчас происходит в веб-разработке.
После небольшого ресёрча появились три кандидата: React Native, Flutter, Kotlin/Native. Ни во Flutter, ни в Kotlin Native релизить быстро нельзя. А мы считали это едва ли не самым важным. Кроме того, эти технологии были совсем сырые на тот момент. Мы остановились на React Native — на нём можно релизить моментально. Плюс большая часть наших разработчиков уже использовала React.
Вообще я негативно относился к кросс-платформенным инструментам — как и большинство нативных мобильных разработчиков. Сходите на любую мобильную конференцию и поговорите об этом — вас сразу же закидают камнями. Сам люблю это дело :-) Поэтому, чтобы подтвердить или опровергнуть опасения, мы провели своё расследование.
Плюсы, риски и вопросы
Мы изучили примеры использования React Native в разных компаниях — удачные и не очень. С Head of Dev Борей Егоровым внимательно прочитали более трёх десятков статей и других материалов. В некоторых обсуждали каждый абзац. В конце статьи — ссылки на самые интересные. Мы отметили моменты, которые могут нас ускорить, возможные риски и вопросы. После этого пообщались с разработчиками из трёх компаний. В каждой ребята создавали массовый продукт и работали с React Native не меньше года.
С плюсами было всё довольно очевидно.
- Общая кодовая база.
- Over-the-Air, или обновление по воздуху, в обход сторов.
- Из первых двух пунктов следовало, что скорость доставки фич до пользователей вырастет.
- Веб-разработчики смогут писать код под мобильные приложения. Если веб-разработчик хорошо знает React, то он может быстро освоить React Native. А если мобильный разработчик уже знает эту платформу, то может относительно быстро войти в веб-разработку.
Список рисков был длиннее :-)
Риск первый. Вместо одной платформы мы в долгосрочной перспективе вынуждены поддерживать три: Android, iOS и React Native.
Иногда экран разработчика выглядит примерно вот так:
Реальность. Один из наших собеседников внедрял React Native в существующий код. Да, появляется полноценная третья платформа, но ты никуда не уходишь от нативной разработки. Его команде приходилось синхронизировать состояние между React Native и нативным кодом. Это влекло за собой много переключений между разными частями кода / разными парадигмами и IDE. Поэтому они решили написать новый проект с нуля, сделать каркас на React Native, а уже в него вставлять нативные куски там, где они нужны. Стало лучше.
Риск второй. React Native Black Box — иногда бывают ситуации, когда разработчик не понимает, из-за чего появился баг. Приходится искать везде: в React Native коде, в нативной части продукта или в самой платформе React Native.
Реальность. Ребята, с которыми мы общались, обкладывали приложение логами и разными инструментами: Crashlytics, Kibana и так далее. Проблемы остаются, но становится понятно, в каком месте они возникают.
Риск третий. В статьях часто встречалось, что React Native подходит для маленьких проектов, но не для больших продуктов с платформенной функциональностью.
Реальность. Мы посмотрели, есть ли на рынке большие компании, которые работают с React Native. Оказалось — их десятки, если не сотни. В том числе Skype, Tesla, Walmart, Uber Eats и «Кухня на районе».
Риск четвёртый. При каждом обновлении операционной системы от Apple или Google проект может сломаться.
Реальность. Решили, что риск вполне допустимый. Такой же риск есть и для нативной разработки. Когда выходит новая OS для iOS и Android, ты адаптируешь своё приложение под неё.
Риск пятый. Нет поддержки 64-битной системы в Android, причем issue открыто с 2015 года. А с августа 2019 года Google Play не принимает в сторы сборки, которые поддерживают только 32-битные системы.
Реальность. Мы посмотрели issue, над которым команда React Native работала летом 2018 года. Они обещали добавить поддержку в следующем релизе, хотя ещё не починили до конца поддержку 64-битной системы. Это сильно огорчало. Поддержку потом добавили, но некоторые Android-устройства падают после перехода. Как мы выяснили потом, процент мизерный, но всё равно это был самый болезненный для меня пункт.
Риск шестой. Вероятность, что завтра Apple или Google выпустят новую версию своей OS и сломают React Native. Или новую технологию, которую Profi.ru в принципе не сможет поддерживать.
Реальность. Тут нет никаких гарантий ни для нас, ни для множества других компаний. Ты либо осознаёшь риск и делаешь, либо пробуешь что-то другое. Мы решили делать, а все проблемы решать по мере поступления.
Риск седьмой. Мы не могли сказать заранее, насколько React Native будет быстрым по сравнению с нативным приложением и какую производительность будет показывать.
Реальность. Дословная цитата одного из наших собеседников — «списки элементов переменной высоты при скролле тормозили». Решили проверить на практике. Немного забегу вперёд — на момент написания первого прототипа приложения мы такой проблемы не увидели, но когда разрабатывали полноценное приложение, возникло множество вопросов по производительности React Native.
Риск восьмой. Непонятно, насколько быстро мы сможем найти разработчиков React Native. На HeadHunter я нашёл около 300 резюме, при том что разработчиков для iOS там было более 150 тысяч.
Реальность. Тут сильно углубляться не стали, так как уже не раз нанимали React-разработчиков и знали, на что обращать внимание. Решили, что в крайнем случае сможем переобучить React-разработчиков в React Native.
Ещё был риск, что кто-то уйдёт из команды, так как эту технологию мобильные разработчики недолюбливают. Кстати, я оказался прав. Кто-то ушел :-(
Я устал писать React Native, поэтому дальше будет просто RN :-)
Что меняем, а что нет
Мы обсудили результаты расследования с основателями компании Сергеем Кузнецовым и Егором Руди и получили добро на проведение эксперимента.
Решили создавать новый продукт с нуля, а не делать вставки в существующий. А ещё — не трогать наше клиентское приложение. Оно было довольно зрелым, и экономически не имело смысла что-то кардинально менять. Кроме того, нам было важно, чтобы в клиентском приложении был свой нативный опыт и для iOS, и для Android.
А вот приложение для специалистов мы хотели поменять радикально. В отличие от клиентского, нас не смущало, что у специалистов будет одинаковый опыт взаимодействия для приложений iOS и Android. Плюс мы считаем, что в продукте для специалистов можем обойтись без анимации и визуальных эффектов. Но прежде чем перейти всей командой на новую технологию, надо было пощупать, как она работает.
Эксперимент в действии
В декабре 2018 года мы собрали команду из трёх человек. Двух React-разработчиков и одного нативного — меня. Я понимаю, как работает Android, и хорошо разбираюсь в iOS-разработке.
В рамках эксперимента мы хотели проверить следующие пункты:
- как работают мгновенные релизы в RN;
- как идёт взаимодействие между нативными компонентами и RN;
- сможем ли использовать наши нативные компоненты;
- как RN работает с камерой, пушами и диплинками;
- как работает навигация и сохранение состояния в RN;
- насколько можем делать с RN pixel perfect;
- как в RN работает автоматическое тестирование;
- насколько быстро нативный или React-разработчик сможет изучить технологию.
Первые результаты мы получили уже через полтора месяца после погружения в разработку.
- Я начал писать код под RN уже через две недели. Для меня технология оказалась совсем несложной. Мне очень помог один из наших React-разработчиков — он классно рассказал про React/Redux и JS в целом. Нужно было въехать в тонкости React/Redux, но через некоторое время «нейронка начала обучаться», как говорят у нас в компании :-)
- Я был приятно удивлён, что JS + Flow в каком-то виде дают строгую типизацию. По JS у меня были намного ниже ожидания. В то же время я точно отдал бы предпочтение Swift и Kotlin: они для меня в разы красивее и приятнее, чем JS, но тут главные слова «для меня».
- Нам помогло, что в команде были разработчики, которые умеют писать код и для iOS, и для Android, и для React. В каждой из платформ появлялись свои специфические проблемы. Чтобы их решать, команда должна быть кросс-функциональной.
- Мгновенные релизы работают. Для меня это как магия. Не надо ждать релизов и апрувов от Apple. Захотел — взял и выпустил.
- Очень часто проект ломался. Это реально не круто. Ты взял изменения с ветки, пробуешь запустить — и ни фига. Это сильно раздражало. В какой-то момент мы просто написали скрипт, который чистит проект полностью. Нельзя сказать, что решили проблему целиком, но большую часть добили.
- Всё равно приходится работать с тремя платформами, несмотря на то, что мы в основном пишем код на RN. У всех разработчиков стояли три IDE: Xcode, Android Studio, WebStorm.
- Пуши, диплинки, камера, навигация заводятся. Но заводятся либо с помощью сторонних библиотек, либо библиотеки в нативном коде надо писать самому, а потом подключать в RN.
В конце статьи хочется вернуться к заголовку. Так является ли RN серебряной пулей для всех проблем? Мы для себя решили, что нет. В то же время получили, что хотели. Мы увеличили в несколько раз скорость доставки фич и теперь можем релизить на всех пользователей каждый день. Также важно, что в компании появились кросс-функциональные команды, где каждый разработчик пишет код, как в Android/iOS, так и в вебе.
И да, приложения в сторах :-)
Полезные статьи про React Native
- Why Discord is Sticking with React Native — Fanghao (Robin) Chen
- Как я полюбил и возненавидел React Native — Андрей Мелихов
- React Native с точки зрения мобильного разработчика — Андрей Константинов
- React Native at Instagram — Instagram Engineering
- React Native: A retrospective from the mobile-engineering team at Udacity — Nate Ebel
- React Native: батл по фактам в одном действии — Samat Galimov
- Sunsetting React Native — Gabriel Peal