Por qué creemos que Flutter nos ayudará a escalar el desarrollo móvil en Nubank

[🇧🇷 disponível em Português]

Nubank ha sido una Fintech centrada en los dispositivos móviles desde el principio. Comenzamos nuestro desarrollo móvil con aplicaciones nativas para nuestra tarjeta de crédito, compatibles con plataformas Android e iOS en 2013 y rápidamente adoptamos Kotlin y Swift después de su anuncio. Durante un tiempo, admitimos la plataforma Windows Phone.

A medida que la empresa creció (ahora somos el banco digital independiente más grande fuera de Asia), el desarrollo de nuevos productos más allá de la tarjeta de crédito se convirtió en una prioridad, y los nuevos equipos tuvieron que descubrir cómo se enviarían a nuestras aplicaciones.

¿Pero cómo? Bueno, ¿por qué no probar React Native?

El tercer producto de Nubank fue una cuenta de ahorro digital.

Cuando el equipo de cuentas de Nubank contó con personal en 2016, nos enfrentábamos a un desafío: no había suficientes especialistas móviles nativos disponibles. Y tampoco fue fácil contratar, vimos (y todavía vemos) una competencia feroz por estos profesionales en el mercado laboral.

Queríamos desarrolladores móviles dedicados al equipo de cuentas de Nubank porque ya sabíamos que los equipos especializados no escalan. Creemos en equipos autónomos, ágiles y multifuncionales, que trabajen juntos desde el Concepción hasta la Producción, evitando traspasos y siendo responsables de la calidad, las operaciones y la evolución de sus productos. Creemos que los equipos individuales que desarrollan funciones de un extremo a otro ofrecen más valor y más rápido. 

Escribir el mismo artículo dos veces, sólo que en diferentes idiomas y plataformas, y tener que aprenderlos todos, parecía un desperdicio. Aprender una plataforma híbrida para ofrecer funciones reduciría la barrera de entrada para que los desarrolladores de backend contribuyan al frontend móvil.

En ese momento, React Native era una alternativa establecida, respaldada por algunos grandes jugadores. Además de eso, nuestra cultura de ingeniería se trata de aprendizaje y mejora continuos (dejamos claro que es responsabilidad de todos aprender y experimentar en el trabajo), por lo que es fácil entender por qué el equipo de cuentas de Nubank decidió experimentar con esta tecnología multiplataforma.

La cuenta de Nubank ha alcanzado un gran éxito, con más de 13 millones de clientes, que han ahorrado hasta 305 millones de dólares en los últimos cinco años al no pagar una serie de comisiones (a septiembre de 2019). Todos han utilizado una aplicación desarrollada con React Native + GraphQL, una pila tecnológica muy diferente a la utilizada por cualquiera de las plataformas nativas.

La historia de React Native en Nubank es algo de lo que estamos muy orgullosos y merece una publicación aparte.

Pero hoy queremos hablar de nuestro siguiente paso. Después de todo, no importa cuán exitosa sea una herramienta o plataforma, nuestros ingenieros continúan aprendiendo y experimentando con nuevas tecnologías:

“Hola gente linda de este canal. Después de nuestra presentación (yo + @ring) sobre el pico de Flutter durante el Hackathon de cuentas de Nubank, hubo muchas personas interesadas en la tecnología y el lenguaje (Dart). Después de hablar con algunos de ustedes, sugerí que tuviéramos un Flutter Dojo para aquellos que quieran familiarizarse con el lenguaje, la sintaxis, los patrones y las pruebas. Si no sabes qué es un Dojo, hay una explicación en el hilo. La idea es elegir un problema simple (TodoMVC, tal vez) y crear una aplicación desde cero usando TDD, con todos los que están allí. Es importante resaltar que este Dojo es 100% educativo; es decir, el código que escribamos no será utilizado más adelante. ¡El evento será el jueves, a la hora del almuerzo, con pizza! …”

Consulte nuestras oportunidades laborales 

Una cultura de experimentar y aprender rápidamente.

A principios de 2019, los equipos de nuevos productos, como Cuentas Comerciales y Préstamos, ahora tenían la opción de volverse nativos o probar React Native.

Casi al mismo tiempo, la industria ya había mostrado avances significativos en tecnologías móviles (solo algunos anuncios de 2019): Kotlin como lenguaje preferido para Android, Swift 5 ABI Stability, Flutter 1.0, actualizaciones de la gobernanza comunitaria de React Native).

Entonces, nos encontramos discutiendo cómo respaldar mejor la productividad de nuestros ingenieros al ofrecer funciones para nuestra aplicación. Éstos fueron algunos de los problemas:

