Kako donosite i dokumentirate značajne tehnološke odluke?

Question

Accepted Answer

Značajne tehnološke odluke trebale bi biti **namjerne, transparentne i zabilježene**, a ne donesene u nečijoj glavi i zaboravljene. Dobar proces iznosi kompromise, gradi suglasnost i ostavlja trag kako bi budući inženjeri razumjeli *zašto*, ne samo *što*.

## Okvir za donošenje odluka

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

## Zabilježite je s ADR-om

**Architecture Decision Record** je kratka, trajnabildeška:

```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 kojim treba upravljati

Dokumentiranje svega je dodatni posao; nedokumentiranje svega gubi institucionalno pamćenje. Čuvajte ADR-e za odluke koje su **skupo opozvati** ili koje će budući inženjeri osporavati.

## Zašto je to važno

Nedokumentirane odluke stalno se ponovno sude, svaki novi inžinjer pita "zašto smo to odabrali?"

Pisanje razloga također prisiljava jasnoću: ako to ne možete opravdati na papiru, vjerojatno niste dovoljno razmišljali o tome.