Cum iei și documentezi decizii tehnice semnificative?

Question

Accepted Answer

Deciziile tehnice semnificative trebuie să fie **deliberate, transparente și înregistrate**, nu luate în capul cuiva și uitate. Un proces bun scoate la iveală compromisurile, construiește consensul și lasă o urmă pentru ca viitorii ingineri să înțeleagă *de ce*, nu doar *ce*.

## Un cadru de decizie

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

## Înregistrează-l cu un ADR

Un **Înregistrare de Decizie Arhitecturală** este o notă scurtă și durabilă:

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

## Compromisul de gestionat

Documentarea totului este o suprasarcină; documentarea nimic pierde memoria instituțională. Rezervează ADR-uri pentru decizii care sunt **costisitoare de inversat** sau pe care viitorii ingineri le vor pune la îndoială.

## De ce conteaza

Deciziile nedocumentate sunt relitiga fără sfârșit, fiecare ingineri nou se întreabă din nou "de ce am ales asta?"

Scrierea raționamentului forțează, de asemenea, claritate: dacă nu poți să o justifici pe hârtie, probabil nu ai gândit bine.