Teknik borç nedir, ne zaman ödenir? Ölçme, önceliklendirme ve bütçeleme

Teknik borç, bugün hızlı ilerlemek için verilen tasarım kararlarının yarın ödenecek faizi. Özensiz kodla aynı şey değil; bu ikisi sürekli karıştırılıyor. Dağınık kod sadece dağınıklıktır, borç ise bilerek ya da farkında olmadan alınmış, geri ödenebilir bir yükümlülüktür. Yönetilebilir hâle gelmesi dört şeye bağlı: borcu his olarak değil zaman olarak konuşmak, tarayıcı toplamına değil değişim sıklığına göre önceliklendirmek, ödemeyi ayrı bir temizlik sprintine değil zaten yapacağınız işin içine yerleştirmek, ve kapasitenin ne kadarının buna gideceğini yazılı hâle getirmek. Bu dördü oturduğunda borç bir şikâyet konusu olmaktan çıkar, planlanabilir bir kaleme dönüşür.

Metafor 1992'de ne anlatmak istiyordu

Ward Cunningham terimi WyCash portföy yönetim sistemini geliştirirken ortaya attı ve OOPSLA'92 deneyim raporunda şöyle tarif etti: ilk kez yazılan kodu yayına vermek borçlanmaya benzer, az miktarda borç geliştirmeyi hızlandırır, yeter ki hemen bir yeniden yazımla kapatılsın. Tehlike borcun ödenmemesinde. "Tam doğru olmayan kod" üzerinde geçirilen her dakika o borcun faizi sayılır.

Cunningham 2009'da metaforu bir kez daha açıkladı, çünkü yaygın okuma yanlıştı. Anlatmak istediği şey kodu bilerek kötü yazıp sonra düzeltmek değildi; kastettiği, ürünü kullandıkça alan hakkında öğrendiklerinizle kodun ifade ettiği model arasında açılan mesafeydi. Martin Fowler bunu iki eksenli bir tabloya oturtuyor: borç bilinçli mi yoksa farkında olmadan mı alındı, ve ihtiyatlı mı yoksa pervasız mı. Dört hücre çıkıyor ve hepsi aynı ilgiyi hak etmiyor. Fowler'ın altını çizdiği hücre ihtiyatlı-farkında olmadan olanı: bir projede en iyi tasarımın ne olması gerektiğini anlamak bir yıl programlama alabilir, dolayısıyla bu tür borç iyi ekiplerde bile kaçınılmaz.

Sayılar bunu teknik bir dert olmaktan çıkarıyor

Stack Overflow'un 2024 geliştirici anketinde profesyonel geliştiricilerin %62,4'ü işteki en büyük sıkıntı olarak teknik borç miktarını işaretledi. Listedeki ikinci ve üçüncü sıkıntılar (derleme ve dağıtım için teknoloji yığınının karmaşıklığı, %32,9 ve %32,3) bunun yarısı kadar. Yani tek bir kalem, diğerlerinin iki katı ağırlıkta.

Yönetim tarafındaki tablo da benzer. McKinsey'in geliri 1 milyar doların üzerindeki finans ve teknoloji şirketlerinden 50 CIO ile yaptığı ankette, yeni ürünlere ayrılan teknoloji bütçesinin %10 ila %20'sinin teknik borçtan kaynaklanan sorunlara kaydığı söylenmiş. Aynı yöneticiler teknik borcun, amortisman öncesi tüm teknoloji varlıklarının değerinin %20 ila %40'ı kadar olduğunu tahmin ediyor. Katılımcıların %60'ı borcun son üç yılda gözle görülür biçimde arttığını belirtmiş.

Düşük kaliteli kodun faturası ölçüldü

Adam Tornhill ve Markus Borg'un TechDebt 2022 konferansında sunduğu "Code Red" çalışması, kalite tartışmasını tahminden çıkarıp veriye bağlayan ender işlerden biri. Farklı alanlardan 39 özel üretim kod tabanı, toplam 30.737 dosya incelenmiş; kaynak kod analizi, sürüm kontrol geçmişi ve Jira kayıtları birlikte okunmuş. Bulgular şu: düşük kaliteli kod, yüksek kaliteli koda göre 15 kat daha fazla hata barındırıyor. Aynı işi düşük kaliteli kodda çözmek geliştirmede ortalama %124 daha uzun sürüyor. Ve öngörülebilirlik düşüyor, azami çevrim süreleri 9 kata kadar uzuyor.