• Para los ingenieros que están interesados en ser más completos, la barrera de entrada era demasiado alta. Para contribuir a la tarjeta de crédito, había que aprender Kotlin para Android, Swift para iOS y, para ayudar a la cuenta de Nubank, también era necesario aprender React Native.
• ¡Sin mencionar el hecho de que la arquitectura de cada una de estas opciones era muy diferente! Nuestra hipótesis es que, al reducir la barrera de entrada para el desarrollo móvil, Nubank verá más ingenieros contribuyendo al código base.
• Otro cuello de botella que encontramos al depender de desarrolladores de plataformas nativas especializadas para cada nueva característica o lanzamiento de producto fue la “pesadilla de personal.” A pesar de nuestros mayores esfuerzos de contratación, nunca hubo suficientes desarrolladores para dotar de personal completo a nuestros equipos de productos.

Rápidamente nos dimos cuenta de que nuestros equipos eran más importantes que una pila de tecnología y que tener todas estas opciones causaba incomodidad y confusión. Era hora de investigar seriamente cuál de las tecnologías multiplataforma se adaptaría mejor a las necesidades de Nubank.

Así que nos propusimos formar un grupo de trabajo con la misión de investigar y determinar, con la participación de toda la ingeniería de software, qué tecnología deberíamos estandarizar, considerando Kotlin Native, React Native y Flutter como alternativas. 

El objetivo era tomar una decisión de tal manera que, independientemente de la especialización de sus miembros, los equipos fueran autónomos y productivos para desarrollar la aplicación móvil y ofrecer valor en una única arquitectura, lenguaje de programación y conjunto de convenciones.

El grupo de trabajo

Formamos un pequeño equipo con desarrolladores móviles experimentados en Nubank. Determinaron 11 criterios para ser evaluados en un proyecto de investigación. Aquí hay una breve descripción de las preguntas de las 5 prioridades principales:

1. Experiencia del desarrollador: ¿Qué permite a un desarrollador ofrecer valor y ser productivo? Ejemplos: recarga en caliente; visibilidad de los componentes; herramientas de depuración; integración IDE; y herramientas de prueba.

2. Viabilidad a largo plazo: Representa el nivel de confianza en el futuro de la plataforma. ¿El mantenedor seguirá apoyándolo a largo plazo (cinco años)? ¿Qué posibilidades hay de que la comunidad apoye el proyecto si quien lo mantiene decide abandonarlo? 

3. Sin especialización en plataforma: Un ingeniero debería poder escribir un código móvil para el producto sin diferenciar entre Android e iOS. ¿El código se ve y se comporta igual en Android e iOS, con una baja incidencia de problemas específicos del sistema operativo? 

4. Costo de abstracción incremental: El coste de ampliar la plataforma para cada tarea de producto y la fricción de centralizar el trabajo en extensiones, si es necesario. ¿Qué tan difícil será agregar un nuevo componente? ¿Crearíamos una dependencia de un equipo de plataforma horizontal? 

5. Riesgo de abstracción no lineal: Riesgo de requerir repentinamente reescrituras extensas y desproporcionadas de nuestra abstracción interna. ¿Necesitaríamos realizar cambios no triviales en todo el código base para admitir un nuevo componente NuDS (Nubank Design System)? 

Luego nos propusimos recopilar evidencia y acordar una puntuación subjetiva para cada uno de ellos mediante el uso de diferentes técnicas como:

• probar una versión de Flutter de una de nuestras funciones en producción
• analizar comunidades, repositorios y recursos disponibles para cada plataforma
• participar en conversaciones con especialistas, equipos y empresas detrás del desarrollo de las plataformas
• implementar un clon de una de nuestras funciones como una aplicación independiente en las tres plataformas diferentes
• realizar una prueba de usabilidad interna, en la que los ingenieros novatos y experimentados realizaron cambios en la función en las aplicaciones descritas anteriormente
• realizar presentaciones, debates y visitas de equipo para discutir nuestros hallazgos, las opiniones de ingenieros auditivos y asesores senior, incorporar sus comentarios y responder sus preguntas

Los resultados de las pruebas de usabilidad fueron los más interesantes. Personas de todos los niveles y procedencias (incluidos ingenieros principiantes sin experiencia previa en desarrollo en dispositivos móviles) realizaron una prueba de una hora. Recibieron una aplicación funcional, un entorno de desarrollo, documentación de la plataforma híbrida y sus componentes, y algunas tareas de codificación cada vez más complejas. Fueron observados por nuestro equipo mientras ejecutaban las tareas y ambos respondieron un cuestionario al final.

Por ejemplo, los ingenieros tuvieron que agregar una función para que los usuarios pudieran tocar botones de ″acceso directo″ con valores predeterminados para depositar dinero en su cuenta de ahorros:

La aplicación clonada funciona a través del flujo de creación de código de barras “boleto”, comenzando con un campo de entrada para el valor que el cliente desea depositar en su cuenta.

