Sharing is caring!

Como sua aplicação deve ser arquitetada? Através de quais ferramentas e práticas a qualidade deve ser garantida? Os processos estão devidamente automatizados? Qual a cobertura de testes? Fazendo uma pesquisa rápida, não faltam ferramentas, receitas ou histórias de sucesso para cada um desses temas.

Porém, por baixo dos panos existem importantes fatores que geralmente não são mencionados: qual o esforço necessário para obtenção do resultado? Qual o nível de maturidade da aplicação? Como os débitos técnicos são geridos e priorizados, perante time to market, metas, tamanho da equipe? Implementar aquela melhoria seria viável e traria benefícios reais?

Levando isso em consideração, hoje trazemos o case de uma aplicação da vida real que ganhou escala, e passou por evoluções orgânicas e graduais de arquitetura, qualidade, processos e equipe. O foco não é no resultado, mas sim na trajetória.

A aplicação

O Portal do Parceiro, do iFood, é a aplicação usada pelos mais de 50 mil restaurantes para gerenciarem suas lojas e acompanharem resultados. Nascido da migração de um sistema legado, é mantido pela tribo de restaurantes e é composto por um front-end em React.js back-end com BFF e microsserviços em Java/Kotlin.

Começou a ser desenvolvido há dois anos, por uma equipe de 5 desenvolvedores (sendo 3 front-end e 2 back-end), com a missão de migrar e repensar as funcionalidades de um sistema legado; e atualmente é mantida por cerca de 12 equipes, totalizando 40 desenvolvedores front-end e 60 back-end.

Imagem 1
Portal do Parceiro

Linha do tempo

[02/2017] Kickoff

Foi a fase de planejamento e setup da aplicação, quando “isso tudo era mato”. A principal atividade, além de esboçar um roadmap, foi fazer um comparativo para escolher a stack básica, pensando em tamanho da comunidade, mercado, adequação aos requisitos e necessidades. Optamos por React.js, Redux, Webpack, Babel e SCSS.

[05/2017] Lançamento

Após três meses desenvolvendo as versões mínimas de algumas telas e fluxos, chegou a hora de dar vida à aplicação, lançando a primeira versão em produção.

Disponibilizada para poucos restaurantes de um grupo controlado, o ambiente de trabalho foi bem mais priorizado do que a qualidade da aplicação, e nesse estágio, um possível bug para o usuário seria bem menos crítico do que um problema de usabilidade ou de adequação a necessidades.

Ainda não era o momento de ter uma estrutura de pastas definitiva, nem de buscar cobertura de testes em versões iniciais altamente suscetíveis a mudanças; mas sim um bom momento para definir algumas camadas para ter uma forma de trabalho consistente, perfis de linters, formatadores, e um script/job primitivo de release/deploy.

“Se você está apenas começando um projeto, não gaste mais do que cinco minutos na escolha de uma estrutura de arquivos. Escolha qualquer uma das abordagens acima (ou crie as suas próprias) e comece a escrever o código! Você provavelmente vai querer repensá-lo de qualquer jeito depois de ter escrito algum código.”

React.js docs

[09/2017] Primeiro rollout

Depois de diversos ciclos de validação, adaptações e ajustes, a aplicação foi exposta a 2.000 restaurantes, sendo mantida ainda pelos mesmos 3 desenvolvedores front-end.

Com os fluxos mais estáveis e consolidados, e novos por vir, foi uma boa ocasião para gerar alguma documentação: Storybook para favorecer o reuso de componentes gráficos, SassDoc para mixins e variáveis de SCSS.

Além da documentação, ampliar a cobertura de testes, mesmo que de camadas específicas, rendeu bons frutos e garantiu que refatorações e futuros fluxos não quebrassem os antigos.

Imagem 2
Storybook

[11/2017] Segundo rollout

