Por que achamos que o Flutter vai nos ajudar a escalar o desenvolvimento móvel no Nubank

[🇧🇷 disponível em Português]

Desde o início, o Nubank sempre foi uma Fintech voltada para dispositivos móveis. Nós iniciamos o nosso desenvolvimento móvel com aplicativos nativos para o nosso cartão de crédito, suportando as plataformas Android e iOS em 2013, e adotamos rapidamente a Kotlin e a Swift quando foram anunciadas. Por algum tempo, tivemos suporte para a plataforma Windows Phone.

Conforme a empresa cresceu e se tornou o maior banco digital independente fora da Ásia, desenvolver novos produtos além do cartão de crédito virou uma prioridade, e as novas equipes precisavam descobrir como desenvolver nossos aplicativos.

Mas como? Por que não experimentar o React Native?

O terceiro produto do Nubank foi uma conta-poupança digital.

Quando a equipe de contas do Nubank foi formada em 2016, nós tínhamos um desafio: não havia muitos especialistas em aplicações nativas para dispositivos móveis disponíveis. E também não era fácil contratar, pois havia (e ainda há) uma grande concorrência por esses profissionais no mercado de trabalho.

Nós queríamos desenvolvedores de aplicações móveis dedicados à equipe de contas do Nubank, pois já sabíamos que equipes especializadas não escalam. Nós acreditamos em equipes autônomas, ágeis e multifuncionais, trabalhando juntas do planejamento à produção, evitando delegações e sendo responsáveis pela qualidade, pelas operações e pela evolução de seus produtos. Acreditamos que equipes únicas desenvolvendo recursos de ponta a ponta entregam mais valor, mais rapidamente. 

Criar o mesmo recurso duas vezes, mas em linguagens e plataformas diferentes, além da necessidade de aprender todas elas, parecia um desperdício. Aprender uma plataforma híbrida para entregar recursos reduziria a barreira de entrada para que os desenvolvedores de backend contribuíssem com o frontend móvel.

Naquele momento, o React Native era uma alternativa estabelecida, que contava com o apoio de entidades importantes. Além disso, a nossa cultura de engenharia tem tudo a ver com aprendizado e melhoria contínuos (nós deixamos claro que é responsabilidade de todos aprender e fazer experimentos no trabalho), então é fácil entender por que a equipe de contas do Nubank decidiu experimentar essa tecnologia multiplataformas.

A conta do Nubank foi um grande sucesso, alcançando mais de 13 milhões de clientes, que economizaram cerca de US$ 305 milhões nos últimos cinco anos deixando de pagar várias taxas (a partir de setembro de 2019). Todos eles usaram um aplicativo desenvolvido com React Native + GraphQL, uma pilha de tecnologia bem diferente daquela usada pelas plataformas nativas.

Temos muito orgulho da história do React Native no Nubank, e isso merece uma postagem separada.

Mas hoje, queremos falar sobre o nosso próximo passo. Afinal, não importa o quanto uma plataforma ou ferramenta seja bem-sucedida, os nossos engenheiros continuam aprendendo e experimentando novas tecnologias:

“Olá, pessoas bonitas deste canal. Depois da nossa apresentação (eu + @ring) sobre o surto do Flutter durante a Maratona de Hacking do setor de contas do Nubank, surgiram muitas pessoas interessadas na tecnologia e na linguagem (Dart). Depois de conversar com alguns de vocês, sugeri que fizéssemos uma Oficina de Flutter para aqueles que quisessem aprender a linguagem e sua sintaxe, padrões e testes. Se você não sabe o que é uma Oficina (Dojo), tem uma explicação na thread. A ideia é escolher um problema simples (TodoMVC, talvez) e criar um app do zero usando TDD, com todo mundo que estiver lá. É importante destacar que essa Oficina é 100% educacional, ou seja, o código que criarmos não será usado depois. O evento será na quinta-feira, no horário do almoço, com pizza! …”

Confira nossas oportunidades de trabalho 

Conheça nossas oportunidades

Uma cultura de experimentar e aprender rapidamente

No início de 2019, as novas equipes de produtos, como Contas Comerciais e Empréstimos, tinham a opção de usar tecnologia nativa ou experimentar o React Native.

Mais ou menos na mesma época, o setor já havia mostrado avanços significativos nas tecnologias móveis (apenas alguns anúncios de 2019): Kotlin como linguagem preferida para Android, Estabilidade de ABI do Swift 5, Flutter 1.0, atualizações de governança da comunidade do React Native).

Então, estávamos discutindo como apoiar melhor a produtividade dos nossos engenheiros na entrega de recursos para o nosso aplicativo. Aqui estão alguns dos problemas:

