Aşağıdaki proje için teknik borç yönetim planı hazırla:
PROJE:
- Yaş: [N YIL]
- Büyüklük: [LOC / MODÜL SAYISI]
- Ekip: [N KİŞİ]
- Mevcut borç hissi: [DÜŞÜK / ORTA / KRİTİK]
ÜRET:
1. TEKNİK BORÇ ENVANTERİ:
Kategorize et:
- Kod borcu: duplicate code, uzun fonksiyonlar, kötü isimlendirme, dead code
- Mimari borcu: monolith sıkışıklık, tight coupling, circular dependency
- Test borcu: düşük coverage, kırılgan testler, eksik integration test
- Altyapı borcu: eski framework/dil, EOL dependency, manual deploy
- Dokümantasyon borcu: eksik README, outdated API docs, tribal knowledge
2. ÖLÇME:
- SonarQube: code smell, complexity, duplication, coverage
- Dependency age: kaç bağımlılık güncel değil
- Build süresi: artıyorsa karmaşıklık artıyor
- Bug oranı: modül başına bug yoğunluğu
- Developer survey: "hangi alanda en çok acı çekiyorsun"
3. ÖNCELİKLENDİRME (2x2 matris):
- Etki (yüksek/düşük) × Efor (yüksek/düşük)
- Quick wins: yüksek etki + düşük efor → hemen yap
- Strategic: yüksek etki + yüksek efor → planla
- Fill-in: düşük etki + düşük efor → boş zamanda
- Skip: düşük etki + yüksek efor → şimdilik bırak
4. REFACTORING STRATEJİSİ:
- Boy Scout Rule: dokunduğun kodu iyileştir (her PR'da küçük düzeltme)
- Dedicated sprint: 3-4 sprintte 1 tane pure tech debt sprint
- %20 kuralı: her sprintten %20'si tech debt'e
- Strangler pattern: eski modülü yenisiyle kademeli değiştir
- Feature + refactor birlikte: yeni özellik yazarken ilgili borcu temizle
5. YÖNETİMLE İLETİŞİM:
- Teknik borç = finansal borç metaforu (faiz birikir)
- İş etkisi ile anlat: "Bu borç yüzünden her yeni özellik X gün fazla sürüyor"
- Velocity trend grafiği (düşüyorsa borç artıyor)
- Risk: güvenlik açığı, system down, developer kaybı
6. ÖNLEMELEME:
- Definition of Done'da kalite kriterleri
- Code review kültürü
- Linter + formatter zorunlu
- ADR (Architecture Decision Records)
- Yeni borç alma kararı bilinçli ("bilerek shortcut alıyoruz, ticket açıyoruz")
Türkçe, yazılım mühendisliği tech debt management best practice.