Cómo Coinbase reescribió la aplicación en React Native

Hola a todos, soy Siri Wong, una gerente de ingeniería de Coibase. El año pasado, permití que la aplicación Coibase fuera reescrita de nativa a React Native, y hoy quiero compartir nuestra experiencia en este viaje. Así que hoy, voy a hablar sobre por qué reescribimos en React Native, y al principio, cómo abordamos la reescritura, la línea de tiempo del proyecto y los resultados clave, y luego compartir los desafíos y aprendizajes que tuvimos. Entonces, la primera pregunta es, ¿por qué reescribimos en React Native? A fines de 2019, observamos que nuestra velocidad para agregar una nueva función en la aplicación Coinbase no era muy buena. Para las funciones, tomaba varios meses en cada plataforma y mucha coordinación entre equipos. Esto no significa que la tecnología móvil nativa sea mala. Sin embargo, nuestra arquitectura de la aplicación era demasiado compleja y complicada para realizar cambios sin temor a las regresiones. La aplicación se había construido con muchos cambios a lo largo de muchos años. Intentamos solucionar la arquitectura, pero fue muy difícil arreglar los cimientos mientras teníamos mucha presión para construir una nueva función al mismo tiempo. Además, nuestros equipos en ese momento tenían alrededor de 8 personas en Android y 10 personas en iOS, divididos por plataforma en dos equipos. Esto también creaba desafíos de comunicación y consistencia. Por ejemplo, cuando construíamos funciones, necesitábamos verificar qué estaba haciendo otro equipo o plataforma. Y cuando había un error, necesitábamos verificar si ocurría en iOS, Android o ambos. La contratación también era otro desafío. Era realmente difícil contratar ingenieros nativos en comparación con ingenieros web en ese momento. Recuerdo que durante todo el año contratamos tal vez un ingeniero de Android o dos ingenieros de Android en ese momento. Intentamos convertir a algunos de los ingenieros web a Android, pero no tuvimos mucho éxito. Además, en Coibase en ese momento, teníamos un amplio grupo de talentosos ingenieros de JS. Teníamos muchos ingenieros de personal en el lado web. Eso hizo que React Native fuera una excelente opción para nosotros. Y con todo esto, estábamos pensando en reescribir nuestra aplicación principal de Coibase en React Native. Entonces, ¿cómo abordamos la reescritura? Primero, comenzamos con la aplicación de Android. ¿Por qué la aplicación de Android? En ese momento, nuestra aplicación de Android generaba menos de la mitad de los ingresos de iOS. La aplicación de Android también no tenía el mismo conjunto de funciones que iOS. Tenía muchas menos características. Y por lo tanto, era más fácil alcanzar la paridad de funciones. Además, teníamos menos personas en Android.

En comparación con la cantidad de ingenieros de iOS en ese momento. Por eso se eligió reescribir la aplicación de Android en React Native. Y veremos cómo sucede para React Native antes de pasar a iOS. En segundo lugar, estamos hablando de si debemos reescribir o hacer un enfoque Brownfield. Y decidimos hacer un enfoque Brownfield. Y como pueden ver, no vamos a reescribir o hacer un enfoque Greenfield debido a la complejidad. No es solo la complejidad, también hay varios otros desafíos. Por ejemplo, si tenemos una nueva función, debemos decidir qué función hacer en Nativo, qué funciones queremos hacer en React Native. Si modificamos las funciones existentes, ¿realmente debemos intentar convertirlas en React Native o Node.js? Esas son las preguntas que debemos responder si hacemos el enfoque Brownfield. Además, con el enfoque Greenfield, podemos crear un equipo separado que trabaje en la nueva aplicación, que esté separada de la aplicación existente. Por lo tanto, es más fácil reforzar los recursos necesarios para avanzar.

