Hogyan hozol meg és dokumentálsz jelentős technikai döntéseket?

Question

Accepted Answer

A jelentős technikai döntéseket **szándékosan, átlátható módon és rögzítve** kell meghozni, nem pedig valaki fejében, majd elfelejtve. A jó folyamat feltárja az kompromisszumokat, építi a konszenzust, és nyomot hagy, hogy a jövőbeni mérnökök megértsék a *miért*, nem csak a *mit*.

## Egy döntéshozási keret

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

## Rögzítse ADR-rel

Egy **Architecture Decision Record** rövid, tartós jegyzet:

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

## A kezelendő kompromisszum

Mindennek dokumentálása terhelés; semmi sem dokumentálása elveszíti az intézményi emlékezetet. Az ADR-eket olyan döntésekhez tartsuk fenn, amelyek **drágák a visszafordításra** vagy amelyeket a jövőbeni mérnökök kérdőjeleznek meg.

## Miért fontos ez

A dokumentálatlan döntéseket végtelenül újra vita tárgya lesz, minden új mérnök megkérdezi "miért választottuk ezt?"

Az érvelés leírása szintén tisztaságra kényszerít: ha papíron nem tudod indokolni, akkor valószínűleg nem gondolkoztál rajta kellőképpen.