Olá pessoal, meu nome é Gevorg. Sou o chefe de dispositivos móveis da Profi.ru. Quero compartilhar com você a história de nosso experimento com o React Native. Vou contar como avaliamos os prós e os contras do desenvolvimento do React Native - na teoria e na prática. O artigo será útil para quem estiver interessado no desenvolvimento de dispositivos móveis entre plataformas, mas ainda não decidiu se deve seguir esse caminho ou não.
Aceleração máxima
Tudo começou com o fato de termos decidido acelerar o desenvolvimento em 10 vezes no nível da empresa. Estabelecemos uma meta impossível de ir além do horizonte habitual de eventos e experimentar coisas novas. Todas as equipes de desenvolvimento do Profi.ru fizeram os experimentos. Naquela época, a empresa tinha 13 desenvolvedores móveis nativos, incluindo eu e dois líderes de equipe. Minha equipe trabalhou em dois aplicativos móveis. No primeiro, os clientes procuram especialistas, no segundo, especialistas. Para mim, esse período foi incompreensível e emocionalmente estressante. De acordo com meus sentimentos, fizemos tanto que tudo funcionou rapidamente.
Usamos uma arquitetura comum em todo o projeto e monitoramos a pureza do código. Geradores usados que criam todos os arquivos do módulo. Eles tentaram tirar toda a lógica de negócios no back-end. Montamos CI / CD e aplicativos cobertos com testes E2E. Por tudo isso, alguns aplicativos foram lançados de forma estável uma vez por semana. Eu não tinha ideia de como acelerar o desenvolvimento duas vezes. De longe, às 10. Portanto, determinamos o que é importante para nós.
- Base de código unificada. Eu queria que todos os nossos desenvolvedores móveis escrevessem o mesmo código. Em um idioma, sem diferenças de plataforma entre iOS e Android. Para acelerar o desenvolvimento pela metade.
- Fácil de aprender nova ferramenta. Para que, ao expandir a equipe, não tenhamos problemas de reciclagem ou contratação.
- Liberações rápidas. Para que possamos liberar não uma vez por semana, mas todos os dias.
- Atualizações instantâneas. Para que todos os usuários recebam atualizações imediatamente. Como agora está acontecendo no desenvolvimento web.
Após uma breve revisão, três candidatos apareceram: React Native, Flutter, Kotlin / Native. Nem o Flutter nem o Kotlin Native podem ser liberados rapidamente. E consideramos isso talvez o mais importante. Além disso, essas tecnologias eram completamente cruas na época. Decidimos usar o React Native - ele pode ser lançado instantaneamente. Além disso, a maioria dos nossos desenvolvedores já usou o React.
Em geral, eu era negativo sobre as ferramentas de plataforma cruzada - como a maioria dos desenvolvedores móveis nativos. Vá a qualquer conferência móvel e fale sobre isso - você será imediatamente chapado. Eu mesmo amo isso :-) Portanto, para confirmar ou refutar os medos, realizamos nossa investigação.
Prós, riscos e problemas
Estudamos exemplos de uso do React Native em diferentes empresas - bem-sucedidas e não tão boas. Com o chefe de desenvolvimento, Borey Egorov leu com mais de três dúzias de artigos e outros materiais. Alguns discutiram cada parágrafo. No final do artigo - links para os mais interessantes. Observamos os pontos que podem nos acelerar, possíveis riscos e perguntas. Depois disso, conversamos com desenvolvedores de três empresas. Em cada um dos caras, eles criaram um produto em massa e trabalharam com o React Native por pelo menos um ano.
Com os profissionais, tudo ficou bem óbvio.
- Base de código geral.
- Over-the-Air, ou atualização por via aérea, ignorando a loja.
- A partir dos dois primeiros pontos, segue-se que a velocidade de entrega de recursos aos usuários aumentará.
- Os desenvolvedores da Web poderão escrever código para aplicativos móveis. Se um desenvolvedor da Web conhece o React bem, ele pode aprender rapidamente o React Native. E se o desenvolvedor móvel já conhece essa plataforma, pode entrar no desenvolvimento da Web com relativa rapidez.
A lista de riscos era mais longa :-)
O primeiro risco . Em vez de uma plataforma, a longo prazo, somos forçados a oferecer suporte a três: Android, iOS e React Native.
Às vezes, a tela do desenvolvedor se parece com isso:
Realidade Um de nossos interlocutores injetou o React Native no código existente. Sim, uma terceira plataforma completa aparece, mas você não sai do desenvolvimento nativo. Sua equipe teve que sincronizar o estado entre o React Native e o código nativo. Isso exigiu muita alternância entre diferentes partes de código / paradigmas e IDEs diferentes. Portanto, eles decidiram escrever um novo projeto a partir do zero, criar uma estrutura no React Native e já inserir peças nativas onde forem necessárias. Ficou melhor.
O segundo risco. React Native Black Box - às vezes, há situações em que um desenvolvedor não entende por que um bug apareceu. Você deve procurar em qualquer lugar: no código React Native, na parte nativa do produto ou na própria plataforma React Native.
Realidade Os caras com quem conversamos envolveram o aplicativo com logs e várias ferramentas: Crashlytics, Kibana e assim por diante. Os problemas permanecem, mas fica claro onde eles surgem.
O terceiro risco. Em artigos, foi encontrado frequentemente que o React Native é adequado para projetos pequenos, mas não para produtos grandes com funcionalidade de plataforma.
Realidade Examinamos se existem grandes empresas no mercado que trabalham com o React Native. Acabou - existem dezenas, senão centenas. Incluindo Skype, Tesla, Walmart, Uber Eats e Cozinha na área.
Quarto risco. Cada vez que você atualiza seu sistema operacional da Apple ou do Google, o projeto pode ser interrompido.
Realidade Decidimos que o risco era perfeitamente aceitável. O mesmo risco existe para o desenvolvimento nativo. Quando o novo sistema operacional para iOS e Android é lançado, você adapta seu aplicativo a ele.
O quinto risco. Não há suporte ao sistema de 64 bits no Android, e o problema está aberto desde 2015. E desde agosto de 2019, o Google Play não aceita compilações que suportam apenas sistemas de 32 bits.
Realidade Analisamos o problema em que a equipe do React Native trabalhou no verão de 2018. Eles prometeram adicionar suporte no próximo lançamento, embora ainda não tenham totalmente corrigido o suporte para o sistema de 64 bits. Isso ficou muito chateado. O suporte foi adicionado mais tarde, mas alguns dispositivos Android caem após a transição. Como descobrimos mais tarde, o percentual é escasso, mas ainda assim foi o ponto mais doloroso para mim.
Sexto risco. A probabilidade de que amanhã, a Apple ou o Google libere uma nova versão do sistema operacional e quebre o React Native. Ou uma nova tecnologia que Profi.ru, em princípio, não será capaz de suportar.
Realidade Não há garantias para nós ou para muitas outras empresas. Você percebe o risco e o corre, ou tenta outra coisa. Decidimos fazer e resolver todos os problemas assim que estiverem disponíveis.
Sétimo risco. Não foi possível dizer com antecedência a rapidez com que o React Native será comparado ao aplicativo nativo e qual desempenho ele mostrará.
Realidade A citação literal de um de nossos interlocutores é "listas de elementos de altura variável quando a rolagem diminui a velocidade". Decidimos verificar na prática. Um pouco mais à frente - no momento em que escrevemos o primeiro protótipo do aplicativo, não vimos esse problema, mas quando desenvolvemos um aplicativo completo, havia muitas perguntas sobre o desempenho do React Native.
Oitavo risco. Não está claro com que rapidez podemos encontrar desenvolvedores do React Native. No HeadHunter, encontrei cerca de 300 currículos, apesar de haver mais de 150 mil desenvolvedores para iOS.
Realidade Eles não se aprofundaram aqui, pois haviam contratado desenvolvedores do React mais de uma vez e sabiam o que procurar. Decidimos que, como último recurso, podemos treinar novamente os desenvolvedores do React no React Native.
Havia também o risco de alguém deixar a equipe, pois os desenvolvedores de dispositivos móveis não gostam dessa tecnologia. A propósito, eu estava certa. Alguém saiu :-(
Estou cansado de escrever React Native, então o que se segue é apenas RN :-)
O que mudamos e o que não
Discutimos os resultados da investigação com os fundadores da empresa, Sergey Kuznetsov e Yegor Rudi, e obtivemos o aval do experimento.
Decidimos criar um novo produto a partir do zero, e não inseri-lo em um já existente. E também - não toque em nosso aplicativo cliente. Era bastante maduro e, economicamente, não fazia sentido mudar radicalmente alguma coisa. Além disso, era importante para nós que o aplicativo cliente tivesse sua própria experiência nativa para iOS e Android.
Mas queríamos mudar radicalmente o pedido de especialistas. Ao contrário do cliente, não tivemos vergonha de os especialistas terem a mesma experiência de interação para aplicativos iOS e Android. Além disso, acreditamos que em um produto para especialistas podemos ficar sem animação e efeitos visuais. Mas antes que toda a equipe mudasse para uma nova tecnologia, era necessário sentir como ela funciona.
Experiência em ação
Em dezembro de 2018, reunimos uma equipe de três pessoas. Dois desenvolvedores do React e um nativo - eu. Entendo como o Android funciona e sou versado no desenvolvimento do iOS.
Como parte do experimento, queríamos verificar os seguintes pontos:
- como os lançamentos instantâneos funcionam no RN;
- como é a interação entre os componentes nativos e o RN;
- podemos usar nossos componentes nativos;
- como o RN trabalha com câmera, push e diplink;
- como a navegação e a economia de estado funcionam no RN;
- tanto quanto podemos fazer com o pixel RN perfeito;
- como o teste automático funciona no RN;
- a rapidez com que o desenvolvedor nativo ou React pode aprender a tecnologia.
Obtivemos os primeiros resultados em um mês e meio após mergulharmos no desenvolvimento.
- Comecei a escrever código no RN depois de apenas duas semanas. Para mim, a tecnologia era completamente descomplicada. Um de nossos desenvolvedores do React me ajudou muito - ele falou sobre o React / Redux e o JS em geral. Era necessário entrar nos meandros do React / Redux, mas depois de um tempo o "neurônio começou a aprender", como diz nossa empresa :-)
- Fiquei agradavelmente surpreso que, de alguma forma, o JS + Flow forneça uma digitação forte. Para JS, eu tinha expectativas muito mais baixas. Ao mesmo tempo, eu definitivamente daria preferência a Swift e Kotlin: para mim, elas são muitas vezes mais bonitas e agradáveis que JS, mas aqui as principais palavras são “para mim”.
- Nos ajudou a equipe incluir desenvolvedores que podem escrever código para iOS, Android e React. Cada plataforma tem seus próprios problemas específicos. Para resolvê-los, a equipe deve ser multifuncional.
- Liberações instantâneas funcionam. Para mim é como mágica. Não é necessário aguardar lançamentos e atualizações da Apple. Procurado - tirado e liberado.
- Muitas vezes o projeto fracassou. Isso realmente não é legal. Você pegou as alterações do ramo, tentou executar - e não importa. Foi muito chato. Em algum momento, acabamos de escrever um script que limpa o projeto completamente. Isso não quer dizer que eles resolveram o problema como um todo, mas acabaram com a maior parte.
- Ainda assim, temos que trabalhar com três plataformas, apesar de escrevermos principalmente código no RN. Todos os desenvolvedores tinham três IDEs: Xcode, Android Studio, WebStorm.
- Pushas, deeplinks, câmera, início da navegação. Mas eles começam com a ajuda de bibliotecas de terceiros ou as bibliotecas no código nativo devem ser gravadas por você mesmo e, em seguida, conectadas ao RN.
No final do artigo, quero voltar ao título. Então o RN é uma bala de prata para todos os problemas? Decidimos por nós mesmos que não. Ao mesmo tempo, eles conseguiram o que queriam. Aumentamos várias vezes a velocidade de entrega de recursos e agora podemos liberá-lo para todos os usuários todos os dias. Também é importante que equipes multifuncionais tenham aparecido na empresa, onde cada desenvolvedor escreve código no Android / iOS e na web.
E sim, os aplicativos na loja :-)
Artigos úteis sobre React Native
- Por que a discórdia continua com o React Native - Fanghao (Robin) Chen
- Como eu amei e odiei reagir nativo - Andrey Melikhov
- Reagir nativo do ponto de vista de um desenvolvedor móvel - Andrey Konstantinov
- Reagir nativo no Instagram - Instagram Engineering
- React Native: Uma retrospectiva da equipe de engenharia móvel da Udacity - Nate Ebel
- React Native: batalhas de fatos de um ato - Samat Galimov
- Pôr do sol reagir nativo - Gabriel Peal