Kepiye carane nggawe lan ndokumentasiken kaputusan teknis sing signifikan?

Question

Accepted Answer

Kaputusan teknis sing signifikan kudu **sengaja, transparan, lan direkam**, ora diadani ing sirah wong lan lali. Proses sing apik nuduhake tradeoff, bangun ijin, lan ninggalake jejak supaya insinyur masa depan ngerti *napa*, ora mung *apa*.

## Kerangka karya keputusan

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

## Rekam karo ADR

Satunggaling **Architecture Decision Record** minangka cathetan cendhak lan awet:

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

## Tradeoff kanggo dikelola

Ndokumentasikake kabeh minangka overhead; ora ndokumentasikake apa-apa kelangan memori institusional. Cadangake ADR kanggo kaputusan sing **larang bali** utawa sing insinyur masa depan bakal nanya.

## Napa iku penting

Kaputusan sing ora didokumentasikake dikaji maneh kanthi terus-terusan, saben insinyur anyar takon maneh "napa kita milih iki?"

Nulis alasan uga meksa kajelasan: yen sampeyan ora bisa njustifikasi ing kertas, mbok menawa sampeyan durung mikir kanthi cukup.