Jak vytváříte a dokumentujete významná technická rozhodnutí?

Question

Accepted Answer

Významná technická rozhodnutí by měla být **záměrná, transparentní a zaznamenána**, ne jen promyšlena v něčí hlavě a zapomenuta. Dobrý proces odhaluje kompromisy, buduje souhlas a zanechává stopu, aby budoucí inženýři pochopili *proč*, ne jen *co*.

## Rozhodovací rámec

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

## Zaznamenejte si to pomocí ADR

**Architecture Decision Record** je krátká, trvalá poznámka:

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

## Kompromis, který je třeba zvládnout

Dokumentovat vše je zátěž; nedokumentovat nic znamená ztratit instituční paměť. Rezervujte ADR pro rozhodnutí, která jsou **nákladná na vrácení** nebo která budoucí inženýři budou zpochybňovat.

## Proč je to důležité

Nedokumentovaná rozhodnutí se nekonečně znovu projednávají, každý nový inženýr se ptá "proč jsme si to vybrali?".

Zapsání zdůvodnění také nutí ke srozumitelnosti: pokud to nemůžete obhájit na papíře, pravděpodobně jste o tom nemysleli dost.