Teknik Borç Nedir, Nasıl Ölçülür ve Nasıl Ödenir?

"Şimdi hızlı yapalım, sonra düzeltiriz." Bu cümle her yazılım projesinde kurulur ve çoğu zaman doğru bir karardır: teslim tarihi gerçektir, mükemmel tasarım değildir. Sorun, "sonra"nın hiç gelmemesi ve kararın bir borç gibi faiz işletmesidir: altı ay sonra üç günlük değişiklik iki hafta sürer, sprintin yarısı plansız işe gider, kıdemli geliştirici işten ayrılınca kimse o modüle dokunamaz. Yönetim "neden yavaşladık" diye sorar; ekip "teknik borç" der; kimse rakam veremez.

Bu yazıda teknik borcun ne olduğunu ve ne olmadığını, türlerini, tek bir sayı yerine sinyallerle nasıl ölçüleceğini, borç envanterini ve faiz/anapara ile önceliklendirmeyi, ödeme stratejilerini, yeni borcu önleyen korkulukları ve borcu yönetime nasıl anlatacağınızı anlatıyoruz. Yazı hem ekip liderleri hem de bütçeyi onaylayan yöneticiler için yazıldı.

Teknik borç nedir, ne değildir?

Ward Cunningham'ın benzetmesi: bugün hızlı teslim için alınan tasarım kısayolu bir borçtur; geri ödenene kadar her değişiklikte faiz (ek çaba) ödenir. Kritik ayrım: faiz işletmeyen kod borç değildir. On yıldır değişmeyen, çalışan ve dokunulmayan çirkin bir modül borç değil, tarihtir. Borç, sık değişen ya da olay üreten yerdeki kısayoldur. Martin Fowler'ın dörtlüsü karar kalitesini ayırır:

İyi ekip borcu sıfırlamaz; sağduyulu ve kaydedilmiş tutar, pervasız olanı azaltır.

Türleri

Nasıl ölçülür: sayı değil, sinyaller

Statik analiz araçlarının "teknik borç: 412 gün" rakamı çekici ama yanıltıcıdır: kod kokularını sayar, faizi ölçmez. Borcun gerçek ölçüsü, değişimin ve operasyonun ne kadar pahalılaştığıdır. Birlikte okunan bir sinyal seti:

# Hotspot: son 12 ayda en sık değişen dosyalar (değişim sıklığı); karmaşıklıkla (satır, döngüsel karmaşıklık) çarpılır
git log --since="12 months ago" --format=format: --name-only -- src/main | grep . | sort | uniq -c | sort -rn | head -20

# Örnek çıktı: 143 src/main/java/com/acme/siparis/SiparisServisi.java  ← sık değişen + 1.900 satır = birinci öncelik
#              97  src/main/java/com/acme/fiyat/FiyatHesaplayici.java

Hotspot analizi en değerli ölçümdür çünkü borcun tamamını değil, faiz işleten kısmını gösterir: kod tabanının %4'ü genellikle değişikliklerin %60'ını taşır. Ödeme çabası oraya gider.

Borç envanteri ve önceliklendirme

Borç, isimsiz bir "mimari kötü" şikâyeti olarak değil, kalem kalem yönetilir. Her kalem: konum (modül/dosya), tür, faiz (aylık kayıp saat ya da olay sayısı — tahmin yeterlidir), anapara (ödeme çabası, gün), risk (güvenlik, EOL tarihi), sahip, karar (öde / izle / kabul et). Kayıt yeri iş takip aracıdır; mimari kalemler için ADR (mimari karar kaydı) bağlanır.

Önceliklendirme kuralı: faiz/anapara oranı yüksek ve hotspot'ta olan önce; EOL ve güvenlik kalemleri tarihle; faizi sıfır olan kalem, ne kadar çirkin olursa olsun listenin dibinde.

Nasıl ödenir

1. Sürekli bütçe: Kapasitenin %15–20'si her sprintte borç ödemeye; ayrı bir "borç sprinti" beklemek yerine sürekli akış. Bütçe görünür olsun: pano ve sprint hedefi.

2. Değiştireceğin yeri temizle: Ödeme, hotspot'a ve önümüzdeki özelliğin dokunacağı koda odaklanır; "dokunduğun yeri biraz daha iyi bırak" kuralı özellik işine gömülür. Değişmeyen kodu yeniden yazmak israftır.

3. Önce test, sonra refactor: Testsiz refactor borç ödemek değil, borç almaktır; karakterizasyon testleri ilk adımdır.

4. Büyük kalemler için proje: Çerçeve geçişi, modül ayrıştırma, veritabanı bölme gibi kalemler zaman kutulu, ölçütlü ve strangler fig yaklaşımıyla; big bang değil.

5. Bağımlılık otomasyonu: Renovate/Dependabot ile küçük ve sık güncellemeler; büyük sürüm geçişleri planlı. Bağımlılık yaşı metriği düşer, EOL krizi bir daha olmaz.

