Wie triffst und dokumentierst du bedeutende technische Entscheidungen?

Question

Accepted Answer

Bedeutende technische Entscheidungen sollten **bewusst, transparent und dokumentiert** sein – nicht nur im Kopf eines einzelnen getroffen und vergessen werden. Ein guter Prozess macht Trade-offs sichtbar, schafft Zustimmung und hinterlässt eine Spur, sodass zukünftige Engineers verstehen, *warum*, nicht nur *was*.

## Ein Entscheidungsrahmen

```text
1. FRAME the problem and the constraints (cost, time, team skill, scale)
2. LIST the realistic options — usually 2-4, including "do nothing"
3. EVALUATE each against the constraints and trade-offs
4. DECIDE, and state the reasoning explicitly
5. RECORD it (ADR) and communicate it
6. REVISIT if assumptions change
```

## Dokumentiere es mit einem ADR

Ein **Architecture Decision Record** ist eine kurze, dauerhafte Notiz:

```markdown
# ADR 014: Use PostgreSQL for the new service

## Status: Accepted

## Context
We need a primary datastore. Team knows SQL; data is relational; scale is moderate.

## Decision
Use PostgreSQL.

## Consequences
+ Strong consistency, team familiarity, rich querying.
- Vertical scaling limits later; revisit if write volume 10x's.

## Alternatives considered
DynamoDB (rejected: relational data, team unfamiliar).
```

## Der zu managende Trade-off

Alles zu dokumentieren ist Overhead; nichts zu dokumentieren kostet institutionelles Gedächtnis. Reserviere ADRs für Entscheidungen, die **teuer rückgängig zu machen** sind oder die zukünftige Engineers in Frage stellen werden.

## Warum es wichtig ist

Nicht dokumentierte Entscheidungen werden endlos neu diskutiert, jeder neue Engineer fragt wieder „warum haben wir uns dafür entschieden?".

Das Aufschreiben der Begründung zwingt auch zu Klarheit: Wenn du es schriftlich nicht rechtfertigen kannst, hast du es wahrscheinlich nicht durchdacht.