Como lidar com code legado fraco 2 na prática
A maior parte dos sistemas que herdei não era ruim por falta de documentação ou porque o código estava feio. Era ruim porque as decisões de arquitetura foram tomadas em contextos completamente diferentes dos atuais e ninguém atualizou os fundamentos quando o negócio cresceu. Isso é o que eu chamo de code legado fraco 2 — não é o conceito antigo de sistema obsoleto, mas sim um código que funciona, mas falha sob pressão real de escala ou manutenção.
O que é code legado fraco 2
Não é um termo técnico oficial. Surgiu de forma orgânica entre desenvolvedores que lidam com sistemas que parecem funcionais até o momento em que algo crítico acontece. A diferença entre legado comum e code legado fraco 2 é sutil mas importante. Legado comum você sabe que precisa migrar. Code legado fraco 2 é aquele que você consegue dar manutenção no dia a dia, mas qualquer mudança estrutural expõe fragilidades que nunca foram testadas. No meu caso, encontrei isso num sistema de pagamentos que usava triggers de banco para cálculos de juros compostos. Funcionava perfeitamente com 500 transações por dia. Quando o volume chegou a 12 mil, os triggers começaram a causar deadlocks em cascata porque cada operação abria uma transação separada sem lock escalation. O sistema não falhava de forma explosiva. Ele simplesmente ficava lento até o ponto de timeout. Levei três semanas só para entender o padrão de deadlocks porque as logs não mostravam nada claro.
A solução foi extrair a lógica de juros para um serviço separado com processamento assíncrono, usando filas e batches. Não foi rápido. O downtime ficou em torno de 40 minutos durante a migração. Mas depois disso o sistema passou a lidar com 80 mil transações sem problemas. O código legado original continuou lá, funcionando, apenas recebendo menos tráfego.
Pegadinhas que ninguém conta
A primeira armadilha é achar que refatoração incremental resolve. Na prática, refatorar code legado fraco 2 de forma incremental muitas vezes piora a situação. Cada pequena mudança introduz uma nova dependência que se choca com as antigas. Eu já vi times gastarem meses refatorando partes isoladas e no final ter um sistema mais confuso do que antes. O que funciona é o approach de estrangulamento, também conhecido como strangler fig pattern. Você constrói uma nova camada ao redor do sistema existente, redirecionando gradualmente as chamadas para a nova implementação. O código velho vai sendo desligado pela borda até sobrar nada. Isso leva tempo, mas é a única forma que eu vi funcionar consistentemente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que as pessoas ignoram é a questão das dependências ocultas. Em code legado fraco 2, raramente um problema é isolado. Se você tem um módulo com falhas de consistência, olhe ao redor. Vá encontrar pelo menos mais dois módulos que dependem dele de forma indireta. Eu perdi duas semanas rastreando um bug de consistência de dados que na verdade vinha de uma stored procedure que ninguém mais lembrava que existia.
Quando não tentar consertar
Nem todo code legado fraco 2 precisa ser resolvido. Se o sistema opera em carga baixa, com poucas integrações e ninguém da equipe entende o suficiente para arriscar mudanças, às vezes a melhor decisão é manter rodando e isolar. Criar uma camada de abstração à frente, tratar o legado como um black box e desenvolver tudo novo por cima. Isso reduz o risco de quebrar algo que já funciona. O problema é que essa abordagem exige disciplina. É fácil deixar o isolamento virar negligência. O legado continua crescendo de forma não controlada e no final você termina com dois sistemas problema em vez de um. Defina um prazo máximo. Se em 12 meses o sistema isolado ainda não teve nenhuma mudança significativa, aí sim considere uma migração planejada.
Também é importante saber quando o código simplesmente não vale o investimento. Alguns sistemas têm custo de manutenção tão alto que o retorno sobre qualquer esforço de modernização é negativo. Nesses casos, o caminho mais sensato é substituir por uma solução moderna do zero, mesmo que isso signifique perder alguma funcionalidade existente. Nada disso é fácil. Mas é a realidade de quem trabalha com sistemas legados há algum tempo.
Recursos práticos para começar
Se você precisa baixar ou acessar material sobre code legado fraco 2, procure por frameworks de análise estática como SonarQube configurados com regras personalizadas para detecção de código com alta complexidade ciclomática. Isso ajuda a identificar os pontos críticos sem depender de leitura manual. Também recomendo Ferramentas de profiling de banco de dados como o Slow Query Log do MySQL ou o SQL Server Profiler, que mostram onde o legado está realmente custando performance. Para documentação, não confie no que está nos repositórios. A versão mais confiável é o código rodando em produção e as métricas de comportamento. Logs, tempos de resposta, taxas de erro e padrões de uso são muito mais honestos do que qualquer README. Anote tudo. Você vai precisar dessas informações quando for tomar decisões difíceis sobre o que manter, o que substituir e o que simplesmente deixar existir.