Neste rollout intermediário a aplicação foi liberada para 10.000 restaurantes, de naturezas diferentes e com necessidades distintas; e teve a adição de 2 desenvolvedores front-end.

O código cresceu bastante, as páginas ganharam complexidade, mas seguimos na mesma estratégia da etapa anterior, com adição do Sonarqube para análise estática e comparação da qualidade de código com as demais aplicações e ferramentas da empresa.

Imagem 3
Sonarqube

[02/2018] Rollout completo

Em seu último rollout, o grupo aumentou para 15.000 restaurantes, incluindo contas estratégicas com necessidades mais complexas, como relatórios e gráficos de performance. A equipe ganhou outros 2 desenvolvedores front-end, totalizando 7.

Nesse momento, já anunciando o desligamento do sistema legado, a aplicação recebia 100.000 pageviews por dia. Bugs já trariam consequências bem mais severas, e o código já era grande o suficiente para dificultar a análise de impacto de uma refatoração. Seguir a estratégia atual traria um acúmulo impagável de débito técnico e perda de confiabilidade dos usuários.

Foi quando adotamos o Cypress para garantia de funcionamento dos fluxos com teste integrado, porém com uma API mockada. Através dele também ganhamos o benefício de documentar os fluxos através de descrição textual e vídeos, ficando disponível para outras audiências e stakeholders do projeto.

Imagem 4
Cypress

[02/2019] Desligamento do sistema legado

Um ano depois, com todas as funcionalidades migradas, os 50.000 restaurantes dependeriam apenas do Portal do Parceiro para gerenciarem suas lojas, perdendo o acesso ao sistema legado. Devido a expansão do iFood – em complexidade da plataforma, funcionalidades, e equipe – a aplicação estava sendo mantida por cerca de 35 desenvolvedores front-end.

O aumento da equipe, já distribuída e remota, exigiu uma melhoria significativa nos processos, sendo incluídos um job de verificação dos pull-requests, um guia de CONTRIBUTING, um diagrama dos jobs e um conjunto de guias explicando os padrões do projeto, arquitetura, stack, design patterns recorrentes para novos membros e também para manter a qualidade do código.

Já com 765.000 pageviews por dia, e em uma rotina intensa de desenvolvimento, totalizando mais de 2.000 pull-requests, e com novas funcionalidades sendo implementadas em estágios iniciais, os testes não estavam sendo suficientes para garantir a estabilidade necessária para o momento.

Então adotamos uma ferramenta que poderia ter sido implementada em etapas anteriores, mas que sem os devidos recursos para gerir débito técnico não teria sido tão efetiva: monitoramento do ambiente de produção com TrackJS.

Imagem 5
Diagrama de jobs

Estágio atual e próximos passos

Com cerca de 65.000 restaurantes ativos, 800.000 pageviews diários, 40 desenvolvedores front-end; e mais de 100 páginas, 3.000 arquivos de código-fonte e 2.500 pull-requests, pode-se afirmar que a aplicação tornou-se um monolito, e dos grandes.

Apesar da alta coesão e estabilidade, os desafios são diversos: performance, releases demorados, dificuldade de rollback devido à alta frequência de entregas, superficialidade no code review por causa da variedade de domínios e contextos, entre outros. Para solucionar esses desafios, a aplicação está sendo organizada em módulos para uma quebra em micro front-ends.

Imagem 6
Stack atual de qualidade e processos

 

Posted by:Fernando Maia

Bachelor of Computer Science by University of São Paulo. Front end developer, passionate about new technologies, with experience in: - JavaScript, from small to large-scale applications, including main libraries and frameworks, design patterns, build automation, task running, packaging, static analysis, testing, style guide definitions, code linting and documentation; - CSS, from pure to framework oriented large-scale applications; - HTML5, XML and JSON - Template engines, based in Java (Freemarker, Velocity), PHP (Smarty, Twig) and JavaScript (Mustache, Jade, Handlebars).

Deixe seu comentário