Teknik Borç Yönetimi
Teknik borç, kısa vadeli çözümlerin uzun vadede yarattığı bakım ve geliştirme maliyetidir. Sıfır teknik borç hedeflemiyoruz; bilinçli ve yönetilen teknik borç kabul edilebilir.
Teknik borç kötü değildir — yönetilmeyen teknik borç kötüdür. Bilinçli kararlarla alınan borç, zamanında ödenir.
Teknik Borç Kategorileri
| Kategori | Tanım | Örnek |
|---|---|---|
| Kasıtlı / Bilinçli | Hız için bilinçli tercih | MVP için basit çözüm, sonra refactor planı |
| Kasıtsız / Keşfedilen | Zamanla ortaya çıkan | Ölçek büyüdükçe yetersiz kalan mimari |
| Bit Rot | Bakımsızlıktan bozulma | Güncellenmemiş bağımlılıklar, eski API'ler |
| Çevresel | Dış faktörlerden kaynaklanan | Framework deprecation, platform değişikliği |
Teknik Borç Puanlama
Her teknik borç kalemi şu kriterlerle değerlendirilir:
| Kriter | Düşük (1) | Orta (2) | Yüksek (3) |
|---|---|---|---|
| Etki | Tek modül | Birden fazla servis | Sistem geneli |
| Aciliyet | 6+ ay bekleyebilir | 1-3 ay içinde çözülmeli | Hemen müdahale |
| Büyüme Riski | Sabit kalır | Yavaş büyür | Hızla kötüleşir |
| Geliştirici Etkisi | Minimal rahatsızlık | Yavaşlatıcı | Bloker |
Yönetim Stratejisi
- Her sprint'te %20 kapasite teknik borç ödemeye ayrılır
- Büyük refactoring'ler RFC süreci ile planlanır
- Tech debt backlog'u ayrı tutulur ve düzenli gözden geçirilir
- Boy Scout Rule: dokunduğun kodu biraz daha iyi bırak
- Yeni özellik geliştirirken mevcut borcu artırmamaya dikkat et
- Çeyreklik 'Tech Debt Review' toplantısı yapılır
Teknik Borç Oluşturma Kuralları
- Bilinçli borç alırken: neden, ne zaman ödeneceği ve riski yazılı olmalı
- TODO/HACK/FIXME yorumları ticket referansı içermeli
- Borç kararı code review'da tartışılmalı ve onaylanmalı
- Ödeme planı olmayan borç kabul edilmez
Teknik borç görünür olmalıdır. Gizli borç en tehlikeli borçtur. Backlog'a yazın, takip edin, ödeme planı yapın.