A continuación, integramos a los ingenieros de Android existentes en ese momento. El equipo original estaba compuesto por seis personas, y luego incorporamos a dos ingenieros de Android y los capacitamos en React Native. No habían trabajado en React Native con TypeScript antes, así que los capacitamos. Organizamos varias sesiones para diseñar la arquitectura de la nueva aplicación con el equipo de Android existente para aprender más sobre qué capa de datos vamos a utilizar, cómo manejar errores, navegaciones, enlaces profundos o cualquier peculiaridad nativa o módulos nativos que necesitemos escribir como parte de estas reescrituras. Luego creamos el documento de arquitectura y diseño para respaldar todos estos casos de uso actuales que tenemos en la aplicación existente. Por lo tanto, esos ingenieros, los ingenieros de Android, resultaron ser un valor increíble para el proyecto. No solo tienen contexto sobre cómo funciona la aplicación desde adentro hacia afuera, sino que también pueden consultar el código existente cuando los requisitos no están claros. Debido a que reescribimos desde cero, quiero decir que habrá muchas funciones que nadie conoce. También pueden trabajar en los módulos nativos ya que tienen experiencia en el lenguaje nativo, por lo que estos ingenieros de Android fueron clave para el éxito de nuestro proyecto. Antes de comenzar, también creamos el sistema de diseño basado en código que consta de primitivas como el color, el tema, la escala, la elevación, el diseño de espaciado y componentes como el control de botón de texto, las celdas de logotipo, las pestañas. Esos son los componentes clave, por lo que podemos construir la interfaz de usuario de manera mucho más fácil que construir una interfaz de usuario personalizada o tratar de adaptarla pantalla por pantalla. Y los ingenieros pueden centrarse en la funcionalidad en lugar de centrarse en la construcción de la interfaz de usuario, y como resultado, la interfaz de usuario es más consistente y se vuelve más pulida y de mayor calidad. Este sistema de diseño corporativo es la base que se utiliza y se mejora incluso hoy en día. Y lo último que hicimos fue establecer las métricas de control y la línea de tiempo al principio. Esto es muy importante para establecer las expectativas correctas, especialmente para la gerencia. Proporciona los hitos, la transparencia sobre cómo va el proyecto. Podemos evaluar el progreso del proyecto y tomar decisiones de continuar o detenernos en cualquier momento porque ya hemos establecido qué esperar. En cuanto a las métricas y los límites de control, es muy importante discutir, incluso antes de comenzar el proyecto, cómo se verá el éxito. Digamos que queremos lanzar la aplicación mañana, ¿cuáles serán las métricas? ¿Esperamos que las métricas se mantengan neutrales, aumenten o disminuyan, y cuánta disminución podemos tolerar? Especialmente para nuestra aplicación, cuánto

