O que são anti-padrões?

Question

Accepted Answer

**Anti-padrões** são soluções comuns mas **pobres** para problemas recorrentes — abordagens que parecem razoáveis mas levam a resultados ruins (código difícil de manter, com bugs ou rígido). Reconhecê-los ajuda você a evitar erros comuns.

## O que são anti-padrões

```text
ANTI-PATTERNS = commonly-used but COUNTERPRODUCTIVE solutions:
  → they seem like a solution but cause MORE problems (technical debt, bugs, rigidity)
  → the OPPOSITE of design patterns (proven good solutions)
→ recognizing them helps you AVOID common pitfalls
```

## Anti-padrões comuns de código/design

```text
GOD OBJECT/CLASS → one class doing too much (huge, knows everything) → hard to maintain;
  violates single responsibility
SPAGHETTI CODE → tangled, unstructured code with no clear flow → hard to follow/change
COPY-PASTE programming → duplicated code (violates DRY) → bugs/changes must be fixed everywhere
MAGIC NUMBERS/STRINGS → unexplained literal values → unclear, error-prone
PREMATURE OPTIMIZATION → optimizing before it's needed → wasted effort, complexity
GOLDEN HAMMER → over-using one familiar tool/pattern for everything ("when you have a hammer...")
HARDCODING → values that should be configurable baked into code
```

## Anti-padrões de processo/arquitetura

```text
BIG BALL OF MUD → no clear architecture; everything tangled
OVER-ENGINEERING → unnecessary complexity, abstraction, or patterns where not needed
CARGO CULT → using patterns/practices without understanding why
Reinventing the wheel; not invented here; tight coupling everywhere
→ recognizing anti-patterns → write cleaner, more maintainable code by avoiding them
```

## Por que isso importa

Compreender anti-padrões é valioso porque **reconhecer soluções ruins comuns ajuda você a evitá-las**, resultando em código mais limpo e mantível, portanto é um conhecimento de design útil.

Anti-padrões são soluções comuns mas contraproducentes — abordagens que parecem razoáveis mas causam mais problemas (débito técnico, bugs, rigidez) — essencialmente o oposto de padrões de design.

Compreender o que são anti-padrões (soluções comumente utilizadas mas pobres que devem ser evitadas) contextualiza o conceito.

Compreender os **anti-padrões comuns de código/design** — o **God object** (uma classe fazendo muito, violando responsabilidade única), **spaghetti code** (código emaranhado e desestruturado), **copy-paste programming** (duplicação violando DRY, causando bugs que devem ser corrigidos em todo lugar), **magic numbers/strings** (literais não explicados), **otimização prematura** (otimizar antes de necessário), o **golden hammer** (usar em excesso uma ferramenta familiar para tudo), e **hardcoding** — ajuda você a reconhecer e evitar esses erros frequentes no nível de código.

Compreender os **anti-padrões de processo/arquitetura** — a **big ball of mud** (sem arquitetura clara), **over-engineering** (complexidade desnecessária e padrões onde não são necessários — conectando ao julgamento sobre não forçar padrões), e **cargo cult** (usar padrões sem entender por quê) — ajuda a evitar erros maiores estruturais e de processo.

Reconhecer anti-padrões é valioso porque eles são *comuns* — desenvolvedores caem neles naturalmente — então saber como eles parecem e por que são prejudiciais ajuda você a evitá-los conscientemente e escrever código mais limpo e mantível.

Compreender anti-padrões complementa compreender padrões: conhecer tanto boas soluções (padrões) quanto ruins (anti-padrões) melhora o julgamento de design.

Dado que reconhecer soluções ruins comuns (anti-padrões) ajuda você a evitá-las e escrever código mais limpo e mantível, e dado que anti-padrões são armadilhas comuns em que desenvolvedores naturalmente caem (God objects, spaghetti code, duplicação, over-engineering, cargo cult), e dado que compreendê-los complementa conhecer padrões, compreender anti-padrões é conhecimento de design valioso e praticamente relevante — útil para reconhecer e evitar os erros comuns que levam a código ruim, complementando o conhecimento de bons padrões, e importante para o julgamento de design evitar as armadilhas frequentes que prejudicam a qualidade e manutenibilidade do código.