Teknik Borç
Teknik borç, finansal borcun faiz getirmesi gibi, daha sağlam ancak daha yavaş olan çözümler yerine kısa vadeli, pratik tasarım veya uygulama tercihlerinin yapılması durumunda ortaya çıkan gelecekteki maliyeti ifade eden bir metafordur.
Tanım
Teknik borç, daha uzun sürecek daha iyi bir yaklaşım yerine şimdi kolay veya sınırlı bir çözüm seçilmesi nedeniyle ortaya çıkan ek yeniden işleme maliyetinin ima edilen gelecekteki maliyetidir; bu kısayolu aşmak için devam eden ek çaba ise bu borcun faizi olarak kabul edilmektedir.
Kapsam
Bu konu, teknik borç metaforunun kökenlerini ve tanımını; kasıtlı ve kasıtsız, ihtiyatlı ve pervasız borç arasındaki ayrımı; yazılıma uygulanan anapara ve faiz kavramını; borcu tanımlama, ölçme ve önceliklendirme yöntemlerini; ve bir geliştirme süreci içinde borcu yönetme ve geri ödeme stratejilerini kapsamaktadır.
Temel sorular
- Teknik borç olarak ne kabul edilir ve sıradan kusurlardan nasıl farklılaşır?
- Borç üstlenmek, dikkatsizlikten ziyade ne zaman ihtiyatlı bir ödünleşim olarak değerlendirilir?
- Teknik borç nasıl tanımlanabilir, ölçülebilir ve önceliklendirilebilir?
- Özellik teslimatını durdurmadan borcu geri ödeyen stratejiler nelerdir?
Temel kuramlar
- Borç metaforu
- Cunningham, pratik tasarım seçimlerini geleceğe karşı borçlanma olarak çerçevelemiştir: bu seçimler şu anda teslimatı hızlandırmakta ancak borç yeniden düzenleme (refactoring) ile ödenene kadar sonraki her değişiklikte ek çaba olarak faiz biriktirmektedir.
- Kasıtlı ve kasıtsız borç
- Teknik borç, niyet ve ihtiyat eksenleri boyunca kategorize edilmektedir; kasıtlı, ihtiyatlı borç bilinçli bir stratejik ödünleşim iken, kasıtsız veya pervasız borç beceri veya disiplin eksikliğinden kaynaklanmakta ve daha tehlikeli kabul edilmektedir.
Klinik önem
Yönetilmeyen teknik borç, geliştirme süreçlerini yavaşlatmakta, hata oranlarını artırmakta ve nihayetinde bir kod tabanını felç edebilmektedir; borcu görünür kılmak ve kasıtlı olarak yönetmek, ekiplerin kısa vadeli hızı uzun vadeli sürdürülebilirlikle bilinçli bir şekilde dengelemesine olanak tanımaktadır.
Kanıt ve kılavuzlar
SQALE tabanlı borç ölçümü ve statik analiz platformları dahil olmak üzere araştırma girişimleri ve araçları, teknik borcu nicelleştirmek ve izlemek için yöntemler sunmaktadır, ancak tek bir standart yaygın olarak kabul görmemektedir.
Tarihçe
Cunningham, 1992 yılında paydaşlara artımlı tasarım ödünleşimlerini açıklamak için borç metaforunu ortaya atmıştır; bu kavram, 2000'li ve 2010'lu yıllarda çevik geliştirme, özel araştırma seminerleri ve borcu nicelleştirmeyi ve yönetmeyi amaçlayan araçlarla önem kazanmıştır.
Tartışmalar
- Teknik borç faydalı mı yoksa aşırı genişletilmiş bir metafor mu?
- Bazıları, borç metaforunun herhangi bir kod eksikliğine çok gevşek bir şekilde uygulandığını ve anlamını sulandırdığını savunurken, diğerleri bunu ödünleşimler için değerli bir iletişim aracı olarak görmektedir; kesin tanımlar, metaforu uygulanabilir kılmayı amaçlamaktadır.
Öne çıkan isimler
- Ward Cunningham
- Philippe Kruchten
- Ipek Ozkaya
- Robert Nord
İlgili konular
Temel eserler
- cunningham1992
- kruchten2019
- avgeriou2016
Sıkça sorulan sorular
- Tüm teknik borç kötü müdür?
- Hayır. Finansal borç gibi, teknik borç üstlenmek de — örneğin kritik bir son teslim tarihine yetişmek için — bilinçli, görünür ve geri ödenmesi koşuluyla sağlam bir stratejik tercih olabilmektedir; tehlike, sessizce faiz biriktiren kasıtsız veya yönetilmeyen borçta yatmaktadır.
- Teknik borç bir hatadan (bug) nasıl farklıdır?
- Bir hata (bug), kullanıcılara görünen yanlış bir davranıştır; oysa teknik borç, yanlış çıktı üretmek zorunda olmayan ancak gelecekteki değişikliklerin maliyetini ve riskini artıran iç yapısal bir zayıflıktır; ikisi ilişkili olabilse de, ayrı endişe alanlarıdır.