Teknik Borç (Technical Debt) Yönetimi: Hızın Gizli Faturası

Yazılım geliştirmede sık duyulan bir cümle vardır: "Şimdilik böyle yapalım, sonra düzeltiriz." Bu cümle çoğu zaman iyi niyetlidir; bir teslim tarihine yetişmek, bir fırsatı kaçırmamak için verilen makul bir karardır. Ancak her "sonra düzeltiriz", geleceğe kesilen bir faturadır. Bu faturaların birikmiş toplamına teknik borç (technical debt) denir. Finansal borç gibi, teknik borç da faiz işletir: bugün kaçırdığınız düzeltme, yarın çok daha pahalıya mal olur. Bu yazıda teknik borcun ne olduğunu, nasıl ölçüleceğini ve onu bir düşman değil, yönetilebilir bir araç haline nasıl getireceğinizi ele alıyoruz.

Teknik Borç Nedir?

Teknik borç, kısa vadeli hız uğruna yapılan ve uzun vadede maliyet yaratan tasarım veya kod kararlarının toplamıdır. Bu benzetmeyi ünlü yazılımcı Ward Cunningham ortaya attı: tıpkı borç para almak gibi, aceleci kod yazmak size şimdi hız kazandırır ama sonra "faiziyle" geri ödemeniz gerekir. Bu faiz, her yeni özelliğin daha yavaş eklenmesi, hataların artması ve ekibin yavaşlaması olarak kendini gösterir.

Teknik borç mutlaka kötü değildir; ödenmeyen teknik borç kötüdür. Sorun borcu almak değil, faizini ödemeyi unutup iflasa sürüklenmektir.

Teknik Borç Türleri

Tüm teknik borç aynı değildir; farklı kaynaklardan gelir ve farklı yönetim gerektirir:

1. Kasıtlı ve dikkatli borç: "Bunun daha iyi bir yolu var ama zamanımız yok, riski biliyoruz." Bilinçli, ölçülü ve genellikle sağlıklı bir karardır.
2. Kasıtsız borç: "En iyisi bu sandık, sonradan yanlış olduğunu öğrendik." Deneyim ve öğrenmeyle azalır.
3. Umursamaz borç: "İyi tasarım nedir, umursamadık." En tehlikeli türdür; disiplin eksikliğinden doğar.
4. Çürüme borcu: Kod ilk yazıldığında iyiydi ama teknoloji, kütüphaneler ve ihtiyaçlar değiştikçe eskidi. Bakımı ihmal edilen her sistemde birikir.

Teknik Borcun Belirtileri

Teknik borç genellikle sessizdir; ama belirtileri vardır. Bir ekip aşağıdakileri yaşıyorsa, muhtemelen ağır bir borç yükü taşıyor demektir:

• Basit görünen bir değişiklik beklenenden çok daha uzun sürüyor.
• Bir yeri düzeltince başka bir yer bozuluyor (kırılgan kod).
• Yeni geliştirici kod tabanını anlamakta çok zorlanıyor.
• Hatalar sürekli geri geliyor; kalıcı çözüm bir türlü mümkün olmuyor.
• Ekip "bu koda dokunmaktan korkuyor."

Bu belirtiler görmezden gelindikçe hız düşer ve bir noktada ekip, yeni değer üretmek yerine mevcut sistemi ayakta tutmakla meşgul olur. İşte teknik iflas budur.

Borcu Görünür Kılmak ve Ölçmek

Teknik borcun en tehlikeli yanı görünmez olmasıdır. Bir yöneticinin bilançoda göreceği bir kalem değildir; kodun içinde saklanır. Bu yüzden ilk adım onu görünür kılmaktır. Statik analiz araçları kod kalitesini, karmaşıklığı ve tekrar oranını ölçer. Ekip, bilinçli olarak aldığı borçları bir "teknik borç kaydı"nda takip edebilir. Görünmeyen borç yönetilemez; görünen borç ise planlanabilir.

Berasoft olarak müşteri projelerinde teknik borcu bir tabu değil, açıkça konuştuğumuz bir konu haline getiririz. "Bu özelliği hızlı çıkarmak için şu borcu alıyoruz ve şu tarihte ödeyeceğiz" demek, sessizce borç biriktirmekten çok daha sağlıklıdır.

Refaktör: Borcu Ödemek

Teknik borcu ödemenin yolu refaktördür (refactoring): kodun dışarıdan davranışını değiştirmeden iç yapısını iyileştirmek. Refaktör bir lüks değil, sürdürülebilir hızın koşuludur. Ancak "her şeyi baştan yazalım" tuzağına düşmemek gerekir; büyük yeniden yazımlar çoğu zaman başarısız olur. Bunun yerine kademeli, güvenli iyileştirme daha etkilidir.

// Refaktör öncesi: her şey tek bir devasa fonksiyonda
function siparisIsle($veri) {
    // 200 satır: dogrulama, hesaplama, kayit, e-posta, log...
}

// Refaktör sonrası: sorumluluklar ayrilmis
function siparisIsle($veri) {
    $dogrulanan = siparisiDogrula($veri);
    $tutar = tutariHesapla($dogrulanan);
    $siparis = siparisiKaydet($dogrulanan, $tutar);
    bildirimGonder($siparis);
    return $siparis;
}

Refaktörü güvenli kılan şey testlerdir. İyi bir test setine sahipseniz, iç yapıyı korkusuzca iyileştirebilirsiniz; çünkü testler bir şeyi bozarsanız hemen haber verir. Testsiz kodda refaktör, gözü kapalı ameliyat gibidir.

Borcu Yönetmenin Pratik Kuralları

• Sıfır borç hedefi koymayın: Amaç borcu yok etmek değil, sürdürülebilir seviyede tutmaktır.
• Her sprintte pay ayırın: Zamanın küçük bir kısmını düzenli olarak borç ödemeye ayırmak, borcun birikmesini engeller.
• İzci kuralını uygulayın: Dokunduğunuz kodu, bulduğunuzdan biraz daha temiz bırakın.
• Borcu iş diliyle anlatın: Yöneticilere "kod çirkin" değil, "bu borç yeni özellikleri yavaşlatıyor" deyin.

Sonuç

Teknik borç, yazılım geliştirmenin kaçınılmaz bir parçasıdır ve doğru yönetildiğinde tehlikeli değil, faydalı bir araçtır. Tıpkı finansal borç gibi, bilinçli alınıp zamanında ödendiğinde büyümeyi hızlandırır; görmezden gelindiğinde ise faiziyle birlikte ekibi felce uğratır. Anahtar üç şeydir: borcu görünür kılmak, düzenli olarak refaktörle ödemek ve onu iş kararlarının bir parçası olarak açıkça konuşmak. "Sonra düzeltiriz" demek bir suç değildir; ama o "sonra"yı hiç getirmemek, en pahalı yazılım hatasıdır. Borcunuzu tanıyın, ölçün ve ödeyin; o zaman hızınız kalıcı olur.