Los ingresos de la empresa en las métricas que podemos tolerar, realizando la implementación gradual, por ejemplo. Por lo tanto, esto es realmente crítico para alinearse al principio. Voy a hablar sobre el cronograma del proyecto y los resultados clave. Comenzamos el proyecto en marzo de 2020. En ese momento, no sabíamos que la reescritura sería exitosa. Es por eso que pueden ver que aquí, en el cronograma, todavía continuamos desarrollando Android nativo. Seguimos construyendo pantallas nativas de iOS con funciones de iOS. Comenzamos a obtener más información cuando alcanzamos el primer hito, que es el grupo de pruebas internas en julio. Entonces teníamos lo básico mínimo que solo podía realizar transacciones y verificar precios. Así que pudimos ver, sentir y usarlo, ponerlo en manos de las personas dentro de la empresa. Comenzamos a obtener más información sobre la duración del proyecto y también a ganar más confianza en el éxito del proyecto. En ese momento, detuvimos el desarrollo nativo de Android. Pero seguimos desarrollando en iOS, porque no sabíamos si el lanzamiento de Android iba a tener éxito. Y luego, en octubre de 2020, estábamos listos y lanzamos Android, y fue realmente exitoso en términos de métricas, participación del usuario y también métricas de rendimiento. Después de eso, continuamos agregando todas las funciones faltantes que iOS ya tenía. Y luego lanzamos en iOS en enero de 2021. Por lo tanto, todo el proyecto tomó un poco menos de un año desde el principio. En cuanto a los resultados clave, seguimos varias métricas clave tanto en Android como en iOS. En cuanto al rendimiento, no hubo regresiones en el rendimiento que estamos monitoreando. El tiempo de inicio de las llamadas mejora. El tiempo de transición de toque y las fallas también se redujeron en las métricas clave del negocio. De hecho, aumentaron en todas las métricas que estamos monitoreando, incluidos los ingresos. Y la calificación de la aplicación para Android, la calidad de la aplicación es mayor que antes, por lo que la calificación aumentó de 3.8 a 4.4. Fue realmente una sorpresa en la reescritura del proyecto en su conjunto. Pensamos que iba a ser neutral, pero en realidad es aún mejor. Quiero compartir los desafíos y los aprendizajes del proyecto de la aplicación que tuvimos. El primero es claramente el rendimiento. Como saben, React Native tiene un déficit de rendimiento en comparación con las versiones nativas. Pusimos énfasis en el rendimiento desde el principio. Medimos el rendimiento temprano, tratamos de reducir la cantidad de renderizaciones, que es aproximadamente un 10%, y en ese momento, nuestra capa de datos utilizaba el hook de estado que llamaba a múltiples API en la misma pantalla y causaba muchas renderizaciones. Por lo tanto, hicimos mucho

Optimización en el lado del cliente. Fue como almacenamiento en caché y escribimos algunas de las API principales durante el inicio en frío para agregarlas en una sola API y mejorar el tiempo de inicio en frío. Como resultado, el rendimiento de la aplicación no se ha visto afectado en comparación con antes. Durante el proyecto, creamos una herramienta para rastrear el rendimiento. La clave es enfocarse y medir las métricas de rendimiento desde el principio.

El siguiente desafío es decidir cómo implementar la nueva aplicación. Hemos estado debatiendo si queremos implementarla como una aplicación totalmente nueva o una aplicación combinada que contenga tanto versiones nuevas como antiguas junto con el interruptor. Con la complejidad del cronograma, decidimos optar por el enfoque más simple implementando la nueva aplicación y mitigando el lanzamiento utilizando el proceso de implementación lenta de Android en Play Store. Definitivamente no es fácil medir el impacto, ya que no tenemos control sobre quién recibe la versión antigua y quién recibe la nueva versión. Pero nos ayudó a ahorrar mucho tiempo y mitigar el riesgo de implementación.

Antes de implementar, nivelamos el programa beta, también realizamos una encuesta cualitativa a las personas que participaron en este programa. Medimos la puntuación antes y después, también detectamos algunos errores en el proceso. Lo que aprendimos es que necesitamos involucrarnos antes y crear un programa beta y asegurarnos de entender cómo implementar y medir las métricas correctamente. Otra cosa que es realmente importante es el apoyo de la dirección. La reescritura, especialmente a esta escala, es un proyecto de un año de duración. Significa que no pudimos desarrollar una nueva función durante un año. Esto genera mucha presión. La clave es mostrar progreso y pequeñas victorias. Esto ayuda a la dirección y también ayuda con los recursos y la comunicación. Necesitamos comunicarnos con ellos y asegurarnos de hacer un seguimiento en cada hito.

Una vez que un proyecto avanza, la dirección debe incorporar a los ingenieros nativos existentes que no están trabajando en el proyecto. Necesitamos cambiar y detener el proceso de contratación cambiando de nativo a React Native y TypeScript. Durante la implementación, hubo momentos en los que tuvimos que tomar una decisión sobre si debíamos avanzar o no según las métricas. Establecer expectativas desde el principio, progreso constante y comunicación son clave para obtener apoyo y alineación de la dirección. Otro aprendizaje es la replataformización de los ingenieros nativos existentes. Si lo pensamos bien, un ingeniero nativo fue contratado por una empresa y ahora les pedimos que cambien y vuelvan a aprender el nuevo lenguaje y plataforma, el TypeScript y React Native. Teníamos un plan. Tenemos un programa de capacitación. Les brindamos apoyo y mentoría para garantizar que la transición sea exitosa. También proporcionamos pautas sobre cómo evaluamos el rendimiento individual de cada persona durante la transición para asegurarnos de no penalizarlos debido al cambio de plataforma y que no puedan operar al más alto nivel.

