Teknik borç kavramını Ward Cunningham 1992'de ortaya attı. Finansal borç metaforuyla anlatıyor: kısa yoldan bir karar almak şimdi hız kazandırır ama ileride "faiz" ödetir — yani o kararı düzeltmek için ekstra zaman harcarsınız.
Buradaki kritik nokta şu: teknik borç kötü değil. Sıfır teknik borçla yazılım geliştirmek neredeyse imkânsız — ve çoğu zaman buna çalışmak bile verimsiz.
İyi teknik borç vs kötü teknik borç
İyi teknik borç, bilinçli alınan bir karardır. "Şu an bunu tam doğru yapmak 2 hafta alır; şimdilik çalışan ama temiz olmayan versiyonu yazalım, müşteri geri bildirimi gelince düzeltiriz" demek. Bu borcu alırsınız çünkü kazancı maliyetini karşılıyor.
Kötü teknik borç, farkında olmadan birikir. Kopyala-yapıştır kod, test edilmemiş kritik işlevler, kimsenin tam anlamadığı konfigürasyonlar. Bu borç kimsenin tutanak tutmadığı, faiz oranı her geçen gün büyüyen bir kredi kartı gibi.
Nasıl birikir?
Çoğunlukla zaman baskısıyla. "Şimdilik böyle kalsın" kararları belgelenmez ve giderek normlaşır. İlk kişi o kodu yazarken bağlamı biliyordur; 6 ay sonra kodu okuyan kişi bilmez. O "geçici çözüm" production'da 3 yıl kalır.
Bir de büyüme sancısından kaynaklanan borç var: başlangıçta doğru olan mimari karar, 10 kat daha fazla kullanıcıyla yanlış hale gelebilir. Bu kaçınılabilir değil — ama öngörülebilir.
Pratik yönetim
Teknik borç görünür olmak zorunda. Bir backlog'da izleyin — ister ticket ister yorum satırı olsun. "TODO: bunu daha iyi yap" yazan bir yorum, o sorunun en azından var olduğunu belgelemiş olur.
Her sprint'e biraz teknik borç ödeme kapasitesi ekleyin. %10-20 oranı sürdürülebilir bir başlangıç noktası. Tüm sprint'i refactoring'e ayırmak çoğu zaman mümkün olmaz — ama küçük, sürekli iyileştirme birikir.
Sıfırdan mı yazalım, refactor mü edelim?
Sıfırdan yazma kararı çok daha nadir doğru çıkar. Joel Spolsky'nin klasik "Things You Should Never Do" yazısında anlattığı gibi: çalışan kod ne kadar çirkin görünürse görünsün, içinde yıllar içinde öğrenilen edge case'lerin bilgisi var. Sıfırdan yazınca bu bilgiyi de sıfırlıyorsunuz.
Kademeli yeniden yazım genellikle daha güvenli. Bir modülü, bir servisi, bir dosyayı. Büyük bang refactoring'ler çoğunlukla yarıda kalır veya yeni sorunlar üretir.
Müşteri olarak ne yapabilirsiniz?
"Hızlı bitsin" baskısı teknik borç biriktirir. Bir hafta daha süren ama doğru yapılan iş, ileride 3 haftalık düzeltmeden daha ucuza mal olur. Yazılım ekibinizle teknik borcu konuşmak bir lüks değil — uzun vadeli bakım maliyetini doğrudan etkileyen bir tartışma.