Jak podejmujesz i dokumentujesz znaczące decyzje techniczne?

Question

Accepted Answer

Znaczące decyzje techniczne powinny być **celowe, przejrzyste i rejestrowane**, a nie podejmowane w czyjejś głowie i zapomniane. Dobrym procesem wychodzą na jaw kompromisy, buduje się poparcie i pozostawia ślad, aby przyszli inżynierowie zrozumieli *dlaczego*, a nie tylko *co*.

## Ramy decyzyjne

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

## Zapisz to za pomocą ADR

**Zapis decyzji architektonicznej** to krótka, trwała notatka:

```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 do zarządzania

Dokumentowanie wszystkiego to obciążenie; niedokumentowanie niczego prowadzi do utraty pamięci instytucjonalnej. Zarezerwuj ADR dla decyzji, które są **kosztowne do cofnięcia** lub które przyszli inżynierowie będą kwestionować.

## Dlaczego to ważne

Niedokumentowane decyzje są bezustannie ponawiane, każdy nowy inżynier pyta na nowo "dlaczego wybraliśmy to?"

Zapisanie uzasadnienia zmusza również do jasności: jeśli nie potrafisz tego uzasadnić na papierze, prawdopodobnie nie przemyślałeś go dokładnie.