La replataformización es definitivamente un desafío, pero factible. Y también en nuestro caso, tuvimos la suerte de no tener rotación de personal como parte de la transición. Después de lanzar, podemos ver el éxito de las personas, las transiciones y el desarrollo de funciones en React Native. Al comienzo del proyecto teníamos alrededor de 20 ingenieros nativos y ahora estamos contratando más ingenieros y aumentando el número a más de 100 ingenieros y seguimos creciendo. La clave es proporcionar transparencia a todos los ingenieros nativos existentes. Cómo los vamos a capacitar, cómo vamos a establecer las expectativas correctas durante la transición y cada hito, cuándo van a dejar de desarrollar en nativo en la aplicación existente, cuándo van a pasar a la nueva aplicación y cómo va a funcionar eso. Así que necesitamos brindarles apoyo durante la transición. Y esa es la historia de cómo reescribimos la aplicación CODES. Gracias.

Hola, qué bueno verte, bueno, verte en tu cara. Feliz de tenerte aquí, más o menos en Londres. Gracias por tu charla. Tenemos algunas preguntas interesantes de nuestra audiencia, así que vamos a entrar en ellas. Todos ustedes todavía pueden hacer preguntas y votar las preguntas que deseen que se respondan, por supuesto.

La primera pregunta es de Alice. ¿Consideraron compartir componentes y funcionalidad entre sus sitios web con React y esta nueva aplicación de React Native? Por supuesto, sí. Sabes, a largo plazo queremos lanzar la primera aplicación web en móvil, pero aún no estamos ahí. Primero necesitamos que el código se vea igual, usar las mismas tecnologías utilizando el sistema de diseño y también la capa de datos cuando las agreguemos en la lista de reproducción. Estamos lanzando en el mismo entorno, por lo que todo eso será mucho más fácil. Muy bien. Gracias. La siguiente pregunta es de Tom D. Es una buena pregunta. ¿Qué herramientas utilizaron para medir y comparar el rendimiento entre las dos aplicaciones? Sí, tenemos nuestro propio registro personalizado para comparar realmente el rendimiento. Pero inicialmente, simplemente hacíamos la comparación lado a lado y veíamos las diferencias de rendimiento obvias para poder solucionarlas. Pero en cuanto a las métricas que estábamos observando, una de ellas es el inicio en frío definitivamente. Y luego la carga de página o el cambio de pestaña que estamos utilizando. De acuerdo, gracias. La siguiente pregunta es de un usuario anónimo. Un recordatorio, si quieres ganar una camiseta, no debes publicar como anónimo, sino usar tu nombre real si estás aquí o tu ID de Discord si estás viendo de forma remota. Oh, esa fue la misma pregunta también sobre el rendimiento.

La siguiente pregunta es de Alice nuevamente. ¿Cuál es la división de código o módulos de tu aplicación entre los módulos nativos que has creado personalmente y el uso de los módulos existentes de React Native en la comunidad? ¿Puedes repetir la pregunta nuevamente? ¿Cuál es la división de código o módulos de tu aplicación entre los módulos nativos que has creado personalmente y el uso de los modelos existentes de React Native en la comunidad? Sí, utilizamos una combinación de ambos. Creo que utilizamos la navegación de React y algunos módulos personalizados que necesitamos utilizar, como por ejemplo, para la biometría. Por lo tanto, estos son módulos personalizados porque necesitamos realizar lógica personalizada allí. Así que hay una combinación de ambos.

