Teknik Borç (Technical Debt) Nedir?
Kısa tanım
Teknik borç (technical debt), yazılımda bugün daha hızlı ilerlemek için seçilen kestirme veya yetersiz çözümlerin, sonraki her değişikliği yavaşlatan ve pahalılaştıran birikmiş maliyetidir. Kavram Ward Cunningham'ın finans benzetmesine dayanır: borcun anaparası sorunu düzeltmek için gereken iş, faizi ise düzeltilmediği sürece her yeni özellikte harcanan fazladan emektir. Bilinçli alınan borç bir araç olabilir; fark edilmeyen borç projeyi zamanla kilitler.
Diğer adları: technical debt, tech debt, kod borcu, legacy kod
Anapara ve faiz
Ward Cunningham benzetmeyi 1992'de, ekibinin finans yazılımını yöneticilere anlatırken kullandı: ilk sürümü hızla yayına almak borç almaya benzer; kod, öğrendiklerinizi yansıtacak şekilde yeniden düzenlenmedikçe borç ödenmemiş kalır. Benzetmenin gücü iki kavramı ayırmasındadır:
- Anapara: Sorunlu kısmı düzeltmenin tek seferlik maliyeti. Örneğin üç farklı yerde kopyalanmış fiyat hesaplama mantığını tek bir modülde toplamak.
- Faiz: Düzeltme yapılmadıkça her değişiklikte ödenen ek bedel. Fiyat kuralı her değiştiğinde üç yeri bulmak, üçünü de güncellemek ve birini unutunca ortaya çıkan hatayı aramak.
Faizin önemli bir özelliği vardır: yalnızca o koda dokunulduğunda ödenir. Hiç değişmeyen, sorunsuz çalışan eski bir modüldeki çirkin kod, pratikte neredeyse hiç faiz üretmez.
Borç nereden birikir?
- Teslim tarihine yetişmek için atlanan testler ve “şimdilik böyle kalsın” çözümleri.
- Yıllardır güncellenmemiş bağımlılıklar ve desteği biten çatı sürümleri.
- İlk günün ihtiyacına göre kurulmuş, artık ürünün büyüklüğünü kaldırmayan mimari kararlar.
- Kopyala-yapıştır ile çoğalan kod, belgelenmemiş iş kuralları, yalnızca tek bir kişinin bildiği kurulum adımları.
- Gereksinimlerin değişmesi: dün doğru olan model, bugünün iş süreciyle uyuşmuyor olabilir. Bu borç kimsenin hatası değildir, ama yine de birikir.
Her hata teknik borç değildir. Yanlış hesaplanan bir indirim bir bug'dır; o indirimi düzeltmenin üç gün sürmesine yol açan karmaşık yapı ise borçtur.
Bilinçli ve kazara borç
Martin Fowler'ın sık kullanılan sınıflandırması borcu iki eksende ele alır: bilerek mi alındı, ve alınırken ihtiyatlı mı davranıldı?
| Pervasız | İhtiyatlı | |
|---|---|---|
| Bilinçli | “Tasarıma vaktimiz yok, sonra bakarız.” | “Fuara yetişmek için bunu böyle yayınlıyoruz, sonuçlarını biliyoruz ve sonraki ay düzelteceğiz.” |
| Kazara | Ekip iyi yapıyı bilmediği için ortaya çıkan karmaşa. | “Şimdi anlıyoruz ki bu modülü baştan böyle kurmalıydık.” |
İhtiyatlı ve bilinçli borç meşru bir iş kararıdır; bir MVP'de pazarı hızla test etmek için kalıcı olmayacağı bilinen kod yazmak bunun tipik örneğidir. Sorun, o kararın kayda geçirilmemesi ve “sonra”nın hiç gelmemesidir.
Borcu görünür kılmak
Teknik borç tek bir sayıyla ölçülemez; statik analiz araçlarının verdiği puanlar ancak bir kısmını yakalar. Daha güvenilir işaretler süreçte görünür:
- Benzer büyüklükteki işlerin teslim süresi aydan aya uzuyor.
- Hatalar hep aynı birkaç modülde çıkıyor.
- Ekip belirli dosyalara dokunmaktan çekiniyor ya da yeni katılan geliştiricinin ortamı kurması günler sürüyor.
- Her yayın sonrası elle müdahale gerekiyor.
Fark edilen borcu iş listesine, faizini anlatan somut bir cümleyle kaydetmek (“Fiyat mantığı üç yerde; her kampanya değişikliği yaklaşık bir gün ekliyor”) iş tarafıyla önceliklendirme konuşmasını mümkün kılar.
Borcu ödemenin yolları
- Dokunduğun yeri iyileştir: Bir modülde zaten çalışılıyorsa, o fırsatta küçük bir temizlik yapmak en ucuz ödemedir. Pull request incelemeleri bu küçük adımları takip etmek için doğal bir yerdir.
- Kapasiteden pay ayır: Her iterasyonun sabit bir kısmını borç kalemlerine ayırmak, borcun “hiç vakit olmayan” iş olarak kalmasını önler.
- Önce testler: Davranışı koruyan birim testleri olmadan yapılan büyük düzenlemeler, borcu yeni hatalara çevirebilir.
- Baştan yazmaya temkinli yaklaş: Sıfırdan yeniden yazım cazip görünür, ama eski sistemdeki belgelenmemiş iş kurallarını kaybetme riski taşır. Parçaları adım adım değiştirmek çoğu zaman daha güvenlidir.
Her borcun ödenmesi de gerekmez. Yakında kaldırılacak bir özellik veya hiç değişmeyen kararlı bir bileşen için temizlik yapmak, faizi olmayan bir borcu kapatmaya çalışmaktır.