Delphi Vivo

Capítulo 1 - Legado não significa software ruim

A reunião começou por causa de uma venda que a Horizonte Sistemas ainda não conseguia fechar. Um cliente antigo queria consultar pedidos e disponibilidade de estoque fora da rede local. Não pedia uma nova tela do ERP nem a substituição do desktop. Precisava integrar seu portal comercial ao sistema que já usava havia anos.

A primeira sugestão pareceu simples: criar uma API. Em poucos minutos, porém, a conversa deixou de ser sobre integração e passou a ser sobre tudo o que poderia dar errado.

O ERP Horizonte ainda era compilado em Delphi XE7. A versão em produção era Win32. Parte do acesso a dados dependia de uma camada criada antes de o FireDAC se tornar o padrão da equipe. Havia componentes visuais e fiscais comprados muitos anos antes, alguns sem atualização disponível. Um pacote de relatórios continha alterações locais que ninguém conseguia mais separar do código original. A regra de disponibilidade de estoque aparecia em uma query, em um método do Form de pedidos e em uma rotina usada pelo faturamento.

Alguém lembrou a última tentativa de migração. O projeto havia sido aberto em uma versão mais nova do Delphi, vários packages deixaram de compilar e os primeiros ajustes produziram uma sequência de erros em units que a equipe raramente tocava. Depois de dois dias, o trabalho foi interrompido. A conclusão informal ficou conhecida por todos: atualizar o Delphi era arriscado demais.

Outro participante propôs começar um sistema novo. Seria a oportunidade de abandonar o desktop, rever o banco e adotar uma arquitetura moderna. A ideia despertou entusiasmo até surgirem perguntas menos confortáveis. Quem conhecia todas as regras de preço? Como reproduzir as exceções fiscais? Quanto tempo seria necessário para alcançar o comportamento que os clientes já utilizavam? O que aconteceria com as novas demandas enquanto a equipe reconstruísse o produto? Como comparar o sistema novo com o antigo se nem o antigo tinha testes suficientes?

Esse é o ponto de partida de Delphi Vivo. Não uma disputa entre tecnologia antiga e tecnologia nova, mas uma situação comum em produtos que duraram tempo suficiente para se tornar importantes. O sistema continua funcionando, recebendo mudanças e sustentando o negócio. Ao mesmo tempo, a equipe perdeu parte da confiança necessária para fazê-lo evoluir.

É fácil olhar para esse cenário e concluir que o problema é o Delphi XE7, o Win32, o Form grande ou o componente descontinuado. Todos podem representar riscos reais, mas nenhum explica sozinho por que a empresa parou de avançar. O problema mais profundo é a distância entre o valor que o sistema preserva e a capacidade que a equipe possui de mudá-lo sem medo.

Antes de falar em refatoração, testes, FireDAC, APIs ou CI/CD, precisamos ajustar a maneira de enxergar o legado. Se tratarmos todo código antigo como lixo, tentaremos removê-lo antes de compreender o que ele protege. Se romantizarmos sua longevidade, aceitaremos riscos que já deveriam ter sido enfrentados. Modernizar exige sustentar duas ideias ao mesmo tempo: o sistema contém valor comprovado e pode ter se tornado perigoso de mudar.

A palavra legado costuma carregar um julgamento antes mesmo de começar a análise. Em algumas conversas, significa código velho. Em outras, tecnologia fora de moda, sistema sem documentação, aplicação monolítica ou produto que ninguém gostaria de manter. Essas descrições podem aparecer juntas, mas não são equivalentes.

Neste livro, chamaremos de legado o sistema existente que acumula comportamento, dependências e decisões relevantes para uma organização, mas cuja evolução é limitada por riscos que ela já não consegue avaliar ou controlar com facilidade. A idade pode contribuir para isso, porém não é o critério principal. Um projeto criado há dois anos pode se tornar difícil de mudar. Um sistema com quinze anos pode continuar bem estruturado, testado e evolutivo.

Michael Feathers propôs uma definição deliberadamente operacional: código legado é código sem testes. A formulação é útil porque desloca a atenção da idade para o feedback. Sem testes, uma alteração pode parecer correta e ainda quebrar um comportamento distante. Para o contexto deste livro, porém, precisamos ampliar a lente. Testes são parte central da segurança, mas um sistema corporativo também pode ficar preso por builds irreproduzíveis, componentes sem suporte, banco desconhecido, integrações frágeis, decisões não registradas e processos de implantação