Cosa sono gli anti-pattern?

Question

Accepted Answer

**Anti-pattern** sono soluzioni comuni ma **scarse** a problemi ricorrenti — approcci che sembrano ragionevoli ma portano a risultati negativi (codice difficile da mantenere, buggy o rigido). Riconoscerli ti aiuta a evitare errori comuni.

## Cosa sono gli anti-pattern

```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-pattern comuni nel codice/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-pattern di processo/architettura

```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
```

## Perché è importante

Capire gli anti-pattern è prezioso perché **riconoscere soluzioni comuni e scarse ti aiuta a evitarle**, portando a codice più pulito e mantenibile, quindi è una conoscenza di design utile.

Gli anti-pattern sono soluzioni comuni ma controproducenti — approcci che sembrano ragionevoli ma causano più problemi (tech debt, bug, rigidità) — essenzialmente l'opposto dei design pattern.

Capire cosa sono gli anti-pattern (soluzioni comunemente usate ma scarse che dovrebbero essere evitate) inquadra il concetto.

Capire gli **anti-pattern comuni nel codice/design** — l'**object Dio** (una classe che fa troppo, violando la responsabilità singola), il **codice spaghetti** (codice aggrovigliato e non strutturato), la **copy-paste programming** (duplicazione che viola il DRY, causando bug che devono essere corretti ovunque), i **numeri/stringhe magiche** (letterali inspiegati), l'**ottimizzazione prematura** (ottimizzare prima che sia necessario), il **martello d'oro** (usare eccessivamente uno strumento familiare per tutto), e l'**hardcoding** — ti aiuta a riconoscere ed evitare questi errori frequenti a livello di codice.

Capire gli **anti-pattern di processo/architettura** — la **big ball of mud** (nessuna architettura chiara), l'**over-engineering** (complessità non necessaria e pattern dove non servono — collegandosi al giudizio di non forzare pattern), e il **cargo cult** (usare pattern senza capire il perché) — aiuta a evitare errori strutturali e di processo più ampi.

Riconoscere gli anti-pattern è prezioso perché sono *comuni* — gli sviluppatori vi cadono naturalmente — quindi sapere come si presentano e perché sono dannosi ti aiuta a evitarli consapevolmente e scrivere codice più pulito e mantenibile.

Capire gli anti-pattern complementa la comprensione dei pattern: conoscere sia le buone soluzioni (pattern) che le cattive (anti-pattern) migliora il giudizio di design.

Poiché riconoscere soluzioni comuni e scarse (anti-pattern) ti aiuta a evitarle e scrivere codice più pulito e mantenibile, e poiché gli anti-pattern sono insidie comuni in cui gli sviluppatori cadono naturalmente (object Dio, codice spaghetti, duplicazione, over-engineering, cargo cult), e poiché la loro comprensione complementa la conoscenza dei pattern, capire gli anti-pattern è una conoscenza di design preziosa e praticamente rilevante — utile per riconoscere ed evitare gli errori comuni che portano a codice scadente, complementare alla conoscenza dei buoni pattern, e importante per il giudizio di design per evitare gli insidie frequenti che danneggiano la qualità e la manutenibilità del codice.