Lidar com software legado hoje em dia é mais comum do que podemos imaginar. Costumo dizer que muitos softwares nascem legados. Como assim? Para mim, software que não tem teste automatizado é legado – não tem como garantir funcionamento de absolutamente nada dentro dele e muitos comportamentos (recursos ou bugs) só aparecerão com usuários usando constantemente.

Após alinhamento do que é software legado, é comum a empresa (principalmente as com cultura de startup) e desenvolvedores, ter que trocar peças do software em pleno voo. Não temos como pousar o avião para fazer manutenção e depois decolar novamente quando a empresa está com clientes usando o software em produção. Com isso, vem o trabalho do engenheiro de software junto com time para fazer planejamento de trocar peças (componentes, módulos pacotes, serviços, ou seja lá qual for o nome que você dá pra isso) do software com ele no ar.

Planejamento

No meu ponto de vista esse trabalho deve ser feito com muito planejamento e pés no chão. Só assim conseguimos pensar nos possíveis problemas que poderemos ter, mas tenha em mente que não terá como prever todos os possíveis problemas, mesmo passando meses e meses planejando. A única certeza que podemos ter, é: ao colocar no ar surgirá imprevistos. Bem-vindo a vida de desenvolvimento de software.

Esse é o momento de alinhamento do “problema” e possíveis soluções junto com o time envolvido. Tenha certeza de que todos os envolvidos entenderam o problema antes de dar o próximo passo e sair jogando soluções no ar e consequentemente escolher a melhor solução.

Se um dos membros não entendeu o problema, não devemos ignorar. Ele não enxergou como um possível problema ou o trabalho de expor o problema não foi claro para todos. Essa deve ser a hora de praticar a comunicação entre os membros do time. Geralmente não é um trabalho fácil – mantenha sempre a calma, seja objetivo e traga o time de volta ao tema quando começar sair. Para mim, não existe nível hierárquico para fazer isso. Todos devem estar com o mesmo propósito: resolver o “problema”.

Em software usamos um termo chamado baby steps (passos de bebê). Ou seja: dê o próximo passo após concluir o atual (um de cada vez).

Chegando a solução

Para qualquer “problema” existem diversas soluções, e isso não é diferente no mundo de software. Lidando com software legado (contexto deste artigo), temos de ter o equilíbrio do melhor software e da solução que resolve o que estamos buscando resolver. Desenvolvedores geralmente quer partir para melhorar software ao nível de software, mas precisamos pesar isso com outras métricas para ver qual é a melhor solução realmente:

• Tempo
• Esforço
• Conhecimento (do time – esse é extremamente importante)

Minha escolha sempre será por uma solução que o time consiga dar manutenção e mais de uma pessoa já usou a abordagem sugerida em produção – existe um abismo enorme entre teoria e produção (infelizmente).

Esse é o momento de exercitar o conhecimento do time para escolher qual caminho seguir:

• Microsserviço (REST, RPC. etc)
• Fila de processamento
• Serverless
• Serverless + API Gateway
• Módulo, pacote, biblioteca e/ou …
• …

Como tudo em minha vida, tento ter mais de uma opção caso a primeira não funcione. Trago essa abordagem para desenvolvimento de software também – mas já tive casos que todas as possíveis soluções não funcionaram e infelizmente foi momento de jogar a toalha e repensar no negócio. Via software estava impossível resolver.

Reescrevendo as peças

Dado que o time escolheu a melhor solução para o “problema”, é momento de colocar a teoria discutida em prática. Pode ser que a primeira solução não seja possível – estava implícito em algum ponto que não tinha visibilidade antes de começar. Infelizmente, em alguns casos (e não é por falta de experiência) isso acontece, principalmente quando estamos falando de software legado.

Gosto da analogia “cavar um buraco na areia”. Existem diversas ferramentas que podem “adivinhar” o que tem onde cavaremos, mas se realmente funcionasse 100% (algumas podem chegar muito próximo desse número), não precisaríamos de arquivologista ou outras profissões seguindo essa área de atuação.

Deploy: grande momento de ir para produção

Mesmo com tudo funcionando extremamente bem em ambiente de teste, homologação ou qualquer nome que você dê, a tendência de ter imprevistos quando colocarmos o software em produção é grande. Esteja preparado para ter que lidar com eles.

Algumas coisas que tento evitar (sempre que possível):

• Certifique-se se realmente tudo foi escritório teste e de fato testado por todos envolvidos nos outros ambientes;
• Deploy de sexta, ninguém do time está afim de perder o final de semana em família e/ou suas obrigações pessoais. Mas tem casos que não temos como esperar, planejamento é à alma desse ponto;
• Caso apareça problema evite ser o super-herói e se tranque ao seu mundo para resolver o problema e volte com a “bala de prata”;
• Caso apareça problema evite hacking no servidor de produção, tenha um plano de roll back (voltar para versão anterior) caso necessário;
• Na linha do roll back, mantenha os logs gerados no momento do crash. No calor do momento é sempre um problema lembra desse pequeno/grande detalhe;

Deixe nos comentários algumas recomendações para o pessoal que ler esse artigo depois de você.