Come si prendono e documentano le decisioni tecniche significative?

Question

Accepted Answer

Le decisioni tecniche significative devono essere **deliberate, trasparenti e registrate**, non prese nella testa di qualcuno e dimenticate. Un buon processo fa emergere i compromessi, costruisce consenso e lascia una traccia affinché i futuri ingegneri comprendano il *perché*, non solo il *cosa*.

## Un framework decisionale

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

## Registralo con un ADR

Un **Architecture Decision Record** è una nota breve e duratura:

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

## Il compromesso da gestire

Documentare tutto è un sovraccarico; non documentare nulla perde la memoria istituzionale. Riserva gli ADR per decisioni che sono **costose da invertire** o che i futuri ingegneri metteranno in discussione.

## Perché è importante

Le decisioni non documentate vengono ricontestabili endlessly, ogni nuovo ingegnere si chiede di nuovo "perché abbiamo scelto questo?"

Scrivere il ragionamento costringe anche alla chiarezza: se non riesci a giustificarlo sulla carta, probabilmente non ci hai pensato abbastanza.