Bu yazı, teknik borcu “kötü kod” olarak değil; kısa vadeli teslimat hızının uzun vadede bakım maliyeti, risk ve yavaşlık olarak geri dönmesi şeklinde açıklar. Teknik borcun türlerini (tasarım borcu, test borcu, altyapı/CI-CD borcu, bağımlılık borcu) ve “faiz” etkisini (incident artışı, delivery hızının düşmesi, güvenlik açıkları) örneklerle ele alır. Son bölümde teknik borcu görünür kılma, önceliklendirme ve sistematik şekilde azaltma için uygulanabilir bir çerçeve sunulur.
Fatih Kemer ·
1) Teknik borç nedir?
Teknik borç, bir yazılımı hızlı teslim etmek için yapılan “kolaylaştırmaların” (kestirme çözümler) zamanla ek maliyet olarak geri dönmesidir.
Finanstaki borç gibi düşünün:
Bugün hız kazanırsınız
Yarın “faiz” ödersiniz (hata, yavaş geliştirme, kırılganlık)
2) Teknik borcun “faizi” nasıl görünür?
Aynı özelliği eklemek eskisine göre daha uzun sürmeye başlar
Prod ortamında incident sayısı artar
Regresyon hataları çoğalır (test yokluğu)
Performans sorunları ve gecikmeler kalıcılaşır
Güvenlik açıkları (eski kütüphaneler, patch eksikliği) ortaya çıkar
3) Teknik borç türleri (en yaygın 5 kategori)
Tasarım borcu: yanlış mimari, sınırların belirsizliği
Kod borcu: kopya kod, okunabilirlik düşüklüğü, “hack” çözümler
Test borcu: unit/integration/e2e eksikliği, düşük coverage
Altyapı borcu: manuel deploy, eksik CI/CD, zayıf izleme (monitoring)
Bağımlılık borcu: eski framework/kütüphane, riskli paketler
4) Erken uyarı işaretleri
“Bu kodu kimse dokunmasın” bölgelerinin artması
Sprint sonunda “stabilizasyon” işlerinin çoğalması
PR review sürelerinin uzaması, deploy korkusu
Yeni ekip üyelerinin onboarding süresinin uzaması
Basit değişikliklerin bile beklenmedik yerde kırılması
5) Teknik borç nasıl yönetilir? (Vectorium çerçevesi)
Envanter: borç kalemlerini listele (owner + risk + iş etkisi)
Önceliklendirme: müşteri etkisi + güvenlik + operasyon maliyeti
Plan: her sprint %10–25 “borç ödeme” bütçesi (duruma göre)
Otomasyon: test otomasyonu + CI/CD + observability
Disiplin: “definition of done” içine kalite kriterlerini ekle
6) 30 günlük uygulama planı (pratik)