# 13 antipadroes de desenvolvimento que geram tech debt

> Os 13 antipadrões de desenvolvimento que geram tech debt incluem código espaguete, copy-paste, dependências ocultas, ausência de testes, overengineering, e integrações frágeis. Cada prática oferece ganho imediato, mas compromete manutenibilidade, escalabilidade e estabilidade do sistema. Reconhecer esses padrões exige revisão contínua de arquitetura, automação de qualidade e disciplina técnica para evitar acúmulo de dívida técnica.

*Blog Sem Juízo · Destaques · 03 de agosto de 2026 · Babi Cordeiro*

Antipadroes de desenvolvimento sao praticas que parecem resolver um problema hoje, mas cobram caro amanha. Veja os 13 mais comuns que geram tech debt e como reconhece-los antes que virem bola de neve.

Antipadroes de desenvolvimento sao solucoes recorrentes que parecem eficientes no curto prazo, mas geram tech debt: complexidade alta, manutencao cara e bugs frequentes. Os 13 mais comuns incluem God Object, Copy and Paste, Spaghetti Code e Golden Hammer, entre outros. Identificar esses padroes cedo e o primeiro passo para evitar que a divida tecnica saia do controle.

## 1. God Object

Uma classe central que concentra responsabilidades demais. Ela cresce sem limite e vira um ponto unico de falha. Criterio: se a classe tem mais de 500 linhas e toca em 3 ou mais modulos distintos, ela ja e um God Object. Refatorar exige dividir por responsabilidade.

## 2. Copy and Paste

Repetir codigo em vez de abstrair. Cada copia cria um ponto de divergencia: corrige em um lugar, esquece do outro. Criterio: se o mesmo bloco aparece 3 vezes, extraia para uma funcao. O custo de manutencao cresce proporcional ao numero de copias.

## 3. Spaghetti Code

Controle de fluxo emaranhado, com gotos, condicoes aninhadas e estados implicitos. Dificil de testar e de seguir. Criterio: se voce precisa de rastreamento manual para entender o fluxo, e spaghetti. Refatore com funcoes puras e early returns.

## 4. Golden Hammer

Usar a mesma tecnologia ou padrao para tudo. Um banco relacional para dados de cache, uma fila para tarefas sincronas. Criterio: se a solucao exige workaround para caber no padrao, e golden hammer. Avalie ferramentas alternativas por adequacao.

## 5. Lava Flow

Codigo morto que ninguem remove por medo de quebrar algo. Ele se acumula e confunde. Criterio: se um trecho nao e executado em producao ha 6 meses, remova ou isole. Versionamento existe justamente para isso.

## 6. Shotgun Surgery

Uma mudanca simples exige alteracoes em varios arquivos. Criterio: se para adicionar um campo voce edita 5 classes, ha dispersao. Centralize a logica em um unico ponto de entrada.

## 7. Feature Envy

Uma classe usa metodos de outra mais do que os proprios. Criterio: se o metodo chama 3+ getters de outra classe, mova a logica para la. Isso reduz acoplamento e aumenta coesao.

## 8. Premature Optimization

Otimizar antes de medir. Complexidade desnecessaria para ganhos teoricos. Criterio: se nao ha metricas de performance que justifiquem, implemente o simples. Otimize apenas apos profiling.

## 9. Magic Numbers

Valores numericos sem nome nem contexto. Criterio: se um numero aparece mais de uma vez sem constante, vire uma constante nomeada. Isso torna o codigo legivel e evita erros de digitação.

## 10. Reinventing the Wheel

Reescrever funcionalidades que ja existem em bibliotecas ou frameworks. Criterio: se a biblioteca e madura e bem testada, use-a. Codigo proprio so vale quando a lib nao atende a necessidade especifica.

## 11. Hardcoding

Valores fixos no codigo que deveriam ser configuraveis. Criterio: se o valor muda por ambiente, vire variavel de ambiente ou configuracao. Isso evita deploy para cada ajuste.

## 12. Improper Exception Handling

Engolir excecoes ou lancar excecoes genéricas. Criterio: se o catch vazio ou com log apenas, ha problema. Trate com contexto e propague quando necessario.

## 13. Dependency Hell

Dependencias em versoes conflitantes ou desatualizadas. Criterio: se o build quebra por conflito de versao, use um gerenciador de dependencias e atualize regularmente. Isso reduz surpresas em producao.

## Como priorizar a correcao

Nao tente refatorar tudo de uma vez. Comece pelos antipadroes que impactam a entrega: God Object e Spaghetti Code sao os mais caros. Use o custo de manutencao como criterio, nao a estetica do codigo.

## FAQ

### O que e um antipadrao em desenvolvimento?

Um antipadrao e uma solucao comum que parece eficiente, mas gera problemas a longo prazo, como tech debt. Ele surge de pressa, falta de design ou desconhecimento. Reconhece-los e o primeiro passo para evita-los.

### Qual a diferenca entre antipadrao e tech debt?

Antipadrao e a pratica, tech debt e a consequencia. O antipadrao gera divida tecnica, que e o custo futuro de manter e corrigir o codigo. Nem toda tech debt vem de antipadrao, mas a maioria dos antipadroes gera tech debt.

### Como identificar antipadroes no codigo?

Use code review, analise estatica e metricas como complexidade ciclomatica. Tambem observe sinais: classes grandes, codigo duplicado, acoplamento alto. Ferramentas como SonarQube ajudam a detectar automaticamente.

### Antipadroes sao sempre ruins?

Nao necessariamente. Em prototipos ou com prazo curto, alguns antipadroes sao aceitaveis desde que documentados. O problema e quando viram padrao permanente sem revisao. A divida tecnica consciente e diferente da ignorada.

### Qual antipadrao mais gera tech debt?

God Object e Spaghetti Code sao os mais caros, pois afetam a legibilidade, testabilidade e a velocidade de entrega. Eles crescem exponencialmente com o tempo. Priorize refatoracoes nesses pontos.

### Como evitar antipadroes em um time novo?

Estabeleca padroes de codigo, faça code review obrigatorio e invista em testes automatizados. Eduque o time sobre antipadroes com exemplos reais do proprio projeto. A cultura de design previne a divida tecnica.

---

Fonte (canonical): https://blogsemjuizo.com.br/destaques/13-antipadroes-de-desenvolvimento-que-geram-tech-debt/