Como trabalhar com código legado com David Reis

O que realmente define código legado

Código legado vai além de tecnologias antigas ou arquiteturas complexas. Sua essência está na falta de domínio pela equipe atual:

• Sistemas se tornam legados quando quem os mantém não os compreende profundamente, impedindo melhorias eficientes.
• Sintomas comuns incluem dificuldade para corrigir bugs, adicionar funcionalidades ou explicar o funcionamento interno.
• Tecnologias obsoletas ou más práticas são consequências, não causas primárias – o cerne é o desconhecimento.

Evitando a "legadização": Cultura > Documentação

Prevenir código legado exige estratégias de compartilhamento contínuo de conhecimento:

• Pair programming (15-20% do tempo): Engenheiros seniores e juniores resolvem problemas juntos, transferindo contexto decisivo.
• Code reviews eficazes: Mais que encontrar bugs, servem para disseminar padrões e racional por trás das escolhas.
• Documentação enxuta: Foque em "porquês" (ex.: "Usamos Postgres para X após comparar A/B") em vez de manuais extensos.
• Comentários inteligentes: Explique a intenção, não o óbvio (ex.: "Este índice otimiza consultas do painel Y").

Inovação vs. Modismo: Quando mudar de tecnologia

Adotar novidades por hype gera legado. A regra de ouro é:

• Resolva problemas concretos, não adicione complexidade desnecessária. Exemplo válido: Migrar para Rust se reduzir custos de ML em 70%.
• Faça protótipos descartáveis: Teste hipóteses em 2-3 dias antes de decisões. A premissa é "jogar fora após aprender".
• Evite soluções em busca de problemas: Reescrever tudo em Go porque "TypeScript é ruim" sem métricas claras é receita para fracasso.

Barreiras ao código de qualidade e como quebrá-las

Fatores que alimentam legado:

• Capacidade técnica limitada: Times medianos produzem código medianos – invista em treinamento e mentoria.
• Postura passiva: Profissionais devem defender boas práticas (ex.: testes) como médicos defendem protocolos, não como "ordens do chefe".
• Pressão por entrega: Negocie escopo, não qualidade. "Estamos atrasados" não justifica ignorar testes.

Reescrever ou não? Eis a questão!

Decisões de reescrita exigem rigor:

• Evite decisões precipitadas: Engenheiros recém-chegados tendem a sugerir reescritas por desconforto com o desconhecido.
• Estrangule progressivamente: Substitua módulos antigos por novos gradualmente, nunca tudo de uma vez (padrão strangler-fig).
• Valide com especialistas: Após 3-4 meses de imersão no código, um engenheiro sênior pode propor reescrita só se houver ganhos claros de custo/manutenção.

Sinais de alerta que seu sistema está virando legado

Identifique riscos cedo com:

• Métricas quantitativas: Aumento de regressões, tempo de implantação ou falhas.
• Pesquisas de satisfação: "Você se sente produtivo trabalhando nesse código?"
• Feedback de novos membros: Olhares frescos detectam complexidade desnecessária que veteranos normalizaram.

IA e LLMs: Aliados limitados

Ferramentas como Copilot ajudam, mas com ressalvas:

• Entendimento de contexto: Funcionam bem em códigos modulares e documentados, mas lutam em sistemas legados caóticos.
• Refatoração de larga escala: São ineficientes e propensas a erros em mudanças massivas (ex.: alterar 80 arquivos).
• Melhor uso: Automatizar tarefas repetitivas (ex.: atualizar 50 testes similares) ou gerar documentação básica.

Código legado não é inevitável

Sistemas tornam-se legados por falhas de gestão do conhecimento, não por fatalidade. Empresas que cultivam:

• Ownership compartilhado: Defina "donos primários/secundários" para cada módulo e atualize rotineiramente.
• Melhoria contínua: Código de 2 anos atrás será pior que o atual – e isso é normal. Refatore incrementalmente, não em "big bangs".
• Simplicidade como padrão: Só adicione complexidade onde há risco comprovado (desempenho, segurança).

A mentalidade anti-legado

Legado surge quando equipes perdem a conexão com seu código. Combata isso com:

• Transparência intelectual: Assuma quando não sabe algo e documente descobertas.
• Protagonismo técnico: Engenheiros devem advogar por boas práticas, não esperar permissão.
• Tolerância calculada: Problemas futuros podem ser resolvidos no futuro. Priorize o mínimo viável bem feito em vez do "perfeito incompleto".