Özel Yazılımda Teknik Borç (Technical Debt) Nedir, Nasıl Yönetilir?

Özel yazılım geliştiren ekiplerin çoğu, teknik borcu bir başarısızlık işareti gibi görür. Oysa sahada gözlemlediğimiz gerçek bunun tam tersi: teknik borç, hızlı karar veren ve gerçekten iş yapan her ekibin doğal bir yan ürünüdür. Sorun borcun var olması değil; görünmez kalması, faizinin hesaplanmaması ve kimsenin geri ödeme planı yapmamasıdır. QuantKOD olarak firmalara özel yazılım geliştirirken öğrendiğimiz şey net: teknik borç yönetilebilir bir mühendislik kalemidir, ahlaki bir kusur değil.

Bu yazıda teknik borcun ne olduğunu, hangi türleri olduğunu, nasıl ölçülüp önceliklendirildiğini ve projeyi kilitlemeden nasıl ödendiğini, uygulamada işimize yarayan bir çerçeve halinde paylaşıyorum.

Teknik Borç Tam Olarak Nedir?

Teknik borç terimini ilk kullanan Ward Cunningham'ın benzetmesi hâlâ en açıklayıcı olanı: Bugün hızlı ilerlemek için aldığınız bir kestirme karar, tıpkı finansal bir borç gibi, ileride faiziyle geri ödenir. Faiz burada, o kestirmenin üstüne yeni özellik eklemeyi her seferinde biraz daha yavaşlatan ek maliyettir.

Önemli bir ayrımı baştan yapalım: teknik borç, kötü kod ile aynı şey değildir. Kötü kod, daha iyisini yapabilecekken yapılmamış işlerdir. Teknik borç ise çoğu zaman bilinçli ve makul bir tercihtir: "Bu modülü şimdilik en basit haliyle yazalım, ürün tutarsa düzgün kurgularız." Sorun, ürün tuttuktan sonra kimsenin geri dönüp o sözü hatırlamamasıdır.

Teknik borcun kendisi tehlikeli değildir; kayıt altına alınmamış ve faizi ödenmeyen teknik borç tehlikelidir.

Teknik Borç Nereden Birikir?

Borcu yönetebilmek için önce nereden geldiğini bilmek gerekir. Sahada gördüğümüz birikim kaynaklarının çoğu, kötü niyetten değil, tamamen anlaşılır baskılardan doğuyor:

• Zaman baskısı: En klasik kaynak. Bir teslim tarihine yetişmek için "şimdilik böyle olsun" denir ve o geçici çözüm kalıcılaşır. Geçici çözümlerin yarı ömrünün, herkesin sandığından çok daha uzun olduğunu defalarca gördük.
• Değişen gereksinimler: Yazılım, üzerine kurulduğu varsayımlar değiştikçe eskir. Başında tek bir ülke için tasarlanan bir sistem, çok ülkeye açılınca aniden borçlu hale gelir; oysa ilk gün doğru karar verilmişti.
• Bilgi eksikliği: Ekip, kullandığı teknolojiyi ya da iş alanını henüz tam tanımıyorken verdiği kararlar, öğrenme ilerledikçe borca dönüşür. Bu kaçınılmazdır; kimse bilmediği bir alanı ilk denemede mükemmel kurgulamaz.
• İletişim kopuklukları: Aynı işi farklı ekiplerin birbirinden habersiz çözmesi, tutarsız ve tekrar eden kod üretir. Bu, mimari kararların yazıya dökülmediği projelerde özellikle hızlı birikir.

Bu kaynakları görmek, suçluyu aramaktan daha yararlıdır. Çünkü borç bir kişinin hatası değil, çoğu zaman sürecin doğal bir sonucudur; dolayısıyla çözüm de kişisel değil, sistemli olmalıdır.

Borcun Türlerini Ayırmak Neden Önemli?

Her teknik borç aynı değildir ve hepsine aynı tepkiyi vermek pahalı bir hatadır. Pratikte borçları dört grupta düşünmek, hangisine ne zaman müdahale edeceğimize karar vermeyi kolaylaştırıyor:

• Kasıtlı ve sağduyulu borç: "Pazara hızlı çıkmak için kimliği doğrulama akışını şimdilik basit tutuyoruz, ölçeklenince yenileyeceğiz." Bilinçli alınmış, planlı borçtur. En sağlıklı türdür çünkü kararın gerekçesi bellidir.
• Kasıtsız ve sağduyulu borç: Ekip o an elindeki en iyi bilgiyle doğru kararı verdi, ama iş büyüdükçe o tasarımın yetmediği ortaya çıktı. "Şimdi öğrendiğimizi başında bilseydik farklı kurgulardık" dediğiniz durumdur. Kaçınılmazdır ve normaldir.
• Kasıtlı ve sağduyusuz borç: "Test yazmaya vaktimiz yok, sonra bakarız." Aciliyet bahanesiyle alınan, gerekçesi zayıf borçtur. Faizi en yüksek ve en sinsi türdür.
• Kasıtsız ve sağduyusuz borç: Ekip iyi pratikleri bilmediği için biriken borç. Bu aslında bir eğitim ve süreç sorunudur, kod sorununun ötesindedir.

Bu ayrımın pratik faydası şu: ilk iki tür borçla birlikte yaşamayı öğrenirsiniz, son iki türü ise kök nedeniyle birlikte ortadan kaldırmaya çalışırsınız. Hepsini "kötü kod" diye tek torbaya koyarsanız, hangisinin gerçekten tehlikeli olduğunu göremezsiniz.

