Teknik Borç: Ne Zaman Ödemeli, Ne Zaman Taşımalı?
Her teknik borç kötü değildir. Bilinçli alınan borç hız kazandırır; unutulan borç projeyi durdurur.
Görsel: Pixabay · Pixabay Lisansı
Tanım
Teknik borç, hızlı ilerlemek için bilinçli olarak alınan kestirmelerdir. Finansal borç gibi faiz öder: her yeni özellik biraz daha yavaş gelir.
Bilinçsiz alınan kestirmeler ise borç değil, hatadır. Aradaki fark, kaydedilmiş olup olmamasıdır.
Ne zaman borç almak doğrudur?
Pazara hızlı çıkmak kritikse ve ürünün tutup tutmayacağı belirsizse.
Bir varsayımı test etmek için geçici çözüm yazmak mantıklıdır; ürün tutmazsa mükemmel kod boşa gitmiş olurdu.
Koşul şudur: borç kayıt altına alınmalı ve ödeme planı olmalıdır.
Ne zaman borç almak yanlıştır?
Güvenlik ve veri bütünlüğü konularında. Bu alanlardaki kestirmeler borç değil, risktir.
Temel veri modelinde. Yanlış kurulmuş veri modeli, üzerine yazılan her şeyi etkiler ve sonradan düzeltmesi en pahalı olandır.
Borç nasıl kaydedilir?
Kodun içine not düşmek yeterli değildir; kimse okumaz.
Borçları görünür bir listede tutun: ne yapıldı, neden yapıldı, düzgün çözümü nedir, ertelemenin maliyeti nedir.
Bu liste, teknik ekiple yönetim arasındaki en faydalı ortak dildir.
Önceliklendirme
Her borcu ödemeye çalışmayın. Sık dokunulan kodu etkileyen borçlar önceliklidir.
Hiç değişmeyen bir modüldeki çirkin kod, günlük olarak geliştirilen bir modüldeki kadar maliyetli değildir.
İkinci ölçüt risk: veri kaybı veya güvenlik ihtimali taşıyan borçlar sıraya girmez, hemen ödenir.
Ödeme yöntemi
Büyük yeniden yazımlar risklidir ve genellikle yarım kalır.
Daha sağlıklı yöntem, dokunulan her alanı biraz iyileştirmektir. Yeni özellik eklerken o bölgeyi temizlemek, ayrı bir temizlik projesinden daha sürdürülebilirdir.
Her sürümde belirli bir kapasiteyi borç ödemeye ayırmak, birikmeyi önler.
Bağımlılık borcu
En sinsi borç türü, güncellenmeyen kütüphanelerdir. İki yıl ertelenen güncelleme, artık küçük bir iş değildir.
Düzenli ve küçük güncellemeler, seyrek ve büyük güncellemelerden kat kat ucuzdur.
Belirtiler
Basit bir değişiklik neden bir hafta sürüyor? Neden herkes belirli bir dosyaya dokunmaktan korkuyor?
Bu sorular teknik borcun faizinin yükseldiğini gösterir ve ödeme zamanının geldiğine işarettir.
Borcu yönetime anlatmak
Teknik borç, teknik olmayan yöneticiler için soyut bir kavramdır. Somutlaştırmak gerekir.
En etkili anlatım süre üzerindendir: bu özellik altı ay önce üç günde yapılırdı, şimdi sekiz gün sürüyor.
İkinci etkili anlatım risk üzerindendir: bu bağımlılık desteklenmiyor, bir güvenlik açığı çıkarsa yama alamayız.
Borç listesini önceliklendirilmiş ve maliyetlendirilmiş halde sunmak, kabul görme olasılığını belirgin biçimde artırır.
Yeniden yazım kararı
Sıfırdan yazma isteği genellikle teknik borcun zirvesinde doğar ve duygusaldır.
Yeniden yazım projelerinin çoğu, eski sistemdeki yazılı olmayan kuralların keşfedilmesiyle uzar ve yarım kalır.
Karar vermeden önce şunu sorun: mevcut sistemde bir yıl boyunca kademeli iyileştirme yapsak nereye geliriz?
Yeniden yazım ancak teknoloji tamamen desteklenmiyorsa veya mimari yeni gereksinimleri kaldıramıyorsa doğru karardır.
Sık sorulanlar
Teknik borç ödemesi için ne kadar kapasite ayrılmalı?
Yaygın bir yaklaşım, her geliştirme döneminin belirli bir bölümünü bu işe ayırmaktır. Oran önemli değildir; düzenli ve kesintisiz olması önemlidir.
Sistemi sıfırdan yazmak çözüm olur mu?
Nadiren. Yeniden yazım projelerinin çoğu, eski sistemdeki yazılı olmayan kuralların keşfedilmesiyle uzar. Kademeli iyileştirme genellikle daha az riskli ve daha hızlıdır.
Teknik borcu tamamen sıfırlamak mümkün mü?
Hayır ve gerekli de değildir. Amaç borcu sıfırlamak değil, faizini yönetilebilir tutmaktır. Sıfır borç hedefi, değer üretmeyen mükemmeliyetçiliğe dönüşür.
