Escrevendo o novo iFood para Parceiros — Parte 1: Flutter 2.0
Olá! Meu nome é Gildásio. Sou engenheiro de software da equipe de iFood para Parceiros, e estou aqui para falar sobre nossa jornada de três partes na reescrita, refatoração e redesign do app. O objetivo é deixar o app num estado onde todos se sintam confortáveis para adicionar novas funcionalidades enquanto gerenciamos as já existentes, sejam eles novos na equipe ou não.
Prólogo
Quando eu cheguei no iFood, em maio de 2021, a equipe estava numa situação difícil depois de perder um integrante — e tínhamos algumas entregas para fazer num curto espaço de tempo. Sabíamos que, em breve, teríamos ajuda externa por alguns meses, mas o app, como estava naquele momento, não estava amigável o suficiente para que uma nova equipe entrasse assim. Decidimos por uma nova arquitetura baseada no bloc para a UI, e arrumamos (mais ou menos) nossa arquitetura atual para o resto. Ainda assim, tínhamos um problema maior pela frente: estávamos usando o Flutter 1.22.6.
A situação era a seguinte: sprint atual/lançamentos para terminar, nova equipe e novas funcionalidades chegando, arquitetura ainda não organizada, plugins antigos e uma versão antiga do Flutter. Não podíamos esperar, considerando que a próxima atualização do Flutter (que anunciou o 2.2) estava pra sair, e isso significaria ainda mais trabalho se ainda não estivéssemos no 2.0.
Ao mesmo tempo, este foi o melhor momento para fazer a migração, considerando que estávamos numa pausa enquanto as próximas funcionalidades ficavam prontas para a etapa de desenvolvimento. Ou seja, o prazo para isso era de duas semanas.
Ficou decidido o seguinte:
- Separar um branch do desenvolvimento chamado develop_2.0 e iniciar a migração por lá, módulo a módulo;
- Continuar desenvolvendo as funcionalidades do sprint atual separadamente, para convertê-los depois, pois precisávamos ainda terminar uma versão;
- Escrever e detalhar uma nova arquitetura para a nova equipe, para já saberem o que precisávamos para o novo módulo, já usando o Flutter 2.0 desde o início.
Um deles definitivamente não deu certo. Imagina qual?
A migração
Tínhamos apenas duas semanas para migrar um aplicativo com 22 módulos antes que a próxima funcionalidade chegasse e, para facilitar as coisas, pensamos: “migrar cada módulo separadamente vai dar bom, né?”.
Não.
Um pouco do contexto: o aplicativo iFood para Parceiros começou há dois anos, com uma equipe que estava aprendendo Flutter enquanto construía o app. Isso nos deixou com padrões e uma arquitetura que tornaria nosso trabalho de migração um pouco difícil — um desses, justamente, relacionado a como os módulos estavam interligados. Não podemos migrar o módulo 1, por exemplo, porque ele depende do 3, 4 e 7. E esses, por sua vez, dependem de outros.
Portanto, a abordagem por módulos não estava funcionando. O que poderíamos fazer depois de garantir que os módulos sem dependências fossem migrados com segurança? Executar dart migrate em cada módulo de uma só vez, certo?
Calma, não fizemos isso — mas quase.
Primeiro, precisávamos ter certeza de que estávamos seguindo as etapas corretas. Felizmente, todos os pacotes que estávamos usando naquela época já tinham uma versão null-safety disponível no canal stable ou no beta.
Em seguida, mapeamos os módulos com menos dependências e começamos por eles, gradualmente para, aos poucos, tornar mais fácil também pegar os módulos maiores.
Aí, sim, executamos dart migrate! Foi o que tornou tudo muito mais fácil e seguro, (considerando que tínhamos apenas duas semanas). A ferramenta teve suas deficiências, mas definitivamente foi o que tornou a façanha possível em tão pouco tempo.
Discutimos um pouco se migraríamos para o 2.0 com o null-safety desativado ou não, e cada artigo e recomendação deixava apenas uma escolha: é melhor fazer isso agora, antes que seja obrigatório e que sobre ainda mais trabalho pra depois. Valeu a pena? Com certeza!
Vindo de Kotlin, senti falta do null-safety nos três anos em que trabalhei com o Flutter. Nos ajuda a nos tornar menos propensos a erros, e deixa os novos plugins e pacotes mais seguros, com recursos como a late initialization (que ainda não temos a versão async que o Kotlin permite). Você pode dar uma olhada na explicação oficial aqui.
Lições aprendidas
- Ter uma ferramenta tão boa como o dart migrate ajuda na tarefa “perigosa” de migrar um projeto grande uma vez com poucas ressalvas. A gente realmente parabeniza o trabalho das equipes de Dart and Flutter nesse sentido;
- É possível fazer muita coisa em duas semanas! Organizamos a equipe de uma maneira que a gente não só conseguiu fazer a migração, mas ainda tivemos tempo de preparar o terreno para que novas pessoas trabalhassem no código assim que migrássemos;
- O próprio Flutter ajudou nisso também. Tínhamos muitos widgets que temíamos que parassem de funcionar após a migração, devido à complexidade — mas tudo funcionou bem. Só tivemos problemas com campos anuláveis imprevistos, provenientes de APIs que foram mapeadas incorretamente pela ferramenta;
- A partir de agora, vamos tomar muito mais cuidado com todos os novos módulos que escrevermos. Principalmente, sobre o problema de dependência, que era algo de anos atrás e, finalmente, tivemos a chance de pelo menos evitar que nos atrapalhe ainda mais no futuro.
Esperamos que você tenha gostado desta primeira parte da nossa jornada, e fique atento para a próxima! Falaremos sobre a nova arquitetura que definimos para os módulos: dados, domínio e UI.
Dê uma olhada nas vagas disponíveis no iFood! Aprenda sobre o processo seletivo e junte-se à equipe!
Texto original disponível em Writing the new iFood for Partners — Part 1: Flutter 2.0