Hvordan tar og dokumenterer du betydelige tekniske beslutninger?

Question

Accepted Answer

Betydelige tekniske beslutninger bør være **bevisste, transparente og registrerte**, ikke gjort i hodet på noen og glemt. En god prosess fremhever avveiinger, bygger enighet og etterlater et spor slik at fremtidige ingeniører forstår *hvorfor*, ikke bare *hva*.

## En beslutningsramme

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

## Registrer det med en ADR

En **arkitekturbeslutnningspost** er en kort, holdbar notat:

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

## Avveiingen som skal håndteres

Å dokumentere alt er overhead; å dokumentere ingenting mister institusjonsminne. Reservér ADR-er for beslutninger som er **kostbare å reversere** eller som fremtidige ingeniører vil stille spørsmål ved.

## Hvorfor det betyr noe

Udokumenterte beslutninger blir uten slutt relitisert igjen, hver ny ingeniør spør på nytt "hvorfor valgte vi dette?"

Å skrive ned resonnementet tvinger også klarhet: hvis du ikke kan rettferdiggjøre det på papir, har du sannsynligvis ikke tenkt det grundig gjennom.