Teknik borc yönetimi

Teknik borc, kisa vadeli teslimat icin bilincli olarak alinan mimari ve kod kalitesi odemeleridir. Ward Cunningham metaforu gunumuzde her ekipte kullanılır; ancak çoğu organizasyon borcu olcmeyen, konuşmayan ve biriktiren bir gizli vergi haline getirir. Teknik borc yönetimi, bu vergiyi görünür kilarak ürün ve muhendislik hedeflerini dengelemek icin sistematik bir cerceve gerektirir.

Teknik borc turleri

Borc tek boyutlu degildir. Pratik siniflandirma:

• Kod borcu: Tekrar, zayif isimlendirme, test eksikligi.
• Mimari borc: Yanlış sınırlar, tight coupling, eksik ACL.
• Altyapi borcu: Guncellenmemis runtime, güvenlik yamasi eksigi.
• Dokumantasyon borcu: ADR eksikligi, güncel olmayan diyagramlar.
• Test borcu: Flaky testler, düşük coverage kritik modullerde.

Her tur farklı maliyet profili ve farklı sahip gerektirir. Hepsini tek backlogda karistirmak onceliklendirmeyi zorlastirir.

Bilincli vs gizli borc

Bilincli borc: Takım bilerek hızlı çözüm secti; geri odeme plani vardir. Gizli borc: Bilgi eksikligi, yanlış varsayim veya kod review disiplinsizligi ile birikir. Bilincli borc yönetilebilir; gizli borc sprint planini sessizce eritir.

Olçme ve gorunurluk

Teknik borcu tek sayiyla olcmek imkansizdir; ancak proxy metrikler karar destekler:

1. Cycle time artisi: Ayni alanda değişiklik icin gereken sure uzuyor mu?
2. Defect density: Modül basina üretim hatasi.
3. Code churn: Sürekli değişen dosyalar risk sinyali.
4. Static analysis skoru: SonarQube, Roslyn analyzer bulgulari.
5. Dependency freshness: EOL kutuphane sayisi.

Bu metrikler birlikte borc haritasi oluşturur. Tek basina satir sayisi veya coverage yuzdesi yeterli degildir.

Borc kaydi formati

Her bilincli borc kaydedilmelidir:

## TD-042: Legacy payment mapper
- Borc: Stripe v1 API dogrudan controllerda
- Neden: Black Friday deadline
- Faiz: Her yeni odeme metodu 3 gun ek gelistirme
- Geri odeme: Q2 ACL refactor, tahmini 5 sprint gunu
- Sahip: Platform team

Bu kayıt ürün yoneticisi ile paylasilir; borc ürün kararinin parcasidir.

Faiz metaforu

Borc ana parasi refactor maliyetidir; faiz her degisiklikte odenen ek suredir. Faiz yüksek modullerde geliştirme durur denilebilir. Faiz oranini takım retrospektifinde tartismak, borc konusmasini somutlastirir.

Onceliklendirme cercevesi

Tüm borcu ayni anda odeyemezsiniz. Öncelik matrisi:

• Yüksek faiz + yüksek dokunma: Hemen planla.
• Yüksek faiz + düşük dokunma: Arka plan refactor.
• Düşük faiz + yüksek dokunma: Özellik geliştirirken lokal iyileştirme.
• Düşük faiz + düşük dokunma: Kabul et veya sil.

Strangler Fig ile büyük borc parça parça geri odenir; big bang rewrite genellikle basarisizdir.

Urün ile denge

Teknik borc yalnizca muhendislik meselesi degildir. Product owner ile capacity allocation anlasilir: sprint kapasitesinin yüzde 15-25 borc geri odemesine ayrilabilir. Bu oran ürün olgunluguna gore degisir. Erken startup daha fazla bilincli borc alabilir; olgun ürün faiz odemek zorundadir.

Code review ve borc onleme

Yeni borc birikimini yavaslatmak icin review checklist:

• Bu PR bilincli borc mu? Kayıt var mi?
• Test eklendi mi?
• Sınırlar ihlal edildi mi?
• Performans regresyonu var mi?

Review sadece stil degil borc etkisini de degerlendirmelidir.

Refactor güvenliği

Borc geri odemesi davranis degistirmeden yapilmali. Characterization test, golden master ve feature flag ile refactor güvenli yapilir. Boyut küçük PRlarda tutulur; büyük refactor review yorgunlugu yaratir.

Organizasyonel anti-patternler

1. Borc sifir fantezisi: Her satirin mukemmel olmasi teslimati durdurur.
2. Sonsuz refactor: Ürün degeri uretilmez.
3. Borc gizleme: Deadline baskisi kayıt olmadan borc biriktirir.
4. Blame culture: Borcu kisisellestirmek kayıt kulturunu oldurur.

Metrik panosu ornegi

Engineering dashboard su panelleri icerebilir:

• Açık borc kayitlari ve yasi
• Modül bazli cycle time trendi
• Production incident ile borc modulu korelasyonu
• Dependency EOL takvimi

Incident kok neden analizi teknik borca geri baglandiginda yatırım onaylanir.

Büyük yeniden yazim karari

Bazen geri odeme rewrite gerektirir. Karar kriterleri:

• Faiz mevcut geliştirme hizini yari yariya mi dusuruyor?
• Domain bilgisi korunabilir mi?
• Paralel çalıştırma (strangler) mümkün mu?
• Is surekliligi riski kabul edilebilir mi?

Rewrite ürün roadmap ile senkron planlanmali; gizli proje olarak yapilmamali.

Özet

Teknik borc kacinilamazdir; yonetimsiz borc ise surdurulemezdir. Turleri siniflandirin, bilincli borcu kaydedin, faizi olcun, ürün ile kapasite paylasin. Geri odeme küçük güvenli adimlarla yapilir. Borc kulturu şeffaf ve yargisiz oldugunda takım uzun vadede hizlanir.

Sprint ritueli

Her sprint planlamada bir borc maddesi secilir ve kabul kriteri net yazilir. Retrospektifte odenen borc ve yeni borc sayisi gozden gecirilir. Trend yukseliyorsa ürün gundemine tasınır.

Arac destegi

Issue trackerda tech-debt etiketi, SonarQube quality gate ve dependency bot PRlari borcu görünür tutar. Araclar karar vermez; veri sağlar.

Quadrant modeli

Martin Fowler teknik borc quadrant modeli: bilincli/reckless ve bilincli/prudent ayrimi. Reckless bilincli borc kayıt olmadan alinir; prudent borc planli geri odeme ile gelir. Takım hangi quadrantta oldugunu retrospektifte tartisir.

Modül bazli borc haritasi

Heat map: eksenler faiz orani ve değişim sikligi. Kirmizi bolgeler refactor sprint adayidir. Harita uctan uca güncellenir; statik tek seferlik analiz yetmez.

Vendor ve lisans borcu

EOL framework veya lisans riski teknik borc sayilmalidir. Upgrade penceresi takvime yazilir; güvenlik acigi faiz gibi hizla artar.