De acuerdo, la siguiente pregunta es de Anna. Ella pregunta, veo que les llevó casi un año reescribir Coinbase. ¿Cuántos desarrolladores están trabajando en esto? Sí, inicialmente eran alrededor de seis personas, originalmente, y el equipo creció a medida que avanzaba el proyecto. Así que al final del proyecto, probablemente había alrededor de 10 o 12 personas. Así que, en promedio, si tomo un promedio, llevó a ocho desarrolladores un año. Sí. Sí. Muy bien, genial. Y ahora, por supuesto, tienes una mayor velocidad, porque solo tienes una base de código y todos los desarrolladores pueden trabajar en esa misma base de código. Sí, tenemos más de 100 desarrolladores en esta base de código. Genial.

Vamos a ver. La siguiente pregunta es de Lauren. ¿Tuvieron que capacitar a sus ingenieros en este nuevo lenguaje? Y si es así, ¿ahorraron tiempo a largo plazo en lugar de a corto plazo? Sí, creo que realmente capacitamos a muchas personas de Android y especialmente en iOS. Así que ahorrar tiempo para los ingenieros nativos existentes, no diría que realmente ahorró tiempo, pero se convirtieron correctamente. Queremos asegurarnos de que se configuren y midan correctamente, ¿verdad? Porque aprendiste el lenguaje nativo durante muchos años, y ahora debes aprender React Native. Pero el ahorro de tiempo es más a largo plazo, porque estamos contratando, en este momento, a más de 100 ingenieros en el cliente en sí. Eso es, como, una parte de ello, y también la velocidad que tenemos en la aplicación. La parte de la capacitación es, como, tal vez 10 personas o 15 personas, originalmente, que están en Nativo.

De acuerdo, y una pregunta para mí en el medio. ¿Encontraste alguna resistencia en el equipo de personas que no querían o realmente querían recibir capacitación como desarrolladores de React Native o JavaScript? Sí, totalmente. Creo que esto es algo que necesitábamos comunicar de manera transparente, porque como sabes, muchas personas pueden no querer realmente hacer React, o React Native, si haces Android, probablemente en general, o haces iOS, Swift, creo que lo clave es que necesitamos brindar el apoyo y asegurarnos de que tengan una capacitación, como cómo vamos a medir el rendimiento para todas estas personas. Así que, afortunadamente, todos necesitan realmente en React Native y se convierten con éxito, no tenemos ninguna rotación en sí, diría que tal vez una persona que quiere probar algo totalmente diferente, como backend y todo eso. De acuerdo, así que es bueno que el equipo estuviera bastante alineado todavía.

Muy bien, siguiente pregunta. ¿Recomendarías a partir de ahora construir todas tus aplicaciones en React Native o todavía hay ventajas en tener una aplicación nativa separada?

Sí, veo el beneficio de haber venido de la aplicación nativa y ahora estar en el mundo de React Native. Depende de la aplicación. Para la aplicación de Coinbase, creo que tiene sentido utilizar React Native. Realizamos muchas cosas en el lado del servidor y la interfaz de usuario es bastante sencilla en ciertos aspectos. Por lo tanto, si desarrollas juegos o algo que tenga mucho contenido multimedia, en ese caso, puede que no funcione para ese tipo de aplicaciones. Pero para nosotros, creo que funciona bien. Muy bien. Bueno, eso es todo el tiempo que tenemos para preguntas. Me gustaría que nominaras a un ganador para nuestra camiseta gratuita. Entonces, ¿cuál crees que fue la mejor pregunta? Bueno, no sé qué preguntas tenemos hasta ahora. Creo que las preguntas sobre tal vez el módulo nativo pueden ser realmente buenas. Sí, cuál es la división entre los módulos nativos y los módulos de la comunidad de React. Sí, exactamente. Esa fue la pregunta de Alice. Alice, ¿estás aquí? Alice, ven al escenario y te daré una camiseta.