• Para engenheiros que tinham mais interesse em atuar como full-stack, a barreira de entrada era alta demais. Para contribuir com o cartão de crédito, era necessário aprender Kotlin para Android, Swift para iOS e, para ajudar com as contas do Nubank, também era necessário aprender o React Native.
• Sem mencionar que a arquitetura de cada uma dessas opções era muito diferente! Nossa hipótese é que, ao reduzir a barreira de entrada para o desenvolvimento móvel, o Nubank terá mais engenheiros contribuindo com a base de código.
• Outro gargalo que encontramos quando dependíamos de desenvolvedores especializados de plataformas nativas para cada novo lançamento de recurso ou produto era o “pesadelo da contratação“. Apesar dos nossos esforços adicionais para recrutar, nunca havia desenvolvedores suficientes para completar os quadros das nossas equipes de produtos.

Logo percebemos que as nossas equipes eram mais importantes do que a pilha de tecnologia, e que ter todas essas opções estava causando desconforto e confusão. Era o momento de investigar seriamente qual das tecnologias multiplataforma seria a melhor opção para as necessidades do Nubank.

Por isso, decidimos montar uma força-tarefa encarregada de investigar e determinar, com a participação de toda a engenharia de software, qual tecnologia deveríamos eleger como padrão, considerando como alternativas Kotlin Native, React Native e Flutter. 

A meta era fazer uma escolha que permitisse às equipes, independentemente da especialização de seus integrantes, atuar com autonomia e produtividade para desenvolver o aplicativo móvel e entregar valor usando apenas uma arquitetura, uma linguagem de programação e um conjunto de convenções.

A força-tarefa

Montamos uma pequena equipe com desenvolvedores móveis experientes no Nubank. Eles determinaram 11 critérios para serem avaliados em um projeto de pesquisa. Aqui está uma breve descrição das perguntas das 5 maiores prioridades:

1. Experiência do desenvolvedor: O que permite que um desenvolvedor entregue valor e seja produtivo? Exemplos: recarga automática, visibilidade de componentes, ferramentas de depuração, integração de IDE e ferramentas de testes.

2. Viabilidade em longo prazo: Demonstra o nível de confiança no futuro da plataforma. O mantenedor vai continuar fornecendo suporte de longo prazo (cinco anos)? Qual é a chance da comunidade apoiar o projeto se o mantenedor decidir abandoná-lo? 

3. Sem especialização de plataforma: Um engenheiro deve ser capaz de criar código móvel para o produto sem diferenciar entre Android e iOS. O código tem o mesmo visual e comportamento no Android e no iOS, com uma baixa ocorrência de problemas específicos de SO? 

4. Custo de abstração incremental: O custo de estender a plataforma para cada tarefa de produto e o atrito da centralização do trabalho nas extensões, se necessário. O quanto será difícil adicionar um novo componente? Nós estaríamos criando uma dependência em uma equipe de plataforma horizontal? 

5. Risco de abstração não linear: O risco de precisar reprogramar repentinamente partes extensas e desproporcionais da nossa abstração interna. Nós precisaríamos fazer alterações não triviais no código-base inteiro para suportar um novo componente do NuDS (Nubank Design System)? 

Então, decidimos reunir provas e combinar uma pontuação subjetiva para cada uma delas, usando técnicas diferentes, como:

• testar uma versão no Flutter de um de nossos recursos na produção
• analisar comunidades, repositórios e recursos disponíveis para cada plataforma
• conversar com especialistas, equipes e empresas responsáveis pelo desenvolvimento das plataformas
• implementar um clone de um dos nossos recursos como um app autônomo nas três plataformas diferentes
• realizar um teste interno de usabilidade, em que engenheiros novatos e experientes fizeram alterações no recurso nos aplicativos descritos acima
• realizar apresentações, debates e visitas da equipe para discutir nossas descobertas, ouvir as opiniões dos engenheiros e consultores sênior, incorporar o feedback deles e responder às suas perguntas

Os resultados dos testes de usabilidade foram os mais interessantes. Pessoas de todos os níveis e históricos (incluindo engenheiros de nível de entrada, sem experiência anterior no desenvolvimento para dispositivos móveis) fizeram um teste de uma hora. Eles receberam um aplicativo funcional, um ambiente de desenvolvimento, a documentação da plataforma híbrida e de seus componentes, e algumas tarefas cada vez mais complexas para programar. Eles foram observados pela nossa equipe enquanto realizavam as tarefas, e ambos responderam a um questionário no final.

Por exemplo, os engenheiros precisavam adicionar um recurso para que os usuários pudessem tocar em botões de “atalho” com valores pré-determinados para depositar dinheiro em suas contas-poupança:

