React Native в Airbnb: Создание кроссплатформенной мобильной команды
Адаптация мобильной разработки к жизни в мире с React Native.
Перевод статьи Gabriel Peal: Building a Cross-Platform Mobile Team. Опубликовано с разрешения автора.
Это третья статья в серии, в которой мы поделимся нашим опытом с React Native и расскажем, что ждёт в дальнейшем мобильную разработку в Airbnb.
В дополнение к бесчисленным техническим плюсам и минусам React Native мы получили множество знаний о том, что React Native означает для инженерной организации. Принятие его гораздо сложнее, чем добавление новой библиотеки или шаблона к существующей платформе. Это выявило ряд организационных проблем. В отличие от технических проблем, которые часто могут быть решены или эффективно «исправлены костылями», организационные проблемы могут быть сложны для обнаружения, исправления и и последующего восстановления. К счастью, наша культура мобильной разработки здорова, но есть ряд вещей, о которых нужно знать при рассмотрении React Native.
Восприятие React Native склонно к поляризации мнений
По нашему опыту, инженеры подошли React Native с совершенно разными мнениями, варьирующимися от восхваления его как серебряной пули, которая объединила Android, iOS и веб, до полного неприятия любого использования React Native в своей команде. Такая же ситуация произошла и после его использования. Некоторые команды имели невероятный опыт, в то время как другие сожалели об этом и вернулись к нативной разработке.
Определение причин проблем
Во время работы над React Native, были неизбежные ошибки, полировка, и проблемы с производительностью. Тем не менее, можно выделить основные причины проблем:
- React Native быстро развивается.
- Мы занимались одновременным развитием инфраструктуры и функционала.
- Инженеры изучали Reac Native вместе, и он был относительно новым для всех.
- Наша документация и руководство по отладке в разработке и продакшене иногда были непоследовательными и могли сбивать с толку.
В результате часто бывает трудно найти первопричину проблемы. Иногда не было ясно, какой команде следует приписать проблему или была ли проблема присуща React Native.
React Native по-прежнему Native
Распространенное заблуждение заключается в том, что React Native позволяет полностью отказаться от написания нативного кода. Однако, это не текущее положение вещей. Нативный фундамент React Native время от времени все еще поднимает голову. Например, текст отображается немного по-разному на каждой платформе, клавиатуры обрабатываются по-разному, а Activities пересоздаются при повороте экрана на Android. Качественный опыт React Native требует тщательного баланса обоих миров. Это, в сочетании с трудностью наличия сбалансированного опыта на всех трех платформах, затрудняет создание приложений неизменно высокого качества.
Отладка на разных платформах
Большинство инженеров владеют одной или двумя платформами. Чрезвычайно редко кто-то может быть очень компетентным в Android, iOS и React. Несмотря на то, что подавляющее большинство работы в зрелой среде React Native выполняется с JavaScript и React, бывают случаи, когда построение или отладка чего-то требует копания в нативном коде. Эти ситуации могут привести к тому, что инженеры застревают в разработке, пытаясь отладить проблему на платформе, которую они никогда не использовали. Еще хуже, когда инженер даже не уверен, где искать из-за сложности определения первопричины.
Найм новых разработчиков
Несмотря на то, что мы инвестировали в React Native, наши мобильные амбиции и команды продолжали параллельно расширяться. Тем не менее, через сарафанное радио в сообществе, многие люди начали ассоциировать Airbnb с React Native, а некоторые даже считали, что наше приложение было на 100% React Native. Несмотря на то, что это было далеко от истины, многие Android- и iOS-инженеры в результате не решались обратиться к Airbnb. На всякий случай, если вы один из них, мы все еще нанимаем!
Гибридные приложения сложны
Путь развития приложения, которое является 100% нативным или 100% React Native относительно прост. Однако, как только у вас есть смесь из двух миров в вашей кодовой базе, возникает много новых проблем. Как вы разделяете свои команды? Как команды сотрудничают? Как поделиться состоянием в приложении? Как вы гарантируете, что всё будет проверено? Как инженеры эффективно отлаживают код на трех платформах? Как вы решаете, какую платформу использовать для новой функции? Как вы нанимаете и распределяете ресурсы в вашей организации? Это все проблемы с нетривиальными решениями, которые неизбежно возникнут, если вы пойдете по этому пути.
Три среды разработки
Чтобы быть эффективным React Native инженером, важно иметь стабильную и актуальную среду React Native, Android и iOS. Для такой крупной организации, как Airbnb, каждой платформе требуется значительное количество времени для настройки, изучения и обновления. Возвращение через несколько недель часто означало несколько часов подготовки, чтобы вернуться в курс дела.
Баланс между Native и React Native
Существует множество ситуаций, в которых оптимальное решение проблемы охватывает нативный код и React Native. Например, наша реализация навигации интенсивно использует Activities и ViewControllers, и большая часть ее кода является нативной для каждой платформы. Часто бывает, что неясно, должен ли код быть написан на нативном языке или на React Native. Естественно, инженер будет часто выбирать платформу, которая ему наиболее комфортна, что приводит к неидеальному коду.
Кроссплатформенное тестирование
Мы обнаружили, что инженеры часто при разработке используют только одну платформу для удобства или из-за комфорта. Часто они предполагают, что если код работает на платформе, на которой они его протестировали, он будет отлично работать и на другой. Большую часть времени это было правдой, что является свидетельством силы React Native. Однако частота ошибок этого утверждения была достаточно высока, что в итоге становится причиной частых проблем во время QA цикла или на продакшене.
Разделение команд
Команды, которые работали как с нативной частью, так и с React Native, часто сталкивались с техническими и коммуникационными проблемами. Как только кодовая база была разделена между нативным кодом и React Native, код стал фрагментированным. Разделение бизнес-логики, моделей, состояния и так далее стало слишком сложным, и инженеры больше не имели экспертизы для понимания процессов целиком. Мы знали, что это произойдет с самого начала, но думали, что это может быть сбалансировано расширением сотрудничества с веб. Несколько команд начали делиться ресурсами и кодом между вебом и мобильными устройства, но большинство из них не смогли реализовать эту потенциальную выгоду.
Воспринимаемая скорость разработки
Одной из наших качественных целей с React Native было увеличение скорости развития. Часто, новые возможности, реализованные с помощью React Native, были написаны одним инженером вместо нескольких отдельных разработчиков для каждой платформы. С точки зрения React Native инженера, если им требуется на 50% больше времени, чтобы закончить свою задачу, чем решение аналогичной задачи на Android или iOS, они чувствуют что работают медленней, даже если это занимает меньше часов в целом.
Публичные ресурсы и документация
У Android и iOS было десять лет и миллионы инженеров, вносящих вклад в учебные ресурсы, открытый исходный код и онлайн-помощь. Мы используем многие ресурсы, такие как CodePath, чтобы помочь людям изучить Android и iOS. Несмотря на то, что React Native имеет одно из крупнейших кроссплатформенных сообществ и может использовать ресурсы React, это сообщество по-прежнему намного меньше, чем Android и iOS. В сочетании с тем фактом, что мы должны были построить большую часть нашей внутренней инфраструктуры это означало, что наши ограниченные ресурсы React Native были чрезмерно инвестированы в образование и обучение по сравнению с нативной разработкой.
Это третья часть в серии записей, освещающих наш опыт работы с React Native в Airbnb.
Часть 1: React Native в Airbnb
Часть 2: Технология
Часть 3: Создание кроссплатформенной мобильной команды
Часть 4: Принятие решения по React Native
Часть 5: Что дальше с мобильной разработкой
Слушайте наш подкаст в iTunes и SoundCloud, читайте нас на Medium, контрибьютьте на GitHub, общайтесь в группе Telegram, следите в Twitter и канале Telegram, рекомендуйте в VK и Facebook.
