Teknik Borç
- İngilizcesi
- Technical Debt
- Okunuşu
- teknikıl det
Günlük kullanımda iki ad da yaygın.
Kısaca
Teknik borç, daha uzun sürecek daha iyi bir yaklaşım yerine şimdi hızlı ya da sınırlı bir çözüm seçilmesiyle doğan, gelecekteki ek iş maliyetidir.
Teknik borç nedir?
Teknik borç, bir yazılım sistemini zamanla değiştirmesi daha zor hâle getiren kestirmeleri, eskimiş tasarımları ve dağınık kodu anlatır. Terimi, bu kestirmeleri finansal borca benzeten programcı Ward Cunningham ortaya atmıştır. Tıpkı bir kredi gibi ekibin bugün daha hızlı ilerlemesini sağlar ama daha sonra ödenmesi gerekir.
Teknik borcun faizi, gelecekteki her değişikliğin maliyetine eklenen fazladan zamandır. Tekrarlanan kodun birçok yerde düzeltilmesi gerekir, eksik testler her sürümü riskli kılar ve eskimiş bağımlılıklar güvenlik güncellemelerini engeller. Borç hiç ödenmezse faiz büyümeye devam eder ve sonunda küçük özellikler bile haftalar sürer.
Her teknik borç kötü değildir. Bir lansman tarihini yakalamak için sonradan temizleme planıyla bilinçli olarak borçlanmak, sağlam bir iş kararı olabilir. Asıl sorun; aceleyle yapılan işler, belirsiz gereksinimler ya da sistemin ve araçların yaşlanması yüzünden birikip gelen pervasız ya da fark edilmeyen borçtur.
Teknik borç, hata (bug) ile aynı şey değildir. Hata yanlış davranıştır; teknik borç ise çalışan ama olması gerekenden daha zor anlaşılan ya da değiştirilen koddur. Ekipler bunu refactoring, test ekleme, bağımlılıkları yükseltme ve düzenli bakım için zaman ayırma yoluyla öder.
Önemli noktalar
- Teknik borç, bugün alınan kestirmelerin gelecekteki maliyetidir.
- Faizi, gelecekteki her değişikliğin gerektirdiği ek çabadır.
- Bilinçli ve takip edilen borç makul bir ödün olabilir.
- Refactoring, testler ve yükseltmeler ekiplerin borcu ödeme yollarıdır.
Örnek
// TODO: temporary shortcut for launch; replace with per-country tax rules
function getTax(price) {
return price * 0.2; // hard-coded rate: works today, costly once we sell abroad
}Sık sorulan sorular
Teknik borca ne yol açar?
Yaygın nedenler arasında sıkışık teslim tarihleri, belirsiz ya da değişen gereksinimler, eksik testler, dokümantasyon eksikliği ve hiç güncellenmeyen bağımlılıklar bulunur. Teknoloji ve iş ihtiyaçları zamanla değiştikçe bir kısım borç doğal olarak da ortaya çıkar.
Teknik borç nasıl azaltılır?
Diğer işler gibi takip ederek görünür kılın, ardından refactoring, test ekleme ve bağımlılıkları yükseltme yoluyla kademeli olarak ödeyin. Birçok ekip her geliştirme döngüsünün sabit bir bölümünü buna ayırır.
Teknik borç her zaman kötü müdür?
Hayır. Önemli bir teslim tarihini yakalamak gibi iyi bir gerekçeyle bilinçli olarak alınan borç, takip edildiği ve maliyeti fazla büyümeden ödendiği sürece faydalı olabilir.
İlgili sayfalar
- RefactoringYazılım Mimarisi, s. 32Refactoring, mevcut kodun dışarıdan görünen davranışını değiştirmeden daha temiz ve bakımı kolay hâle getirmek için yeniden yapılandırılması sürecidir.
- SOLIDYazılım Mimarisi, s. 39SOLID, geliştiricilerin daha anlaşılır, genişletilebilir, test edilebilir ve bakımı kolay kod yazmasına yardım eden beş nesne yönelimli tasarım ilkesidir.
- Tasarım DeseniYazılım Mimarisi, s. 42Tasarım deseni, yazılım tasarımında sık görülen bir soruna kanıtlanmış, yeniden kullanılabilir çözümdür; hazır kod değil, genel bir şablon olarak anlatılır.
- MonolitYazılım Mimarisi, s. 25Monolit, tek parça olarak derlenip dağıtılan, tüm özelliklerin tek kod tabanını, tek süreci ve çoğunlukla tek veritabanını paylaştığı yazılım uygulamasıdır.
- CI/CDDevOps ve Bulut, s. 9CI/CD, kod değişikliklerini sık sık derleyen, test eden ve yayınlayan otomatik pratikler bütünüdür; yazılım kullanıcılara hızlı ve güvenli biçimde ulaşır.
- Code SmellEkipler ve Süreç, s. 6Code smell (kod kokusu), kod hâlâ çalışsa bile çoğu zaman daha derin bir tasarım sorununa işaret eden yüzeysel bir belirtidir.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin