Hvad er anti-patterns?

Question

Accepted Answer

**Anti-patterns** er almindelige men **dårlige løsninger** på tilbagevendende problemer — tilgange, der virker fornuftige, men fører til dårlige resultater (kode der er svær at vedligeholde, bugget eller stiv). At genkende dem hjælper dig med at undgå almindelige fejltagelser.

## Hvad anti-patterns er

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

## Almindelige kode-/designanti-patterns

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

## Process-/arkitektur anti-patterns

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

## Hvorfor det betyder noget

At forstå anti-patterns er værdifuldt, fordi **at genkende almindelige dårlige løsninger hjælper dig med at undgå dem**, hvilket fører til renere, mere vedligeholdelig kode, så det er nyttig designviden.

Anti-patterns er almindelige men kontraproduktive løsninger — tilgange, der virker fornuftige, men forårsager flere problemer (teknisk gæld, bugs, stivhed) — i bund og grund det modsatte af designpatterns.

At forstå, hvad anti-patterns er (almindeligt anvendte men dårlige løsninger, der bør undgås), præciserer konceptet.

At forstå de **almindelige kode-/designanti-patterns** — **God-objektet** (en klasse, der gør for meget, hvilket krænker single responsibility), **spaghetikode** (forvirrende, ustruktureret kode), **copy-paste-programmering** (duplikation, der krænker DRY, forårsager bugs der skal rettes alle steder), **magiske tal/strenge** (uforklarede litteraler), **præmatur optimering** (optimering før det er nødvendigt), **guldhammer** (overuse af ét velkendt værktøj til alt), og **hardcoding** — hjælper dig med at genkende og undgå disse hyppige fejl på kodeniveau.

At forstå **process-/arkitektur anti-patterns** — **storbøllet mudder** (ingen klar arkitektur), **over-engineering** (unødvendig kompleksitet og patterns hvor det ikke er nødvendigt — forbundet med vurderingen om ikke at tvinge patterns), og **cargo cult** (brug af patterns uden at forstå hvorfor) — hjælper med at undgå større strukturelle og processfejl.

At genkende anti-patterns er værdifuldt, fordi de er *almindelige* — udviklere falder naturligt ind i dem — så at vide, hvordan de ser ud, og hvorfor de er skadelige, hjælper dig med bevidst at undgå dem og skrive renere, mere vedligeholdelig kode.

At forstå anti-patterns supplerer forståelsen af patterns: at kende både gode løsninger (patterns) og dårlige (anti-patterns) forbedrer designvurderingen.

Fordi at genkende almindelige dårlige løsninger (anti-patterns) hjælper dig med at undgå dem og skrive renere, mere vedligeholdelig kode, og fordi anti-patterns er almindelige faldgruber, som udviklere naturligt falder ind i (God-objekter, spaghetikode, duplikation, over-engineering, cargo cult), og fordi at forstå dem supplerer viden om patterns, er forståelse af anti-patterns værdifuld, praktisk relevant designviden — nyttig til at genkende og undgå de almindelige fejltagelser, der fører til dårlig kode, supplerer viden om gode patterns, og vigtig for den designvurdering, der skal undgå de hyppige faldgruber, som skadet kodekvalitet og vedligeholdelse.