E lá está o jovem programador, anunciando orgulhoso para a sua sogra que a partir de amanhã ele será “O responsável por todo o legado da sua empresa!“.

Em seguida, todos na mesa de jantar se levantam entusiasmados para abraçar e parabenizar o rapaz por essa grande conquista.

Exceto o cunhado, um programador das antigas que após um longo suspiro acende um cigarro e lança um olhar vazio para o horizonte.

 

Introdução

Apesar de um pouco dramática, esta cena talvez não aconteça nos dias de hoje. Uma vez que atualmente até os programadores  iniciantes já sabem que lidar com Softwares Legados não é uma atividade tão glamorosa quanto parece.

Um código não se torna legado apenas porque foi escrito há muito tempo e por utilizar tecnologias ultrapassadas. Ao passo que o QuickSort, por exemplo, foi publicado em 1962 e ainda continua sendo uma referência em Algoritmos de Ordenação.

Apenas o fato de possuir muitas dívidas técnicas e não fazer o uso de Testes Automatizados já candidata um código como legado.

E antes de mais nada: esta opinião não é minha e sim do Consultor Michael C. Feathers em seu famoso livro “Working Effectively with legacy code“.

Em 2012, eu me aventurei a elaborar um artigo de iniciação científica acerca desse livro, como atividade da minha não concluída Pós Graduação em Engenharia de Software.

Irei apresentar a partir de agora alguns fragmentos e insights adquiridos nesta empreitada.

 

Principais desafios ao lidar com código legado

Trabalhar com Sistemas legados não é apenas um desafio técnico. Também é um paradoxo gerencial,  uma vez que, pela lógica, um gestor não deve investir dinheiro para realizar alterações em um software que já está desatualizado.

Contudo há situações onde:

• O Software Legado eventualmente entrega informações básicas para outros sistemas mais modernos.
• O Software Legado é tão específico que torna inviável a sua substituição.
• O custo para realizar o  software Legado foi tão alto que a gestão não consegue defender a ideia de “jogá-lo fora“.

Ok, então vamos deixar os programadores da empresa realizando a manutenção desses sistemas, correto?

Talvez. Mas é provável que essa ação gere outros problemas:

• Cada modificação no sistemas envolve o risco de criar bugs.
• Pra evitar essa situação, as alterações nos softwares legados se tornam minuciosas e demoradas. O que deixa o departamento de desenvolvimento com a fama de não conseguir atender a velocidade que o negócio precisa.

Tudo bem. Mas o que devemos fazer então?

 

Estratégias para atacar o problema

Não existe uma Bala de Prata para matar esse lobisomem abstrato. Contudo  podemos adotar algumas estratégias. Irei citar algumas (livro do Michael possui mais ou menos 24 técnicas) que apesar de meio densas, são bem interessantes.

 

Encontrar os pontos de inflexão

Sabe aquelas vias da cidade que, quando ficam engarrafadas, paralisam a cidade inteira? Pois bem, eventualmente os Sistemas de Informação também possuem alguns componentes-chave que alteram de forma significativa o comportamento de outros.

Com a ajuda dos responsáveis pelo negócio, que entendem como as regras do sistema funcionam, é possível que os programadores identifiquem esses pontos.

 

“Fotografar” as Entradas e Saídas

Após identificar um  ponto de inflexão, os programadores podem isolá-lo com ferramentas específicas e capturar as suas entradas e saídas.

 

Criar os Stubs e Mocks

Após essa captura, os programadores criam uma outra aplicação, que automatiza o envio das entradas simuladas ao sistema e confere as suas  saídas.

Há várias estratégias para realizarmos este tipo de testes, que popularmente chamados de mocks e stubs.

Foge do escopo deste artigo explicar esta técnica mais a fundo. Caso seja do seu interesse  recomendo ler este artigo aqui ou se tiver mais empolgado consultar a clássica fonte primária sobre o assunto.

 

Realizar as alterações

Com uma camada de segurança formada pelos mocks e testes automatizados.  E com o entendimento dos pontos críticos do Sistema, obtidos em conjunto com os responsáveis pelo negócio, o Time de desenvolvimento finalmente pode realizar as alterações.

 

Conclusão

De forma bastante resumida, chegamos na conclusão de que cercar os Pontos de Inflexão de um sistema legado com “Testes de fumaça” e Mocks pode ser uma boa estratégia para conseguir mantê-lo e realizar atualizações no seu código de forma segura e com maior rapidez.

Entender como lidar com Softwares Legados é um tema um pouco denso e eu espero que você tenha tido uma boa experiência lendo até aqui.

Há exemplos práticos de código que caso você tenha interesse, podem ser apresentados numa próxima oportunidade.

Obrigado pela leitura e fique à vontade para continuarmos a conversa nos comentários.