Hola a todos, mi nombre es Gevorg. Soy jefe de dispositivos móviles en Profi.ru. Quiero compartir con ustedes la historia de nuestro experimento con React Native. Te diré cómo evaluamos los pros y los contras del desarrollo en React Native, en teoría y en la práctica. El artículo será útil para aquellos que estén interesados en el desarrollo móvil multiplataforma, pero aún no han decidido si seguir este camino o no.
Máxima aceleración
Todo comenzó con el hecho de que decidimos acelerar el desarrollo 10 veces a nivel de empresa. Fijamos una meta imposible para ir más allá del horizonte habitual de eventos y probar cosas nuevas. Todos los equipos de desarrollo de Profi.ru se encargaron de los experimentos. En ese momento, la compañía tenía 13 desarrolladores móviles nativos, incluidos yo y dos líderes de equipo. Mi equipo trabajó en dos aplicaciones móviles. En el primero, los clientes buscan especialistas, en el segundo, expertos en clientes. Para mí, este período fue incomprensible y emocionalmente estresante. Según mis sentimientos, hicimos tanto que todo funcionó rápidamente.
Utilizamos una arquitectura común en todo el proyecto y monitoreamos la pureza del código. Generadores usados que crean todos los archivos del módulo. Intentaron eliminar toda la lógica de negocios en el backend. Configuramos CI / CD y aplicaciones cubiertas con pruebas E2E. Debido a todo esto, algunas aplicaciones se lanzaron de manera estable una vez por semana. No tenía idea de cómo acelerar el desarrollo ni siquiera dos veces. Con mucho, a las 10. Por lo tanto, determinamos lo que es importante para nosotros.
- Código de base unificado. Quería que todos nuestros desarrolladores móviles escribieran el mismo código. En un idioma, sin diferencias de plataforma entre iOS y Android. Entonces podríamos acelerar el desarrollo a la mitad.
- Nueva herramienta fácil de aprender. Para que al expandir el equipo no tengamos problemas con el reciclaje o la contratación.
- Lanzamientos rápidos. Para que podamos lanzar no una vez por semana, sino todos los días.
- Actualizaciones instantaneas. Para que todos los usuarios reciban actualizaciones de inmediato. Como está sucediendo ahora en el desarrollo web.
Después de una breve revisión, aparecieron tres candidatos: React Native, Flutter, Kotlin / Native. Ni Flutter ni Kotlin Native pueden ser liberados rápidamente. Y consideramos esto quizás el más importante. Además, estas tecnologías eran completamente crudas en ese momento. Nos decidimos por React Native: se puede lanzar al instante. Además, la mayoría de nuestros desarrolladores ya han usado React.
En general, fui negativo sobre las herramientas multiplataforma, como la mayoría de los desarrolladores móviles nativos. Vaya a cualquier conferencia móvil y hable sobre esto; inmediatamente lo apedrearán. Me encanta esto :-) Por lo tanto, para confirmar o refutar los temores, llevamos a cabo nuestra investigación.
Pros, riesgos y problemas
Estudiamos ejemplos del uso de React Native en diferentes empresas: exitoso y no tan bueno. Con el Jefe de Desarrollo, Borey Egorov leyó cuidadosamente más de tres docenas de artículos y otros materiales. Algunos discutieron cada párrafo. Al final del artículo, enlaces a los más interesantes. Notamos los puntos que pueden acelerarnos, posibles riesgos y preguntas. Después de eso, hablamos con desarrolladores de tres compañías. En cada uno de los chicos crearon un producto masivo y trabajaron con React Native durante al menos un año.
Con los profesionales, todo era bastante obvio.
- Código de base general.
- Over-the-Air, o actualización por aire, sin pasar por la tienda.
- De los dos primeros puntos se deduce que aumentará la velocidad de entrega de funciones a los usuarios.
- Los desarrolladores web podrán escribir código para aplicaciones móviles. Si un desarrollador web conoce React bien, puede aprender rápidamente React Native. Y si el desarrollador móvil ya conoce esta plataforma, puede ingresar al desarrollo web con relativa rapidez.
La lista de riesgos fue más larga :-)
El primer riesgo . En lugar de una plataforma, a la larga nos vemos obligados a admitir tres: Android, iOS y React Native.
A veces la pantalla del desarrollador se ve así:
Realidad Uno de nuestros interlocutores inyectó React Native en el código existente. Sí, aparece una tercera plataforma completa, pero no va a ningún lado desde el desarrollo nativo. Su equipo tuvo que sincronizar el estado entre React Native y el código nativo. Esto implicó una gran cantidad de cambios entre diferentes piezas de código / diferentes paradigmas e IDE. Por lo tanto, decidieron escribir un nuevo proyecto desde cero, crear un marco en React Native y ya insertar piezas nativas allí donde se necesitan. Se puso mejor.
El segundo riesgo. Reaccionar Native Black Box: a veces hay situaciones en las que un desarrollador no comprende por qué apareció un error. Debe buscar en todas partes: en el código React Native, en la parte nativa del producto o en la plataforma React Native.
Realidad Los chicos con los que hablamos envolvieron la aplicación con registros y varias herramientas: Crashlytics, Kibana, etc. Los problemas persisten, pero queda claro dónde surgen.
El tercer riesgo. A menudo se ha encontrado en artículos que React Native es adecuado para proyectos pequeños, pero no para productos grandes con funcionalidad de plataforma.
Realidad Analizamos si hay grandes compañías en el mercado que trabajan con React Native. Resultó que hay docenas, si no cientos. Incluyendo Skype, Tesla, Walmart, Uber Eats y Kitchen en el área.
Cuarto riesgo. Cada vez que actualiza su sistema operativo desde Apple o Google, el proyecto puede interrumpirse.
Realidad Decidimos que el riesgo era perfectamente aceptable. El mismo riesgo existe para el desarrollo nativo. Cuando sale el nuevo sistema operativo para iOS y Android, adaptas tu aplicación a él.
El quinto riesgo. No hay soporte de sistema de 64 bits en Android, y el problema ha estado abierto desde 2015. Y desde agosto de 2019, Google Play no ha aceptado versiones que solo admitan sistemas de 32 bits.
Realidad Analizamos el problema en el que trabajó el equipo React Native en el verano de 2018. Prometieron agregar soporte en la próxima versión, aunque todavía no han arreglado completamente el soporte para el sistema de 64 bits. Esto muy molesto. Posteriormente se agregó soporte, pero algunos dispositivos Android caen después de la transición. Como descubrimos más tarde, el porcentaje es escaso, pero aún así fue el punto más doloroso para mí.
Sexto riesgo. La probabilidad de que mañana, Apple o Google lancen una nueva versión de su sistema operativo y rompan React Native. O una nueva tecnología que Profi.ru, en principio, no podrá soportar.
Realidad No hay garantías para nosotros o para muchas otras compañías. O te das cuenta del riesgo y lo haces, o intentas otra cosa. Decidimos hacer y resolver todos los problemas a medida que estén disponibles.
Séptimo riesgo. No podríamos decir de antemano qué tan rápido React Native se comparará con la aplicación nativa y qué rendimiento mostrará.
Realidad La cita literal de uno de nuestros interlocutores es "listas de elementos de altura variable cuando el desplazamiento se ralentiza". Decidimos comprobar en la práctica. Un poco por delante: al momento de escribir el primer prototipo de la aplicación, no vimos ese problema, pero cuando desarrollamos una aplicación completa, había muchas preguntas sobre el rendimiento de React Native.
Octavo riesgo. No está claro qué tan rápido podemos encontrar desarrolladores de React Native. En HeadHunter encontré cerca de 300 hojas de vida, a pesar del hecho de que había más de 150 mil desarrolladores para iOS.
Realidad No profundizaron aquí, ya que habían contratado a desarrolladores de React más de una vez y sabían qué buscar. Decidimos que, como último recurso, podemos volver a capacitar a los desarrolladores de React en React Native.
También existía el riesgo de que alguien dejara el equipo, ya que a los desarrolladores móviles no les gusta esta tecnología. Por cierto, tenía razón. Alguien se fue :-(
Estoy cansado de escribir React Native, así que lo que sigue es solo RN :-)
Que cambiamos y que no
Discutimos los resultados de la investigación con los fundadores de la compañía, Sergey Kuznetsov y Yegor Rudi, y obtuvimos el visto bueno para el experimento.
Decidimos crear un nuevo producto desde cero y no insertarlo en uno existente. Y también, no toque nuestra aplicación cliente. Era bastante maduro, y económicamente no tenía sentido cambiar radicalmente algo. Además, para nosotros era importante que la aplicación cliente tuviera su propia experiencia nativa tanto para iOS como para Android.
Pero queríamos cambiar radicalmente la solicitud de especialistas. A diferencia del cliente, no nos avergonzaba que los especialistas tuvieran la misma experiencia de interacción para las aplicaciones iOS y Android. Además, creemos que en un producto para especialistas podemos prescindir de la animación y los efectos visuales. Pero antes de que todo el equipo cambiara a una nueva tecnología, era necesario sentir cómo funciona.
Experimenta en acción
En diciembre de 2018, reunimos un equipo de tres personas. Dos desarrolladores de React y un nativo: yo. Entiendo cómo funciona Android, y estoy bien versado en el desarrollo de iOS.
Como parte del experimento, queríamos verificar los siguientes puntos:
- cómo funcionan los lanzamientos instantáneos en RN;
- cómo es la interacción entre los componentes nativos y RN;
- podemos usar nuestros componentes nativos;
- cómo funciona RN con cámara, push y diplink;
- cómo funcionan la navegación y el ahorro de estado en RN;
- por lo que podemos hacer con RN pixel perfect;
- cómo funciona la prueba automática en RN;
- qué tan rápido el desarrollador nativo o React puede aprender la tecnología.
Obtuvimos los primeros resultados dentro de un mes y medio después de sumergirnos en el desarrollo.
- Comencé a escribir código bajo RN después de solo dos semanas. Para mí, la tecnología era completamente sencilla. Uno de nuestros desarrolladores de React me ayudó mucho: habló sobre React / Redux y JS en general. Era necesario entrar en las complejidades de React / Redux, pero después de un tiempo la "neurona comenzó a aprender", como dice nuestra compañía :-)
- Me sorprendió gratamente que, de alguna forma, JS + Flow proporcione un tipeo fuerte. Para JS, tenía expectativas mucho más bajas. Al mismo tiempo, definitivamente preferiría Swift y Kotlin: para mí son muchas veces más hermosos y agradables que JS, pero aquí las palabras principales son "para mí".
- Nos ayudó que el equipo incluía desarrolladores que pueden escribir código para iOS, Android y React. Cada plataforma tiene sus propios problemas específicos. Para resolverlos, el equipo debe ser multifuncional.
- Los lanzamientos instantáneos funcionan. Para mí es como magia. No es necesario esperar a los lanzamientos y actualizaciones de Apple. Se busca, toma y libera.
- Muy a menudo el proyecto se estropeaba. Esto realmente no es genial. Tomó los cambios de la rama, intenta ejecutar, y no importa. Fue muy molesto. En algún momento, acabamos de escribir un script que limpia el proyecto por completo. Esto no quiere decir que resolvieron el problema en su conjunto, sino que terminaron la mayor parte.
- Aún así, tenemos que trabajar con tres plataformas, a pesar de que principalmente escribimos código en RN. Todos los desarrolladores tenían tres IDEs: Xcode, Android Studio, WebStorm.
- Pushas, enlaces profundos, cámara, inicio de navegación. Pero comienzan con la ayuda de bibliotecas de terceros, o las bibliotecas en el código nativo deben escribirse usted mismo y luego conectarse a RN.
Al final del artículo quiero volver al título. Entonces, ¿es la RN una bala de plata para todos los problemas? Decidimos por nosotros mismos que no. Al mismo tiempo, obtuvieron lo que querían. Hemos aumentado varias veces la velocidad de entrega de funciones y ahora podemos lanzarlo a todos los usuarios todos los días. También es importante que hayan aparecido equipos interfuncionales en la empresa, donde cada desarrollador escribe código tanto en Android / iOS como en la web.
Y sí, las aplicaciones en la tienda :-)
Artículos útiles sobre React Native
- Por qué Discord se queda con React Native - Fanghao (Robin) Chen
- Cómo amé y odié reaccionar nativo - Andrey Melikhov
- Reaccione Native desde el punto de vista de un desarrollador móvil - Andrey Konstantinov
- Reaccionar nativo en Instagram - Instagram Engineering
- React Native: una retrospectiva del equipo de ingeniería móvil en Udacity - Nate Ebel
- React Native: batallas de hechos en un acto - Samat Galimov
- Sunsetting React Native - Gabriel Peal