Teknik borç, bugün hız kazanmak için alınan kısa yolların ileride ödenecek bedelidir. Tıpkı finansal borç gibi; doğru kullanıldığında işi hızlandırır, kontrolsüz büyüdüğünde ise faizini ödemekten asıl işe vakit kalmaz.
Faiz nasıl ödenir?
Teknik borcun faizi, her yeni değişiklikte harcanan ek zamandır:
- Basit bir alan eklemek için on dosyaya dokunmak
- Her sürümde aynı modülde hata çıkması
- Yeni bir geliştiricinin kodu anlamasının haftalar sürmesi
- "Oraya dokunma, bozulur" denilen bölgeler
Teknik borç türleri
| Tür | Örnek |
|---|---|
| Bilinçli ve mantıklı | "Fuar haftasına yetişsin, sonra düzenleriz" |
| Bilinçli ve pervasız | "Test yazacak vaktimiz yok" (her zaman) |
| Bilinçsiz | Ekip daha iyi bir yolu bilmiyordu |
| Zamanla oluşan | Kullanılan kütüphanenin desteği bitti |
Bilinçli ve kayıt altına alınmış borç sağlıklıdır. Asıl tehlike, varlığından haberdar olunmayan veya hiç ödenmeyen borçtur.
Belirtiler
- Tahminlerin sürekli tutmaması
- Hata oranının sürümden sürüme artması
- Güncellenmemiş, desteği bitmiş bağımlılıklar (sürüm yönetimi)
- Otomatik testlerin olmaması veya güvenilmez olması
- Dokümantasyonun sadece bir kişinin kafasında olması
Nasıl yönetilir?
- Görünür kılın. Borçları bir listede tutun: ne, nerede, etkisi ne, tahmini maliyet.
- Etkiye göre önceliklendirin. En sık değişen ve en çok hata üreten bölgeler önce.
- Düzenli ödeyin. Her iş döngüsünün belirli bir payını iyileştirmeye ayırmak, büyük "temizlik projelerinden" daha etkilidir.
- İzci kuralı: Dokunduğunuz kodu bulduğunuzdan biraz daha iyi bırakın. Bkz. refactoring.
- Yeni borcu kontrol edin. Code review ve otomatik kontroller, gereksiz borcun oluşmasını engeller.
Yöneticiye nasıl anlatılır?
Teknik terimler yerine iş etkisiyle konuşun:
- "Bu modül yüzünden kampanya değişiklikleri üç kat uzun sürüyor."
- "Desteği biten bu bileşen güvenlik yaması almıyor."
- "İki haftalık iyileştirme, sonraki her özellikte birkaç gün kazandıracak."
Rakamlar tahmini bile olsa, borcun görünür bir bedeli olduğunu göstermek karar almayı kolaylaştırır. Yazılım satın alan işletmeler için de teknik borç, bakım ve destek sözleşmesinde konuşulması gereken bir konudur.
Sık sorulan sorular
Teknik borç tamamen sıfırlanabilir mi?
Hayır ve gerekmez. Amaç borcu sıfırlamak değil, faizini kontrol edilebilir seviyede tutmaktır.
Hızlı bir MVP teknik borç yaratır mı?
Evet ve bu çoğu zaman doğru bir karardır. Önemli olan, ürün tutunduğunda bu borcu ödeme planının olmasıdır. Bkz. MVP nedir.
Sonuç
Teknik borç kaçınılmazdır; yönetilmeyen teknik borç ise pahalıdır. Borcu görünür kılmak, düzenli ödemek ve iş diliyle anlatmak, yazılımın yıllar içinde hızını korumasını sağlar.