O aplicativo clonado trabalhando pelo fluxo de criação do código de barra do boleto, iniciando com um campo de entrada para o valor que o cliente deseja depositar em sua conta.

O resultado de um desafio de programação para os testes de usabilidade dos desenvolvedores: 

Nós criamos um relatório para a nossa pesquisa, reunindo as descobertas e detalhando como cada critério foi avaliado. No fim deste artigo, há um link para solicitar o relatório completo. Foi difícil tomar uma decisão, até mesmo após coletar muitas informações, e tivemos que focar nos sete critérios mais importantes para chegarmos aos seguintes resultados:

A partir da nossa própria experiência (80% da nossa base de código Android é feita com Kotlin, e a conta do Nubank é desenvolvida em React Native) e avaliando as alternativas em relação às prioridades do Nubank, achamos que Kotlin é uma ótima linguagem para trabalhar. Mas o Kotlin Native é a única plataforma que não fornece uma abstração de interface de usuário, tornando-o dependente das ferramentas nativas da plataforma para desenvolvimento e testes. Embora ele tenha obtido uma classificação mais alta nos nossos critérios de menor prioridade, sem mostrar limitações de recursos ou riscos de restrição de armazenamento de aplicativos, nós achamos que, especialmente em relação ao suporte de testes para engenheiros especializados, o Kotlin Native não está pronto para nós.

Nós temíamos um viés para o React Native, então reduzimos propositalmente a prioridade de outro critério: o custo de criar a abstração inicial da plataforma, em que o React Native foi claramente o vencedor. 

Ao examinar critérios mais importantes, o React Native também venceu em suporte da comunidade. 

Não tivemos medo sobre a continuidade e a evolução do projeto, e ficamos muito felizes com a quantidade da documentação e dos treinamentos Um gráfico de radar, mostrando a pontuação de 0 a 5 para cada critério, em cada uma das plataformas. disponíveis. Porém, em relação a mudanças disruptivas, descobrimos que o React Native tem mais dependências do que as outras alternativas. Por isso, é muito mais vulnerável às dificuldades de manutenção e upgrade.

Nossa cultura de engenharia incentiva muito a automação de testes, então o Flutter brilhou graças às suas excelentes capacidades de testes que combinavam com a nossa mentalidade (infraestrutura integrada de testes para testes de Unidade, Integração e ponta a ponta sem a necessidade de renderizar na tela). Em contraste, o React Native exige dependências de terceiros, o que o torna mais propenso a mudanças disruptivas. Nós achamos que a experiência de desenvolvimento no Flutter era superior, com recursos melhores de recarga automática, documentação oficial robusta e uma API mais estável.

Depois de muita discussão até o último minuto, decidimos usar o Flutter como tecnologia principal do Nubank para desenvolvimento móvel. Isso significa que vamos criar novos recursos no Flutter, e conforme o produto evolui, esperamos que ele se torne um percentual maior da nossa base de código.

Estamos muito empolgados por compartilhar esse estudo no mesmo dia em que anunciamos o lançamento de um recurso muito esperado: o recurso de “transferência de pontos” do programa de recompensas foi criado com o Flutter.

Conclusão: como é usar o Flutter?

Até agora, tem sido ótimo usar o Flutter, e esperamos entregar em breve aos nossos clientes mais recursos que foram criados ou migrados para o Flutter.

Ter que incluir o Flutter em um aplicativo funcional que já conta com milhões de clientes traz seus próprios desafios, que estamos superando gradualmente. O primeiro deles:

• mudanças nos pipelines de versão,
• criar os canais da plataforma principal,
• integrar o roteamento entre React Native, Flutter, Kotlin e Swift para que possamos manter a interoperabilidade.

Embora o Flutter vá se tornar a nossa tecnologia principal, ainda precisamos dos desenvolvedores nativos e os valorizamos, porque cada plataforma tem seu próprio conjunto de recursos que requerem código nativo (por exemplo, plugins nativos como GPS e câmera, Apple Watch, aplicativos minimizados do Android etc.). Além disso, conforme a equipe de engenharia de software do Nubank cresce, a especialização individual é bem-vinda.

Para qualquer um que esteja considerando o Flutter, nós disponibilizamos nosso relatório completo, com dados detalhados, prós e contras, para download. Lembre-se, o que funciona para o Nubank pode não funcionar para você. 

Também recomendamos pesquisar sobre a experiência de outras empresas. Embora haja empresas usando o Flutter ou React Native, o Dropbox abandonou sua tecnologia multiplataforma (C++) por causa do “custo (não tão) oculto de compartilhar código entre iOS e Android“, e o AirBnB decidiu “Desativar o React Native“.

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