Bu son madde çoğu yöneticinin asıl derdine dokunuyor. Ortalamanın iki katına çıkması can sıkıcıdır, ama tahminlerin tutmaması planlamayı bütünüyle bozar. Fowler'ın konuya bakışı da bunu destekliyor: iç kaliteyi düşürmenin kazandırdığı süre sanıldığı kadar uzun değil, geliştiriciler kötü kodun kendilerini birkaç hafta içinde belirgin biçimde yavaşlattığını görüyor. Aylar değil, haftalar.

Tarayıcının verdiği "toplam borç" bir bütçe değil

Statik analiz araçları borcu gün cinsinden raporlar ve bu sayı ilk bakışta ikna edici görünür. Nasıl hesaplandığını bilmek şart. SonarQube'un kullandığı SQALE yaklaşımında teknik borç oranı, düzeltme maliyetinin geliştirme maliyetine bölümüdür; geliştirme maliyeti ise varsayılan olarak satır başına 30 dakika kabul edilerek bulunur. Sürdürülebilirlik notu bu orandan çıkar, A notu için oranın %5'in altında olması gerekir.

Yani "142 günlük borcunuz var" cümlesinin arkasında sabit bir katsayı ve kural setinin ne kadar sıkı ayarlandığı vardır. Eğilimi izlemek için iyi bir sayıdır, bütçe kalemi olarak kullanmak için değil. İki pratik kural işe yarıyor. Birincisi, eski kod için sıfır bulgu hedefi koymayın; bunun yerine yeni yazılan kodda eşiği sert tutun, çünkü asıl kontrol edebildiğiniz yer orası. İkincisi, oranı depo genelinde değil değişen kod üzerinde ölçün; ekibin bu hafta ürettiği borcu görmek, beş yıl önce üretilmiş toplamı görmekten daha çok işe yarar.

Önceliklendirme: değişim sıklığı ile karmaşıklığın kesişimi

Bir kod tabanındaki her kötü dosya aynı derecede pahalı değil. Kimsenin iki yıldır açmadığı karmaşık bir modül size hiçbir şeye mal olmuyor. Asıl bedel, hem karmaşık hem de sürekli dokunulan dosyalarda birikiyor. Bu kesişime sıcak nokta (hotspot) deniyor ve tespiti için özel bir araç almanız gerekmiyor, git geçmişi yeter:

git log --since="12 months ago" --name-only --pretty=format: \
  | grep -v '^$' | sort | uniq -c | sort -rn | head -20

Çıkan liste, son bir yılda en çok değişen yirmi dosyayı verir. Bunları dosya uzunluğu ya da elinizdeki karmaşıklık ölçüsüyle yan yana koyduğunuzda öncelik listeniz büyük ölçüde hazır olur. Etkisi de küçümsenecek gibi değil. CodeScene'in belgelerindeki bir örnekte önceliklendirilmiş sıcak noktalar kod tabanının %5,5'ini oluşturuyor, geliştirme eforunun %17,6'sını ve düzeltilen hataların %23'ünü barındırıyor; belgeler bu son oranın çoğu kod tabanında daha da yüksek çıktığını ekliyor.

Ödeme zamanını kodun kötülüğü değil yol haritası belirler

Doğru soru "burası ne kadar kötü" değil, "önümüzdeki çeyrekte buraya dokunacak mıyız". Dokunmayacaksanız borç orada durur ve size faiz yazmaz. Dokunacaksanız, temizlik o işin ilk adımıdır. Kent Beck'in kuralı bunu tek cümleye indiriyor: istediğiniz değişiklik için önce değişikliği kolay hâle getirin (uyarı: bu kısım zor olabilir), sonra kolay değişikliği yapın. Fowler'ın hazırlık amaçlı yeniden düzenleme (preparatory refactoring) dediği şey de bu.