6. Bilgi borcu için: Eşli çalışma, modül sahipliği rotasyonu, ADR; tek kişinin bildiği modül listesi yönetim riski olarak izlenir.

Yeni borcu önleyen korkuluklar

// ArchUnit: mimari kurallar test olarak — ihlal PR'da kırılır, tartışması sonra değil şimdi yapılır
@AnalyzeClasses(packages = "com.acme")
class MimariKurallariTest {
    @ArchTest
    static final ArchRule domain_altyapiya_bagimli_olamaz =
        noClasses().that().resideInAPackage("..domain..")
            .should().dependOnClassesThat().resideInAnyPackage("..adapter..", "org.springframework..", "jakarta.persistence..");

    @ArchTest
    static final ArchRule moduller_arasi_dongu_yok =
        slices().matching("com.acme.(*)..").should().beFreeOfCycles();

    @ArchTest
    static final ArchRule controller_repository_cagiramaz =
        noClasses().that().resideInAPackage("..api..").should().dependOnClassesThat().resideInAPackage("..repository..");
}

Ek korkuluklar: CI kalite kapısı yalnızca yeni ve değişen kod için (eski kodu bir gecede temizlemek yerine "bugünden itibaren kötüleşmez" ilkesi); tanım-of-done'da test; bilinçli borç kararları PR'da // BORÇ: … (BORC-142) etiketiyle ve envanterde; mimari kararlar ADR ile kaydedilir.

Yönetime nasıl anlatılır?

Yönetim kod kokusunu değil, üç şeyi anlar: para, zaman, risk. Faizi o dile çevirin: "On kişilik ekipte kapasitenin %25'i plansız işe ve yavaşlığa gidiyor; bu iki buçuk kişinin maaşı" — sonra "şu üç kalemi bu çeyrek ödersek plansız iş %25'ten %12'ye iner" gibi ölçülebilir bir vaat. Riski tarihle anlatın: "Çerçevenin güvenlik desteği Mart'ta bitiyor; denetimde bulgu olur." Her çeyrek üç kalem seçin, eğilim grafiğini gösterin (teslim süresi, plansız iş oranı), ödeme sonrası farkı raporlayın. Güven, ilk ölçülebilir kazanımdan sonra gelir; "her şeyi baştan yazalım" teklifi güveni bitirir.

Sahada sık yapılan hatalar

1. Tek sayıya bağlanmak: Statik analizin "412 gün"ü düşerken teslim süresi uzuyorsa yanlış şey ölçülüyor.

2. Büyük temizlik sprinti: Üç haftalık "refactor sprinti" genellikle yarım kalır ve regresyon getirir; sürekli bütçe daha etkilidir.

3. Sahipsiz envanter: Liste büyür, kimse ödemez.

4. Testsiz refactor: Borç yerine olay.

5. Değişmeyen kodu güzelleştirmek: Sıfır faizli kalem için anapara ödemek.

6. Bağımlılık borcunu EOL gününe kadar ertelemek: Planlı bir çeyreklik iş, plansız bir kriz olur.

7. Borcu ahlaki mesele yapmak: "Kim yazdı bunu" sorusu yerine "faizi ne, anaparası ne" sorusu.

Sık sorulan sorular

Ne zaman "iflas" ilan edilir (yeniden yazım)?

Faiz, anaparanın ödenmesini imkânsız kılacak kadar yüksekse ve platform gerçekten ölmüşse; ama bu nadirdir ve yeniden yazım da kendi borcunu üretir. Çoğu durumda doğru cevap strangler fig ile kademeli ödemedir (bkz. modernizasyon).

AI kod asistanları borcu artırır mı, azaltır mı?

İkisi de mümkün: kuralsız kullanımda hızlı üretilen, anlaşılmayan kod borcu artırır; test yazımı, açıklama ve mekanik refactor'da doğru kullanımda ödemeyi hızlandırır. Belirleyici olan inceleme disiplinidir (bkz. AI kod asistanı).

Yeni projede borç nasıl önlenir?

Önlenmez, yönetilir: ilk günden kalite kapısı, ArchUnit kuralları, ADR ve borç etiketi; bilinçli alınan her kısayol envantere yazılır. Sıfır borç hedefi, hiç teslim etmemek demektir.

Sonuç

Teknik borç kaçınılmazdır ve iyi yönetildiğinde bir araçtır; ölçülmediğinde ve sahipsiz kaldığında ekibi yavaş yavaş durduran bir faiz yüküdür. Doğru yaklaşım: faiz işleten yeri hotspot ve teslim metrikleriyle bul, kalem kalem envantere yaz, faiz/anapara ile önceliklendir, sürekli bütçeyle ve değiştireceğin yerden başlayarak öde, yeni borcu korkuluklarla sınırla ve yönetime para-zaman-risk diliyle anlat.

Ekibinizin teknik borç envanterini çıkarmak, hotspot analizi yapmak ve ölçülebilir bir ödeme planı kurmak için yazılım tasarımı ve mimari ile bakım ve destek hizmetlerimize göz atabilirsiniz.