Önemli teknik kararları nasıl verirsiniz ve belgelendirirsiniz?

Question

Accepted Answer

Önemli teknik kararlar **kasıtlı, şeffaf ve kaydedilmiş** olmalıdır, birinin kafasında verilip unutulan kararlar olmamalıdır. İyi bir süreç uzlaşmaları ortaya koymaz, anlaşmayı oluşturur ve gelecek mühendislerin *neden* olduğunu anlamasını sağlar, sadece *ne* değil.

## Bir karar çerçevesi

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

## ADR ile kaydedin

Bir **Architecture Decision Record** kısa, dayanıklı bir nottur:

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

## Yönetilecek uzlaşma

Her şeyi belgelendirmek ek işe neden olur; hiçbir şeyi belgelendirmemek kurumsal hafızayı kaybettirir. ADRları **geri döndürülmesi pahalı** olan veya gelecek mühendislerin sorgulayacağı kararlar için ayırın.

## Neden önemli

Belgelendirilmemiş kararlar sonsuza dek yeniden tartışılır, her yeni mühendis "neden bunu seçtik?" diye sorar.

Gerekçeyi yazmak aynı zamanda netliği de zorunlu kılar: eğer bunu kağıt üzerinde haklı çıkaramazsanız, muhtemelen yeterince düşünmemişsinizdir.