Bunun pratikteki karşılığı, borç ödemesinin ayrı bir kalem olarak pazarlığa açılmamasıdır. Yeni özelliğin tahminine dahil edilen iki günlük hazırlık, ürün tarafında tartışılmaz; "üç haftalık refactoring" başlığıyla açılan bir talep her seferinde ertelenir. Küçük ve sürekli olanı da elden bırakmayın: dokunduğunuz dosyayı bulduğunuzdan biraz daha temiz bırakmak, yıl boyunca toplandığında planlı temizliklerden fazlasını götürür.

Bütçe: kapasitenin yüzde kaçı, hangi kalemler

İşleyen model, her yineleme kapasitesinin sabit bir yüzdesini bakıma ayırmak ve bunu açıkça yazmak. Oranın kendisinden çok, sabit olması ve ürün tarafıyla anlaşmış olması önemli. Yüzdeyi belirlerken bakılacak sayı da hazır: geçen çeyrekte plansız işe, yani üretimden gelen hata ve acil müdahalelere giden zamanın oranı. Bu oran büyüyorsa bakım payı düşük demektir.

Bir de kriz dönemleri var. 2025'te yayımlanan bir çalışma sekiz açık kaynak projesinde 12,3 bin commit ve 371 sürümü SonarQube ile inceledi; bazı projelerde sürümlerin yarısından fazlasında son teslim tarihi yaklaştıkça teknik borç birikiminin arttığı görüldü. Etki her projede aynı değil, ama yön tanıdık. Buradaki tek gerçekçi savunma, baskı altında bilerek alınan borcu tarihli bir listeye yazmak. Kararı veren kişi, gerekçesi, hangi işten önce kapatılacağı. Yazılmayan borç unutulur; unutulan borç iki yıl sonra "bu kod neden böyle" sorusuna dönüşür.

Yapay zekâ borcu hızlandırıyor

GitClear'ın 2026'da yayımladığı bakım yapılabilirlik araştırması 2023-2026 arasındaki 623 milyon kod değişikliğini inceledi ve eğilim tek yönde. Kopyalanmış kod bloklarında %81 artış, yeniden düzenleme amaçlı satır taşımalarında %70 düşüş, dosyalar arası fonksiyon çağrılarında (yani yeniden kullanımda) %35 düşüş var. Yeni yazılan kodun içinde kopyala-yapıştır payı 2022'de %9,4 iken 2026'nın ilk yarısında %15,7'ye çıkmış. Hatayı gizleyen yapılarda ise %47 artış görülüyor.

Mekanizma anlaşılır. Model, mevcut kodunuzu bulup yeniden kullanmak yerine istediğiniz şeyi yeniden yazmakta çok iyi ve ortaya benzer ama aynı olmayan beş ayrı uygulama çıkıyor. Karşı önlemler yeni değil, sadece daha sıkı uygulanması gerekiyor: incelemede "bu zaten var mı" sorusunu standart hâle getirin, üretilen kodun sessizce yuttuğu hataları geri çevirin, ve yapay zekâ destekli çalışan ekiplerde sıcak nokta listesini üç ayda bir değil ayda bir çıkarın.

Bu haftaya sığan ilk adım

Üç iş yeterli. Bir: yukarıdaki git komutunu çalıştırın, en çok değişen yirmi dosyayı listeleyin. İki: bu listeyi önümüzdeki çeyreğin yol haritasıyla yan yana koyun ve kesişen iki dosyayı seçin. Üç: o iki dosyanın temizliğini bağımsız bir talep olarak değil, ilgili özelliğin tahminine gömülü bir adım olarak planlayın.

Yönetime götürürken de üç sayı yeterli: sıcak noktalardaki hata payı, bir değişikliğin birleşmeden yayına kadar geçen medyan süresi, ve plansız işe giden kapasite oranı. Üçü de zaten elinizdeki verilerden çıkar. Bu ölçümleri düzenli hâle getirmenin en kolay yolu dağıtım hattının içine yerleştirmek; nasıl kurulduğunu küçük ekipler için CI/CD yazımızda anlattık. Borç bir noktadan sonra tek tek dosya temizliğiyle kapanmıyorsa karar başka bir yere kayar, o tartışmayı da eski yazılımı yenilemek mi, sıfırdan yazmak mı yazımızda ele aldık.