Modernizar o código antigo requer primeiro a arqueologia

A coisa mais difícil sobre o código antigo nunca é a sintaxe antiga, mas os velhos tempos. Um projeto está repleto de build.xml, JDK antigo, estrutura de teste antiga e métodos de empacotamento antigos. Superficialmente, parecem várias pilhas de arquivos, mas na verdade são camadas de suposições históricas empilhadas umas sobre as outras. O código em si é apenas a camada mais externa. O que realmente bloqueia a entrega é muitas vezes se essas suposições ainda existem, se podem ser reproduzidas e se o antigo comportamento será perdido após as mudanças.

É por isso que a “arqueologia” precede a “transformação”. Observe primeiro o arquivo de construção, depois as dependências, depois o ambiente em execução e depois os testes. A ordem não pode ser revertida. O build.xml ainda está lá, mas o pom.xml não existe. Tais sinais são suficientes para indicar que o projeto vive na era das Formigas; se o código pode ser compilado, se os testes podem ser executados e se o produto pode ser reconstruído são as primeiras evidências. A parte mais útil do modelo aqui não é escrever imediatamente um novo código para o código antigo, mas identificar essas evidências em uma pilha de fragmentos.

O ambiente também deve ser fixado primeiro. O código antigo geralmente vem com JVMs antigas, contêineres antigos e suposições arquitetônicas antigas. Jogue-o diretamente nas máquinas atuais, especialmente em um ambiente de arquitetura cruzada, e será fácil misturar novos ruídos quando ocorrerem problemas: o código está inerentemente quebrado ou são a emulação, o espelhamento e as cadeias de ferramentas que estão causando problemas? Se você não conseguir nem mesmo “o mesmo código pode ser reproduzido de forma estável no mesmo ambiente” neste estágio, todas as ações de modernização subsequentes serão apenas suposições.

O valor da IA ​​nesta etapa é claro: ela pode ajudar na tradução em nível de personagem e em nível de estrutura. Converter Ant em Gradle, converter scripts de construção antigos em um formato agora sustentável, mover um monte de XML repetitivo e clichê para um local mais claro são coisas que são bons candidatos para deixar para os modelos. É rápido, disposto a tentar de novo e de novo e não muito trivial. Mas não é adequado para arbitragem. Quais avisos podem ser mantidos primeiro, quais testes estão realmente mentindo, quais módulos devem ser cortados primeiro e quais classes devem apenas ser empacotadas e adaptadas. No final, ainda precisa ser decidido pelas pessoas.

Testar é a maneira mais fácil de enganar as pessoas. Passar nos testes do projeto antigo não significa que o sistema seja compreendido, pode significar apenas que alguns comportamentos antigos estão apenas agrupados no ambiente atual. Essa sensação de “totalmente verde” é perigosa porque muitas vezes mascara um problema maior: o que o teste verifica são os detalhes de implementação de uma determinada época, e não a semântica de negócios que precisa ser preservada agora. Se você realmente deseja reformar, a primeira coisa a fazer é retirar esses testes do “senso decorativo de segurança” e reavaliar o que eles estão protegendo.

Portanto, a maneira mais estável para esse tipo de projeto geralmente não é reescrevê-lo de uma só vez, mas primeiro criar uma cápsula do tempo para corrigir o ambiente antigo, os comportamentos antigos e as dependências antigas e, em seguida, removê-lo pelas rachaduras mais estreitas. Primeiro, torne o sistema reproduzível, depois entregue o trabalho repetitivo à IA para tradução e, em seguida, retire os limites, camada por camada. Se a ordem estiver fora de ordem, o modelo irá acelerar o antigo projeto e empurrá-lo para um caos mais profundo; se a ordem estiver correta, o modelo será como um assistente arqueológico verdadeiramente útil, responsável por mover tijolos, limpar poeira e comparar evidências, libertando as pessoas do trabalho sujo e deixando o julgamento em suas mãos.