Qualquer desenvolvedor que se preze volta e meia é obrigado a retornar àquele sistema antigo, arcaico tecnologicamente, que está escanteado e há muito tempo não recebe um tratamento mais cuidadoso. Somos reticentes, fazemos cara feia, olhamos desconfiados, mas muitas vezes não tem jeito: é uma parte importante do nosso ofício manter o espólio tecnológico da empresa que trabalhamos funcionando continuamente.
Pode parecer estranho, mas é perfeitamente natural agirmos com certa reserva, uma vez que queremos sempre estar em contato com as últimas versões das ferramentas e tecnologias que utilizamos diariamente. Mas, mais do que isso, precisamos desse sentimento de inovação como um gatilho motivacional e desafiador, sem contar que é essencial manter-se reciclado nesse mercado tão dinâmico da tecnologia da informação, onde mudanças ocorrem num piscar de olhos.
Mas então, como podemos tratar nossos códigos legados para que qualquer manutenção, seja fazer uma correção ou adicionar uma nova funcionalidade, corra o mais tranquila possível e, principalmente, nos direcione sempre para aquela sensação estimulante de desafio diário?
Depois de garantir que estamos trabalhando sobre a mesma versão da aplicação que está rodando em produção (espero que todos tenham uma gerência de configuração confiável para lhe dizer isso), a primeira coisa é identificar o ponto exato onde será realizada a alteração, seja um serviço, classe, método ou mesmo um comando com problema. Antes mesmo de colocar efetivamente a mão na massa, o importante é isolar o trecho de código onde serão feitas as modificações. Caso seja um bug, qualquer artifício que ajude a descobrir as causas do problema será de grande valia: arquivos de logs, exceptions, debug, testes de performance. Se for necessário, atualize o banco de dados de desenvolvimento com uma cópia do de produção, para ter certeza que estamos trabalhando em um ambiente o mais fiel possível ao que o cliente está utilizando.
Agora temos que certificar que as modificações que serão inseridas não impactarão o que existe no sistema. Inúmeras vezes já acompanhei desenvolvedores que, no intuito de corrigir alguma anormalidade, não têm o cuidado devido e acabam inserindo muitos outros problemas. Então, antes de qualquer alteração, temos que testar todas as possibilidades conhecidas, pensar em cenários e listar entradas e saídas possíveis, a fim de garantir que o trecho identificado na etapa anterior esteja funcionando conforme o esperado. Só quando tivermos certeza que tudo está devidamente protegido por testes e funcionando podemos seguir adiante nas alterações.
Normalmente essa é uma das partes mais custosas de um projeto, uma vez que o trabalho entregue não será visível para o cliente final. Mas ao mesmo tempo garantirá que futuros reparos sejam mais rápidos e transparentes. Se for necessário estipular prazos, leve sempre em consideração o tempo que será gasto desenvolvendo os testes.
Nesse momento que colocaremos em prática todo nosso conhecimento para realizar a tarefa. Mas não devemos nos limitar a somente uma alteração pontual para corrigir um bug, mas analisar principalmente o que posso melhorar nessa parte do sistema para que ele seja um pouco menos antiquado que antes. Torná-lo mais estruturado e organizado, aplicar algum padrão de projeto, utilizar alguma biblioteca existente para fazer um serviço específico, criar componentes que possam ser reutilizados em outros lugares, documentar e simplificar trechos muito complexos, atualizar versões de frameworks e bibliotecas. Note que, assim que é finalizado, um sistema já nasce com algum legado e, se formos negligentes e não o atualizarmos com alguma frequência, em pouco tempo ele estará morto tecnologicamente.
Nunca se esqueça de rodar seguidamente os testes criados anteriormente, para atestarmos que as mudanças não impactaram o que estava funcionando. Provavelmente será necessário adaptá-los para contemplar as novas funcionalidades, mas, no fim, código e testes estarão atualizados e, ao menos, esse trecho estará seguro.
Dentro desse processo ainda podem ser incluídos diversos outros passos que nos ajudem em futuras manutenções no sistema, como, por exemplo, adicionar o sistema à integração contínua para verificações automáticas da qualidade e cobertura do código, que nos dê feedback constante sobre o que está sendo feito, mas acredito que com essas etapas já é possível mantermos inicialmente nosso legado.
Antes de passar adiante um código, pense em como gostaria de recebê-lo. Além de ser uma boa prática, você estará facilitando a vida do seu sucessor. Apenas resta-nos fazer um serviço bem feito para que, nas vezes posteriores, esse trabalho não seja um fardo tão grande assim. O próximo profissional pode ser você.
[Crédito da Imagem: Código Legado – ShutterStock]
Formado em Ciência da Computação em 2003 pela PUCRS, trabalha com tecnologia de informação há mais de 10 anos, especialmente utilizando tecnologias Microsoft. Líder técnico, desenvolvedor e analista de sistemas. Entusiasta de metodologias ágeis, Scrum e XP, e praticante de boas práticas de programação.
You must be logged in to post a comment.
