Teknik borçu nasıl tanımlar, önceliklendirer ve ödersiniz?

Question

Accepted Answer

**Technical debt**, kodun şu anki durumu ile olması gereken durum arasındaki boşluk olup, daha hızlı ilerleme sağlamak için bilinçli veya bilinçsiz olarak üstlenilen borçtur. Biraz borç sorun değil; iş bunu yönetmek, ortadan kaldırmak değil. Anahtar, gerçekten *zarar veren* borcu önceliklendirmektir.

## Rahatsızlığa göre değil, etkiye göre önceliklendirin

```text
For each piece of debt, ask:
  - How often does it slow us down or cause bugs? (frequency)
  - How bad is it when it bites? (severity)
  - How risky/expensive is it to fix? (cost)

High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
```

## Somut bir örnek

Her yayında kırılan ve ekibi her hafta bloke eden kırılgan bir modül düzeltmeye değer. Çirkin ama stabil olan ve hiç kimsenin dokunmadığı bir utility *değildir*, seni öfkelendirse bile. Refaktoring kibir, değer değildir.

## İşi nasıl finanse edersiniz

Saf "borç sprint"leri nadiren onaylanır. Daha iyi taktikler:

```text
✓ Budget ~10-20% of each sprint for debt continuously
✓ Pay debt down inside related feature work ("boy scout rule")
✓ Tie debt to business pain: "this is why feature X took 3 weeks"
```

## Neden önemli

Yönetilmeyen borç birleşir: hız sessizce düşer, takım neredeyse hiçbir şey gemi kuramazsa.

Ama her eksikliğin peşinden koşmak, önemi olmayan borçta zaman harcar.

Bir TL'nin değeri, farkı bilmek ve liderlere *işletme* koşullarında davada bulunmak, yalnızca mühendislik değil.