Kaip priimate ir dokumentuojate reikšmingus techninius sprendimus?

Question

Accepted Answer

Reikšmingi techniniai sprendimai turi būti **sąmoningi, skaidrūs ir užregistruoti**, o ne priimti kažkieno galvoje ir pamiršti. Geras procesas atskleidžia kompromisus, kuria sutarimą ir palieka pėdsaką, kad ateities inžinieriai suprastų *kodėl*, o ne tik *ką*.

## Sprendimo priėmimo sistema

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

## Užregistruokite ADR

**Architecture Decision Record** yra trumpas, ilgalaikis pastabėlis:

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

## Kompromisas, kurį reikia valdyti

Vsio dokumentavimas yra papildomas darbas; nieko nedokumentuojant prarandama institucinė atmintis. ADR skirti sprendimams, kurie **brangūs grąžinti** arba kuriuos ateities inžinieriai bus ginčyti.

## Kodėl tai svarbu

Nedokumentuoti sprendimai nepabaigiamai peržiūrimi, kiekvienas naujas inžinierius vėl klausia "kodėl mes pasirinkome šitai?"

Rašant samprotavimą, taip pat priversčiama aiškumą: jei negalite to pagrįsti popieriuje, tikriausiai nesukūrėte apie tai pakankamai.