Görünmeyen Borcu Görünür Kılmak

Teknik borcun en büyük tehlikesi muhasebesinin tutulmamasıdır. Finansal borcunuz bilançoda görünür; teknik borç ise çoğu zaman sadece geliştiricilerin kafasında, "şu modüle dokunmak istemiyorum" hissi olarak yaşar. Bir gün o geliştirici ekipten ayrılır ve borç tamamen görünmez hale gelir.

Sahada işimize yarayan en somut adım, borcu yazılı ve takip edilebilir hale getirmek oldu. Bunu hayata geçirmenin birkaç pratik yolu var:

1. Borç kaydı tutun. Fark edilen her ciddi teknik borç, normal bir iş kalemi gibi kayıt altına alınmalı. Kaydın içinde sorunun ne olduğu, neyi yavaşlattığı ve düzeltilmezse riskinin ne olacağı net yazmalı.
2. Kodun içine işaret bırakın. Geçici bir çözüm yazıldığında, kodun içinde nedenini ve ilgili kaydı belirten kısa bir not bırakmak, aylar sonra o satıra bakan kişiye paha biçilmez bağlam sağlar.
3. Faizi konuşun. Borç kaydı yalnızca "şurada kötü kod var" demesin; "bu yüzden bu alandaki her değişiklik tahminimizce iki katı sürüyor" gibi somut bir etki içersin. Karar verenleri ikna eden, kodun çirkinliği değil, yavaşlattığı iştir.

Borcu Nasıl Ölçer ve Önceliklendiririz?

"Ne kadar borcumuz var?" sorusuna tek bir sihirli sayıyla cevap veren araçlara temkinli yaklaşmakta fayda var. Statik analiz araçlarının ürettiği skorlar yön gösterir ama bağlamdan yoksundur; hiç dokunulmayan, sorun çıkarmayan bir modüldeki "borç" pratikte sizi hiç yavaşlatmıyor olabilir.

Bizim için daha anlamlı olan ölçüt, borcun gerçek iş üzerindeki etkisidir. Şu soruları sormak, soyut bir skordan çok daha iyi karar verdiriyor:

• Bu kod ne sıklıkta değişiyor? Sık değişen ve aynı zamanda kırılgan olan alanlar, borç ödemesi için bir numaralı adaydır.
• Buraya dokunan geliştiriciler ne kadar yavaşlıyor ve ne kadar sık hata üretiyor?
• Bu borç bir gün patlарsa sonucu ne olur? Veri kaybı ve güvenlik açığı riski taşıyan borç ile sadece estetik olan borç aynı aciliyette değildir.

Pratik bir kural: nadiren değişen ve iyi çalışan çirkin kodu rahat bırakın. Enerjinizi, sık dokunduğunuz ve sizi sürekli yavaşlatan alanlara yöneltin. Burada amaç tüm borcu sıfırlamak değildir; tıpkı finansal borçta olduğu gibi, en yüksek faizli olanı önce ödemektir.

Borcu Ödemenin Sürdürülebilir Yolu

Teknik borç yönetiminde en sık yapılan iki hata var. Birincisi borcu tamamen yok saymak; ikincisi ise işi durdurup aylarca süren büyük bir "yeniden yazım" projesine girişmek. İkincisi, ilkinden bile tehlikeli olabilir çünkü çalışan bir sistemi atıp baştan yazmak, çoğu zaman aynı hataların yeni sürümünü üretir.

Sürdürülebilir yaklaşım, ödemeyi günlük çalışma ritmine yerleştirmektir. İşimize yarayan birkaç ilke:

• İz bırakma kuralı: Bir dosyaya özellik eklemek için dokunduğunuzda, o dosyayı bulduğunuzdan biraz daha temiz bırakın. Küçük ama sürekli iyileştirmeler, dev temizlik kampanyalarından daha kalıcı sonuç verir.
• Kapasite ayırın: Her geliştirme döneminde, ekibin emeğinin makul bir bölümünü borç ödemesine ayırmayı baştan kabul edin. Bunu "artarsa yaparız" diye bırakırsanız asla zaman artmaz.
• Testle koruma altına alın: Bir alanı yeniden düzenlemeden önce, mevcut davranışı testlerle çitleyin. Böylece iyileştirme yaparken sistemi bozmadığınızdan emin olursunuz; testsiz refactoring, borcun üstüne risk eklemekten başka bir şey değildir.
• Borcu işin diline çevirin: Karar vericilere "kodu güzelleştireceğiz" demeyin. "Bu modülü düzelttiğimizde yeni özellikleri yarı sürede çıkaracağız ve hata sayısını düşüreceğiz" deyin. Borç ödemesi, ancak bir iş yatırımı olarak konumlandığında onay bulur.

Sonuç: Borç Bir Araçtır, Yük Değil

Teknik borçtan tamamen kaçınmaya çalışan ekipler genellikle çok yavaş ilerler; borcu hiç umursamayan ekipler ise bir süre sonra her küçük değişiklikte tıkanır. Doğru nokta ikisinin arasındadır: borcu bilinçli alın, kayıt altına alın, faizini izleyin ve en pahalı olanları düzenli olarak ödeyin.

Özel yazılımda kalıcı hız, hiç borç almamaktan değil, borcu görünür ve yönetilebilir tutmaktan gelir. Bir projenin sağlığını anlamak istiyorsanız, ne kadar borcu olduğuna değil, o borcun ne kadarını gördüğüne ve nasıl yönettiğine bakın.