Trabalhar com legado sem odiar a vida.

Legado tem uma definição informal que eu gosto: código que funciona, que ninguém quer tocar, e que paga o salário de todo mundo.

Essa terceira parte costuma ser esquecida quando o time reclama. O sistema feio no ar sustenta a empresa. O sistema bonito que ainda não existe não sustenta nada.

Isso não quer dizer aguentar calado. Quer dizer entrar com estratégia em vez de com desprezo.

O erro de entrada

O padrão que se repete: a pessoa nova chega, olha o código, conclui que quem escreveu era incompetente, e propõe reescrever.

Duas coisas quase sempre são verdade.

Quem escreveu tinha restrição que você não conhece. Prazo, informação incompleta, biblioteca que era o padrão na época, uma decisão de negócio que mudou depois. Código estranho costuma ser cicatriz, não burrice.

E aquele if esquisito no meio da função existe porque um cliente específico quebrou em produção numa terça-feira. Remover é fácil. Descobrir por que ele existia é o trabalho.

A pergunta útil não é “por que fizeram assim?”. É “o que eu não estou vendo?”.

O primeiro mês

Não mude nada estrutural. Faça três coisas.

Aprenda pelo fluxo de dinheiro. Não leia o código de cima pra baixo. Escolha a operação mais importante do negócio e siga ela do começo ao fim: da requisição ao banco, à fila, ao e-mail. Isso ensina mais em dois dias que um mês de leitura aleatória.

Escreva o que você não entende. Uma lista. Ela vira o seu roteiro de perguntas e, depois, a documentação que faltava. Documentação escrita por quem acabou de entender é sempre melhor que a escrita por quem já sabia.

Conserte coisa pequena. Bug irritante, aviso no log, script manual que dá pra automatizar. Isso te dá contexto e, mais importante, te dá crédito. Ninguém aceita proposta grande de quem ainda não entregou nada.

Teste antes de mexer

A regra que evita a maioria dos desastres: nunca refatore código sem teste. Escreva o teste primeiro, mesmo que seja feio.

Legado costuma ser difícil de testar por construção: dependência instanciada dentro da função, chamada de rede no meio do domínio, estado global. Existe uma técnica pra isso, chamada de teste de caracterização: você não testa o que o código deveria fazer, testa o que ele faz hoje.

it("mantém o comportamento atual do cálculo de frete", () => {
  const result = calcularFrete(pedidoRealDeProducao);
  expect(result).toEqual({ valor: 2347, prazo: 5, transportadora: "X" });
});

Esse teste é feio e não valida regra nenhuma. Ele congela o comportamento, o que é exatamente o que você precisa antes de mexer. Se o número mudar depois da refatoração, você tem uma conversa: mudou porque estava errado, ou mudou porque você quebrou?

Pegue casos reais de produção pra montar esses testes. Eles cobrem os cantos que ninguém imaginaria.

Refatore no caminho

Reescrita grande quase nunca termina. Ela compete com entrega de valor, perde, e vira um branch de seis meses que ninguém consegue mesclar.

O que funciona é melhorar o que você já ia tocar. Precisou mexer numa função pra corrigir um bug? Deixe ela um pouco melhor. Extraia um nome, adicione um teste, tire uma duplicação.

Em um ano, as partes que mais mudam ficam boas, e as que ninguém toca continuam feias e estáveis, que é exatamente onde a feiura custa menos.

Quando reescrever de verdade

Existem casos legítimos, e todos têm um formato: o custo de manter é maior que o custo de substituir, com números.

O que não conta como razão: “está feio”, “é uma tecnologia antiga”, “ninguém gosta de mexer”.

O que conta: nenhuma pessoa da empresa consegue mudar aquilo com segurança, a plataforma perdeu suporte de segurança, ou uma mudança de negócio necessária é inviável no desenho atual.

E mesmo aí, o caminho é estrangular, não substituir de uma vez. Coloca-se uma camada na frente, e as funcionalidades migram uma por uma pro novo. O sistema antigo encolhe até poder ser desligado. É lento e é o único método que eu vi funcionar consistentemente.

A parte que não é técnica

Trabalhar com legado testa paciência mais que habilidade.

Vale separar duas coisas: o código é ruim, e as pessoas que escreveram não são. Time que fala mal do legado em voz alta costuma ter alguém na sala que escreveu aquilo, e isso destrói a disposição de contar por que as decisões foram tomadas, que é a informação mais valiosa disponível.

E vale medir o próprio progresso por outra régua. Em produto novo, o resultado é visível: telas, funcionalidades, lançamento. Em legado, o resultado é o incidente que não aconteceu e a mudança que levou dois dias em vez de duas semanas. É menos gratificante e é o trabalho que sustenta a empresa.

O que ganha quem faz bem

Conhecimento de legado é a habilidade menos disputada e uma das mais valorizadas.

Todo mundo quer trabalhar no projeto novo. Quem entende o sistema que gera receita vira a pessoa que é consultada antes das decisões, e isso é uma posição bem melhor que a de quem escreveu o serviço mais moderno.

É a mesma lógica que descrevi em de júnior a pleno: o valor está em resolver o que dói, não no que é agradável de fazer.