Teknik Borç Ne Zaman Ödenir, Ne Zaman Taşınır?

Teknik borç kavramı yazılım ekiplerinde en çok kullanılan, en az tanımlanan terimlerden biri. "Burası teknik borç" cümlesi çoğu zaman "bu kodu beğenmedim" anlamına geliyor. Oysa metaforun kendisi çok daha kullanışlı bir şey söylüyor: borç, faiziyle birlikte anlamlıdır. Bu yazıda teknik borcu duygusal bir şikâyet olmaktan çıkarıp ölçülebilir bir önceliklendirme aracına dönüştüren pratik bir çerçeve kuruyoruz.

Borcun kendisi değil, faizi önemlidir

Bir kod parçasının "kötü" olması tek başına bir maliyet doğurmaz. Maliyet, o koda her dokunduğunuzda ödediğiniz ek süreyle ortaya çıkar. Beş yıldır kimsenin açmadığı, hatasız çalışan 800 satırlık bir rapor üreticisi çirkin olabilir — ama size hiçbir şeye mal olmuyordur. Buna karşılık her sprintte üç kez değiştirdiğiniz, her değişiklikte iki yerde daha bir şeyleri bozan 120 satırlık bir servis, çok daha küçük olmasına rağmen katbekat pahalıdır.

Bu yüzden ilk sorulacak soru "bu kod ne kadar kötü?" değil, "bu dosya son altı ayda kaç kez değişti?" olmalıdır. Sürüm kontrol geçmişiniz bu sorunun cevabını zaten tutuyor; git log --format=format: --name-only --since="6 months ago" | sort | uniq -c | sort -rn | head -20 komutu size en çok dokunulan yirmi dosyayı verir. Bu listeyle kod kalitesi şikâyetlerinizin kesişimi, gerçek teknik borç listenizdir. Git geçmişini günlük akışta daha etkin kullanmak için Git ile çalışma rehberimize göz atabilirsiniz.

Bilinçli borç ve kazara borç ayrımı

Martin Fowler'ın popülerleştirdiği ayrım burada işe yarar. Bilinçli borç, "şu an hızlı çıkmamız gerekiyor, bu yüzden önbelleği atlıyoruz, gerekçesi şu" diye kaydedilmiş bir karardır. Kazara borç ise kimsenin niye öyle yazıldığını hatırlamadığı koddur. İkisinin maliyeti çok farklıdır: bilinçli borcu ödemek bir saatlik iştir, çünkü bağlam yazılıdır. Kazara borcu ödemek önce bir arkeoloji çalışması gerektirir.

Pratik önerimiz basit: hız için bir taviz verdiğinizde, o tavizi kodun içine bir yorum satırı ve tarihle bırakın. "TODO" yeterli değildir; // 2026-03: Ödeme sağlayıcısı toplu uç sunmuyor, tek tek çağırıyoruz. Toplu uç gelirse burası döngüden çıkarılmalı. gibi bir not, altı ay sonra o satıra bakan kişiye saatler kazandırır. Bu alışkanlığın kod incelemesi sürecinde talep edilmesi, ekip genelinde yayılmasının en kolay yoludur.

Ne zaman ödemeliyiz? Üç net sinyal

Refactor kararını tartışmadan çıkarıp veriye bağlayan üç sinyal vardır:

1. Aynı hatanın üçüncü kez dönmesi. Bir bölge iki kez düzeltildiyse tesadüf olabilir; üçüncüde sorun kodun kendisindedir, düzeltmede değil.
2. Tahminlerin sistematik şaşması. Belirli bir modüle dokunan işler sürekli tahminin iki katını alıyorsa, oradaki sürtünme ölçülmüş demektir.
3. Yeni ekip üyesinin aynı yerde takılması. Üst üste iki yeni geliştirici aynı dosyada "burayı anlamadım" diyorsa, sorun kişilerde değildir.

Bu üç sinyalden hiçbiri yoksa, borcu taşımak tamamen meşru bir mühendislik kararıdır. Her kötü kodu düzeltmek zorunda değilsiniz; düzeltmediğinizi bilerek düzeltmemek yeterlidir.

Ödeme nasıl yapılır: büyük yeniden yazım tuzağı

Teknik borcun en pahalı ödeme biçimi, "bu modülü baştan yazalım" kararıdır. Yeniden yazım sırasında eski sistem yaşamaya, hata almaya ve değişmeye devam eder; iki sistemi paralel yürütmek çoğu ekibin tahmin ettiğinden çok daha uzun sürer. Bunun yerine komşuluk kuralı işe yarar: bir dosyaya iş için dokunduğunuzda, o dosyayı bulduğunuzdan biraz daha temiz bırakın. Değişikliğin kendisi zaten test edilecektir, ek risk küçüktür ve borç sprint hızını düşürmeden erir.

Büyük göçler gerekliyse bile kademeli yürütmek şarttır; bu konudaki yaygın hatalar büyük patlama göçünden kaçınma yazımızda ayrıntılı ele alınıyor. Ayrıca refactor öncesi mevcut davranışı kilitleyen testler yazmak, güvenli değişikliğin ön şartıdır; hangi testin ne zaman yazılacağı için test rehberimize bakabilirsiniz.

Borcu görünür kılmak: yönetimle konuşmanın dili

"Refactor yapmamız lazım" cümlesi teknik olmayan bir yöneticiye hiçbir şey ifade etmez. Aynı talebi şöyle kurun: "Sipariş modülünde son üç ayda 11 hata kaydı açıldı, her biri ortalama 4 saat aldı. Bu bölgeyi iki günlük bir düzenlemeyle sadeleştirirsek hata oranının belirgin düşmesini bekliyoruz; iki sprint sonra tekrar ölçeriz." Bu cümlede tahmin, maliyet ve doğrulama planı vardır — reddedilse bile tartışma nesnel zemine oturur.

Konunun kavramsal arka planı için Martin Fowler'ın Teknik Borç Dörtlüsü yazısı hâlâ en berrak kaynaklardan biridir.

Sonuç

Teknik borç, ödenmesi gereken bir ahlaki yük değil, yönetilmesi gereken bir finansal kalemdir. Faizi yüksek olanı — yani sık dokunduğunuz, sık bozulan, yeni gelenin takıldığı kodu — öncelikle ödeyin; geri kalanını bilinçli olarak taşıyın ve taşıdığınızı yazılı hale getirin. Bu ayrımı yapan ekipler hem sonsuz refactor tartışmalarından kurtulur hem de gerçekten pahalı olan yerlere zaman ayırmış olur. Bir sonraki sprint retrospektifinde ekibinize tek bir soru sorun: "Son üç ayda bizi en çok yavaşlatan üç dosya hangisiydi?" Cevap, teknik borç listenizin ilk maddesidir.