De script Python para uma plataforma robusta
Como fizemos isso no BEES
Por Pedro Cordeiro, Software Architect no BEES
Originalmente, havia um script que permitia a qualquer usuário, independentemente de sua experiência técnica, fazer as alterações que desejasse. Posteriormente, o script teve que ser substituído por um produto mais robusto. Neste artigo, fornecerei uma visão geral passo a passo do processo de transição.
Sobre o que é o roteiro/produto?
Simplificando, é uma solução para facilitar a criação de dados de teste. No BEES, priorizamos a qualidade do software acima de tudo. Nosso compromisso com a excelência é evidente em nosso uso extensivo de testes de regressão automatizados, que são executados todos os dias em nossos ambientes de desenvolvimento.
No entanto, os testes manuais e automatizados requerem dados precisos e confiáveis para funcionar corretamente. À medida que nossa plataforma continua a se expandir com novas regras de negócios, parceiros e países — cada um com seus contratos e comportamentos exclusivos — a complexidade de nossa arquitetura de microsserviço aumenta, tornando cada vez mais difícil gerar os dados necessários para fins de teste.
Por que torná-lo um produto?
Software ruim não pode evoluir. Em seu estado atual, o software que encontramos parecia irrecuperável. Uma ferramenta complexa e em constante evolução não pode simplesmente existir como um script.
O que é necessário é um código limpo e bem estruturado para lidar adequadamente com 2 ambientes, mais de 15 zonas com muitos parceiros e mais de 50 contratos que o software deveria lidar. Cada zona e parceiro tinha seu próprio conjunto de regras, o que resultou em um código que cresceu organicamente, mas bem bagunçado.
Observabilidade
O script estava sendo executado nas máquinas pessoais sem qualquer login ou rastreabilidade, tornando difícil determinar quem eram os usuários e quais dados eles estavam criando.
Depurar e fornecer suporte era uma tarefa assustadora e, sem métricas adequadas, era impossível avaliar os custos da equipe. Portanto, era necessário tentar encerrar o script o mais rápido possível e buscar uma abordagem mais organizada e estruturada para o desenvolvimento de software.
Primeiras considerações
Conheça suas personas e casos de uso
A ferramenta python tinha uma infinidade de menus e submenus. Inicialmente, precisávamos desenhar um mapa de calor para entender melhor a atividade do usuário. No entanto, como o script era executado na máquina do usuário, essa não era uma tarefa fácil. O que você deve procurar:
- Converse com os usuários. Entenda suas necessidades.
- Quais são as partes mais sensíveis do sistema? Onde o suporte precisa se concentrar mais?
Evolução X Suporte X Manutenção
Por fim, iniciamos um novo servidor back-end e uma nova plataforma front-end, tudo do zero. Mas não podemos simplesmente deixar de lado o script legado, ele teria que continuar funcionando e recebendo manutenção.
Então, como podemos equilibrar os esforços da equipe para continuar evoluindo a nova ferramenta e, ao mesmo tempo, fornecer uma resposta rápida e eficiente às demandas dos usuários na ferramenta antiga?
A ideia era evitar a duplicação de código e, portanto, duplicar a manutenção e o suporte. Em vez disso, optamos por mover o código para o servidor e evoluí-lo durante o processo de desenvolvimento.
A abordagem passo a passo para a depreciação do script
Fase 0) O ponto de partida
O código que encontramos no script era complicado e era difícil decifrar qualquer lógica de negócios coerente dentro dele. Ele fazia chamadas de descanso para vários serviços na plataforma e executava lógicas de negócios complexas em linhas de código mal escritas.
Fase 1) Configurar um servidor
O primeiro passo foi criar um novo back-end. O back-end está em Node, então o código python não pode ser copiado e colado (e nós realmente nunca tivemos essa intenção). Teve que ser reinterpretado e construído do zero. Nos estágios iniciais, tínhamos apenas o back-bone das operações, como a solução de autenticação de token.
Depois que o servidor foi configurado, pudemos migrar certas partes das regras de negócios e interações do usuário para ele. E é aí que o mapa de calor improvisado é importante, porque pudemos identificar as áreas mais críticas do script e novas regras de negócios que eram bons candidatos para serem priorizados e movidos para o servidor.
Fase 2) Configurar um aplicativo
Depois de configurar o servidor, o próximo passo foi disponibilizar as primeiras features no aplicativo front-end. Infelizmente, apesar de nossos melhores esforços, a adoção do usuário foi lenta nos estágios iniciais do projeto. Consequentemente, tivemos que desenvolver e refinar a maioria das primeiras experiências do usuário sem feedback direto dos usuários.
Apesar desse desafio, estávamos comprometidos em criar uma experiência consistente nos clientes de front-end e script. Assim, garantimos que ambos os clientes (script e app) tivessem acesso às mesmas APIs, pois mantivemos as duas experiências simultaneamente.
Fase 3) Migrar as regras de negócio para o novo servidor
No processo de encerramento do script python, tivemos que mover a lógica para o servidor. Então, escolheríamos uma funcionalidade importante, investigaríamos e entenderíamos o recurso no script legado e depois o traduziríamos em APIs, Casos de uso, Serviços, Entidades, Adaptadores e tantas outras estruturas que um código limpo requer.
Neste momento, o script python estava se tornando apenas uma interface que chama o servidor e não implementa quase nenhuma regra de negócio. No processo, muitas chamadas que o script realizava diretamente para os microsserviços foram removidas por meio desse processo de migração.
Fase 4) Atrair os usuários
Encontramos uma solução única que poderia resolver dois problemas urgentes. Como o desenvolvimento de novos recursos para os clientes de front-end e script era um processo caro e demorado, e como precisávamos atrair mais usuários para o novo aplicativo, decidimos não implementar mais novas features no script.
Após cerca de quatro meses trabalhando no projeto, finalmente recebemos o feedback de nossos primeiros usuários. Embora possa parecer muito tempo desenvolvendo no escuro, durante esse período pudemos nos concentrar em refinar o serviço de back-end, o que melhorou significativamente a funcionalidade geral do sistema e facilitou muito o processo de suporte.
Fase 5) Desativar o script
Após um longo período de desenvolvimento, finalmente concluímos a migração de todas as funcionalidades de script legado para a nova plataforma. Como resultado, ficamos confiantes de que poderíamos interromper totalmente o suporte ao script legado.
Embora o repositório para o script ainda exista, ele quase não funciona, pois a plataforma continuou a evoluir além de suas capacidades. Vale a pena refletir sobre o percurso que nos conduziu até aqui. O processo de migração do legado e desenvolvimento da nova plataforma foi desafiador, mas ao mesmo tempo gratificante.
À medida que avançamos, somos gratos pelas lições que aprendemos e pelos sucessos que alcançamos ao longo desta jornada. Embora o script legado já esteja no passado, seu legado vive na forma da plataforma que criamos, que continuará a evoluir e melhorar nos próximos anos.
Minha parte nisso tudo
Meu papel neste projeto, desde o início, foi projetar a solução técnica como Arquiteto de Software. Trabalhando em estreita colaboração com minha equipe, propusemos ideias e as dividimos em etapas gerenciáveis e entregáveis.
O processo de depreciação levou mais de um ano para ser concluído e, como estou mudando de função na empresa, este é meu último mês na equipe. O timing não poderia ser mais perfeito, fico feliz por poder fazer parte de todo o processo.
E aqui está um agradecimento especial à minha incrível equipe do Data Generator (também conhecida como DataMass) ❤ Foi uma jornada incrível trabalhar com vocês.
