Back home

Ao modernizar sistemas antigos, o Copilot primeiro classifica as evidências

Primeiro, corrija a linha de base, a superfície de modificação e os limites de teste antes que o modelo esteja qualificado para ajudar.

Ao modernizar o sistema antigo, o Copilot primeiro organiza as evidências

A primeira vez que coloquei um projeto Java da era 1.5 em uma máquina moderna, a primeira coisa que apareceu não foi o problema do código, mas o problema das evidências. Se a construção pode ser reproduzida, se a saída do teste é a mesma, se o ponto de falha vem da JVM, da imagem ou do código-fonte, essas coisas determinam como proceder antes de “iniciar a refatoração”. O maior medo ao modernizar sistemas antigos não é que as mudanças sejam lentas, mas que seja impossível dizer o que aconteceu depois das mudanças.

Corrija a cena primeiro, então as ações subsequentes serão significativas. A coisa mais valiosa nessa etapa não é a conclusão no IDE, mas uma caixa que pode ser executada repetidamente: o antigo JDK, as antigas ferramentas de construção, as antigas entradas e os antigos comandos de teste estão todos bloqueados no Docker. Comandos como os seguintes não são bonitos, mas funcionam:

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

Este comando tem apenas uma função: consertar o “fracasso de hoje” em evidências reproduzíveis. Sem ele, todo sucesso subsequente poderia ser apenas o resultado de circunstâncias que por acaso foram perdoadoras. O papel do Copiloto aqui também é muito claro. Não é para substituir o julgamento, mas para ajudar a resolver rastros: erros repetidos em logs longos, caminhos que ecoam entre si em scripts de construção e várias entradas recorrentes em testes antigos podem ser usados ​​primeiro para uma triagem aproximada. O que é analisado não é uma conclusão, mas um mapa para começar.

Quando chega a hora de realmente entrar na faca, a área de mudança deve ser muito estreita. A maneira mais fácil de derrubar projetos antigos é alterar o nome do pacote, construir, entrar e testar tudo de uma vez. No final, você nem consegue dizer qual etapa quebrou o sistema. Uma abordagem mais estável é aproveitar primeiro a menor lacuna: por exemplo, cobrir a entrada antiga com uma camada de adaptadores, primeiro permitir que a nova cadeia de ferramentas fique fora do velho mundo e veja a estrutura claramente e, em seguida, mova-se lentamente para dentro. O Copilot é muito adequado para lidar com esse tipo de trabalho mecânico: preencher importações, mover configurações, extrair fragmentos repetidos e gerar esqueletos de teste temporários. Deixe o modelo fazer essas coisas e a eficiência será realmente alta; mas ainda cabe às pessoas decidir se essa costura deve ser cortada e qual comportamento deve ser preservado após o corte.

Também é fácil ser enganado pelas aparências quando se trata de testes. Passar no velho teste não significa que a modernização seja segura, significa apenas que certos comportamentos históricos ainda não foram eliminados. Os testes de muitos projetos antigos são mais parecidos com instantâneos comportamentais do que com especificações semânticas de negócios. Verde é apenas verde e não pode ser interpretado diretamente como “compreensão do sistema”. Uma das ações mais importantes durante a transformação é adicionar limites de teste novos e mais estreitos a cada pequena incisão, de modo que o teste mude gradualmente de “legado histórico” para “restrições atuais”. O Copilot pode ajudar a quebrar afirmações antigas, completar modelos e implementar shells de teste duplicados. Porém, qual semântica deve ser mantida no teste e o modelo não pode tomar decisões para o sistema.

Na modernização arqueológica, a divisão de trabalho mais fiável é, na verdade, muito simples: o ambiente e os troncos são responsáveis ​​por fixar os factos, o Copiloto é responsável por mover tijolos e traduzir, e as pessoas são responsáveis ​​por decidir qual a história que deve ser mantida e qual a história que deve ser eliminada. Uma vez organizado um modelo para explicar o passado do sistema, muitas vezes ele torna as suposições mais convincentes do que as evidências; colocando-o de volta na posição de gerenciamento de evidências e organização mecânica, torna-se mais um assistente verdadeiramente útil.