7 antipadrões de código que todo dev deve evitar

Antipadrões de código são soluções recorrentes que parecem resolver um problema imediato, mas criam uma dívida técnica que trava o projeto no longo prazo. Código espaguete, god object, copy-paste programming, esses nomes podem soar familiares, e por um bom motivo: eles estão nos repositórios de quase todo dev que já trabalhou em equipe. Neste artigo, listo os 7 antipadrões mais comuns, com exemplos concretos e o que fazer no lugar.

1. Código espaguete

Código espaguete é aquele em que o fluxo de controle é tão emaranhado que qualquer alteração quebra algo em outro lugar. Você puxa um fio e o novelo inteiro se desfaz. É um dos antipadrões mais citados em concursos de engenharia de software, conforme o material da Estratégia Concursos. A causa típica? Falta de modularização: funções que misturam lógica de negócio, acesso a banco e renderização. Um exemplo real: uma função de 500 linhas que valida formulário, consulta o banco e monta HTML ao mesmo tempo.

O que fazer: quebre em funções pequenas e com responsabilidade única. Use separação por camadas (controller, service, repository).

2. God object

God object é a classe que sabe demais e faz demais. Ela centraliza regras de negócio, acesso a dados, validações e até lógica de apresentação. Num sistema de e-commerce, por exemplo, uma classe Pedido que também calcula frete, aplica cupom, envia e-mail e atualiza estoque. Qualquer mudança exige tocar nela, e o risco de quebrar algo cresce exponencialmente.

O que fazer: aplique o princípio da responsabilidade única (SRP). Cada classe deve ter um motivo claro para mudar. Separe serviços de e-mail, cálculo de frete e gestão de estoque em classes independentes.

3. Copy-paste programming

Repetir código em vez de reutilizá-lo é um antipadrão que envelhece mal. Você copia um bloco de validação de CPF para cinco classes diferentes. Depois descobre um bug na validação e precisa corrigir em cinco lugares. Um estudo informal do site CodeGym coloca o copy-paste entre os dez antipadrões mais frequentes. O custo não é só tempo de correção: é também a chance de esquecer um dos pontos e gerar inconsistência.

O que fazer: extraia o código repetido para uma função ou classe utilitária. Use herança, composição ou métodos auxiliares. Se o código é parecido mas não idêntico, considere parâmetros para generalizar.

4. Números mágicos

Números mágicos são valores literais espalhados pelo código sem explicação. if (saldo < 1000), o que significa 1000? Limite de saque? Mínimo para investimento? Daqui a seis meses, nem você vai lembrar. Esse antipadrão torna o código frágil: para ajustar o valor, é preciso caçar cada ocorrência.

O que fazer: declare constantes com nomes descritivos. const LIMITE_SAQUE_DIARIO = 1000 deixa a intenção clara e facilita manutenção.

5. Comentários que explicam o óbvio

Comentários do tipo // incrementa contador sobre contador++ poluem o código sem agregar valor. Pior: eles enganam. Quando o código muda e o comentário não, vira ruído. O livro "Clean Code" de Robert C. Martin defende que código bem escrito dispensa comentários explicativos. O comentário útil é o que explica o porquê de uma decisão atípica, não o como.

O que fazer: antes de comentar, pergunte-se: "dá para tornar o código mais claro?" Renomeie variáveis, extraia funções. Se ainda assim precisar comentar, explique a razão da escolha, não a implementação.

6. Classe preguiçosa

Classe preguiçosa é aquela que existe mas não faz o suficiente para justificar sua existência. Uma classe Cliente que só tem getters e setters para nome e email, sem nenhum comportamento. Ela adiciona complexidade acidental: mais uma entidade para navegar, mais um arquivo para abrir. O antipadrão oposto ao god object: enquanto um centraliza demais, o outro fragmenta sem necessidade.

O que fazer: avalie se a classe realmente agrega valor. Se ela só carrega dados, considere usar um dicionário, um registro (struct) ou fundi-la com outra classe que a use ativamente.

7. Tratamento genérico de exceções

Capturar Exception (ou Throwable) e engolir o erro é um dos antipadrões mais traiçoeiros. O código continua rodando, mas ninguém sabe que algo deu errado. Um sistema financeiro que captura exceção genérica e não loga pode mascarar uma falha crítica de cálculo de juros. O erro vira um bug silencioso que só aparece em auditoria.

O que fazer: capture exceções específicas (IOException, SQLException). Trate cada uma de forma adequada, logue, notifique, ou propague. Se precisar de um catch genérico, ao menos registre o stack trace.

FAQ, Perguntas frequentes sobre antipadrões de código

Qual a diferença entre padrão de projeto e antipadrão?

Padrão de projeto é uma solução comprovada e reutilizável para um problema recorrente. Antipadrão é uma solução que parece funcionar no curto prazo, mas gera problemas futuros. Enquanto um padrão como Singleton resolve acesso global controlado, um antipadrão como God Object centraliza demais e quebra a manutenibilidade.

Como identificar antipadrões no meu código?

Sinais comuns: funções muito longas (mais de 30 linhas), classes com muitos métodos públicos, código duplicado, nomes de variáveis vagos (dados, temp), e dificuldade em escrever testes automatizados. Ferramentas de análise estática como SonarQube e ESLint ajudam a detectar vários antipadrões automaticamente.

É possível corrigir todos os antipadrões de uma vez?

Não. Tentar refatorar tudo de uma vez é arriscado e costuma introduzir novos bugs. O melhor é priorizar: comece pelos antipadrões que mais atrapalham o time (código espaguete em funcionalidades críticas, god objects). Corrija um por vez, com testes automatizados cobrindo o comportamento.

Antipadrões são sempre ruins?

Em geral, sim, mas há exceções. Um código espaguete em um protótipo descartável pode ser aceitável. O problema é quando o protótipo vira produção sem refatoração. A regra prática: se o código vai viver mais de algumas semanas, vale o esforço de evitar ou corrigir antipadrões.

Qual a relação entre antipadrões e dívida técnica?

Antipadrões são uma das principais fontes de dívida técnica. Cada vez que você opta por uma solução rápida e bagunçada em vez de uma bem estruturada, acumula juros: mais tempo para implementar a próxima funcionalidade, mais bugs, mais retrabalho. A refatoração é o pagamento dessa dívida.

Vale a pena refatorar código legado cheio de antipadrões?

Depende do custo-benefício. Se o código legado é estável e raramente alterado, refatorar pode não compensar. Mas se a equipe precisa mexer nele com frequência, corrigir os antipadrões mais críticos reduz o tempo de desenvolvimento futuro e o risco de bugs. Comece mapeando os trechos mais tocados.

Para encerrar

Evitar antipadrões não é questão de perfeccionismo, é economia de tempo e dor de cabeça. Na prática, comece revisando os pontos que mais travam seu time: extraia funções longas, elimine classes que só carregam dados, substitua números mágicos por constantes. Não precisa refatorar tudo hoje, mas crie o hábito de deixar o código um pouco melhor a cada commit.