El resultado de un desafío de programación para pruebas de usabilidad de desarrolladores: 

Los ingenieros tuvieron que agregar tres botones con valores fijos al flujo de depósito de la cuenta.

Escribimos un informe de nuestra investigación, recopilando los hallazgos y detallando cómo evaluamos cada criterio. Encontrará un enlace para solicitar el informe completo al final de este artículo. Fue difícil tomar una decisión, incluso después de recopilar una gran cantidad de información, tuvimos que centrarnos en los siete criterios más importantes para llegar a los siguientes resultados:

A partir de nuestras propias experiencias (el 80% de nuestro código base de Android es Kotlin, la cuenta de Nubank está desarrollada en React Native) y evaluando nuestras alternativas frente a las prioridades de Nubank, sentimos que Kotlin es un excelente lenguaje con el que trabajar. Pero Kotlin Native es la única plataforma que no proporciona una abstracción de interfaz de usuario, lo que la hace dependiente de las herramientas de la plataforma nativa para el desarrollo y las pruebas. Si bien obtuvo una puntuación más alta en nuestros criterios de prioridad más baja, al no mostrar limitaciones de capacidades ni riesgos por las restricciones de la tienda de aplicaciones, sentimos que, especialmente cuando se trata de probar el soporte para ingenieros expertos, Kotlin Native no está listo para nosotros.

Temíamos un sesgo hacia React Native, por lo que conscientemente redujimos la prioridad de otro criterio: el costo de construir la abstracción inicial en la plataforma, donde React Native fue un claro ganador. 

Cuando se analizan criterios más importantes, React Native también gana en apoyo de la comunidad. 

No sentimos miedo por la continuidad y evolución del proyecto y quedamos muy contentos con la cantidad de documentación y aprendizaje. Un gráfico de radar que muestra la puntuación de cada criterio de 0 a 5 para cada una de las plataformas disponible. Sin embargo, cuando se trata de cambios importantes, descubrimos que React Native tiene más dependencias que las otras alternativas. Por lo tanto, es mucho más vulnerable a los problemas de mantenimiento y actualización.

Nuestra cultura de ingeniería fomenta firmemente la automatización de pruebas, por lo que Flutter brilló con sus excelentes capacidades de prueba que encajan muy bien con nuestra mentalidad (infraestructura de prueba integrada para pruebas unitarias, de integración y de extremo a extremo sin la necesidad de renderizar en la pantalla). Por el contrario, React Native requiere dependencias de terceros, lo que lo hace más propenso a sufrir cambios importantes. Descubrimos que la experiencia de desarrollo de Flutter es superior, con mejores capacidades de recarga en caliente, documentación oficial sólida y una API más estable.

Después de mucha discusión y controversia hasta el último minuto, decidimos utilizar Flutter como la tecnología principal de Nubank para el desarrollo móvil. Significa que escribiremos nuevas funciones en Flutter y, a medida que el producto evolucione, esperamos que se convierta en un porcentaje mayor de nuestro código base.

Estamos increíblemente emocionados de compartir este estudio el mismo día en que anunciamos el lanzamiento de una función muy esperada: la función de “puntos de transferencia” del Programa de Recompensas se creó con Flutter.

Conclusión: ¿cómo se siente usar Flutter?

Hasta ahora, ha sido fantástico usar Flutter y esperamos tener más funciones creadas o migradas a Flutter para nuestros usuarios muy pronto.

Tener que incluir Flutter en una aplicación en ejecución con millones de clientes conlleva su propio conjunto de desafíos que estamos superando gradualmente, siendo el primero de ellos:

• cambios en los canales de construcción,
• creando los principales canales de la plataforma,
• integrando el enrutamiento entre React Native, Flutter, Kotlin y Swift para que podamos mantener la interoperabilidad.

Si bien Flutter será nuestra tecnología principal, todavía necesitamos y valoramos a los desarrolladores nativos, porque cada plataforma tiene su conjunto de características que requieren código nativo (por ejemplo, complementos nativos como GPS y cámara, Apple Watch, aplicaciones minimizadas de Android, etc.). Además, a medida que crece el equipo de ingeniería de software de Nubank, la especialización individual es bienvenida.

Para cualquiera que esté considerando Flutter, hemos puesto a disposición para descargar nuestro informe completo con datos detallados, pros y contras. Tenga en cuenta que lo que funciona para Nubank puede no funcionar para usted. 

También recomendamos mirar las experiencias de otras empresas. Si bien hay empresas que utilizan Flutter o React Native, Dropbox abandonó su tecnología multiplataforma (C++) debido al “coste (no tan) oculto de compartir código entre iOS y Android” y AirBnB se decidió por “descartar React Native.”

Written by Alexandre Freire and Vinicius Andrade
Reviewed by André Moreira, Rafael Ferreira, Ana Paula Maia and Paula Rothman.