Teknik borçlar ortaya çıkıyor
Yazılımın geliştirilmesi için neredeyse hiçbir metafor “teknik borçtan” daha önemli değildir. Ama maalesef bazı zayıflıkları var. Her şeyden önce, takımlar genellikle bilinçli olarak borca girmezler.
Kullanıcılar veya Proje Yöneticisi, kodun kalitesinin ne kadar iyi olduğunu neredeyse hiç göremiyor. Sonuçta, yalnızca geliştiriciler kodun özellikle değiştirilip değiştirilmeyeceğini not eder. Ne yazık ki, kaliteli oyun tehlikelidir, çünkü aşırı durumlarda düşük kalite tam bir proje getirir. Bir metafor olarak, teknik borçlar kalite ile ilgili sorunu daha fazla taşımalıdır. Bu şekilde, kullanıcılar veya proje yöneticileri her özelliğin neden hızlı bir şekilde uygulanmaması gerektiğini daha iyi anlayabilir.
Wikipedia
Wikipedia teknik borçları aşağıdaki gibi tanımlamaktadır: Kalite kodu dikkate alınmadan hemen üretimde bir yazılım projesini içeren bir ekip. Ancak ekip borçlar oluşturuyor. Tıpkı parasal borçlarda olduğu gibi faiz ödenmelidir: verimlilik azalır, çünkü kodun düşük kalitesi ekibi kesintiye uğratır. Bu açıklama metafora iyi uyum sağlar: Bir kredi alırsanız, biraz daha hızlı satın almak için borçlar oluşturun ve borçları daha sonra faizlerle geri ödemeniz gerekir.
Ward Cunningham
Ward Cunningham başlangıçta 1992 yılında Oopla Konferansı'ndan teknik borçlar metaforunu tanıttı. Terim YouTube'da farklı açıklıyor: Kod, yazılım tarafından çözülen sorunun mevcut anlayışını her zaman temsil ediyor. Ekip yeni öğrendiğinde, kod yeniden düzenleme ile pekiştirilmelidir, böylece öğrenilenler en uygun şekilde temsil edilir. Yeniden yeniden düzenleme başarısız olursa, teknik borçlar ortaya çıkar ve kodun değiştirilmesi daha zordur. Cunningham, ekibin kaliteden ödün verdiğini ve Wikipedia makalesiyle açıkça çeliştiğini açıkça dışlıyor. Ekip borçlar inşa etmiyor, ancak borçlar istemsiz olarak türetiliyor.
Martin Fowler
Martin Fowler'ın farklı bir perspektifi var: ya proje özenli (ihtiyatlı) ve kalite konusunda kararlar veriyor ya da kaliteye dikkat etmeyen çok acımasız (pervasız). Buna ek olarak, ekip (kasıtlı) kalite veya teknik borçların uzlaşması istemsiz (istemsiz) ortaya çıkar. Dört kadran, bakım ile/ bir tarafta bir karayolu olmadan, diğer tarafta habant/ istemsiz olarak elde eder. Wikipedia'nın tanımı dikkatle/bilinçli olarak karşılık gelir: ekip kaliteyi (dikkatlice) bilir ve kasıtlı olarak bir kalite uzlaşmasına girme kararı alır. Cunningham'ın açıklaması, ekip kaliteyi bildiği için beklenir, ancak teknik borçlar bilinçli olarak türetmez, ancak istemsiz olarak ekip öğrendikleri ve kod henüz öğrendiklerini açıklamadığı için.
Bence başka bir teknik borç kaynağı var: teknik ilerleme. Yeni mimariler ve teknolojiler eski prosedürü eski haline getiriyor. Kod uygun şekilde güncellenmezse, teknik borçlar meydana gelir. Bu da kasıtlı değildir çünkü önlenemez.
Teknik borçlar nasıl yönetilir?
Teknik borçlarla ilgili en önemli şey onlarla yüzleşmek gibidir. Hiçbir sistem mükemmel değildir. Her zaman optimize edilecek bir şey vardır. Bu, ekiplerin pratik olarak sınırsız optimize edebileceği anlamına gelir. Ekip, optimizasyon maliyetlerinden daha fazlasını getiren optimizasyon nedeniyle verimlilikte bir iyileşme beklemiyorsa, optimizasyon atlanmalıdır. Yatırımlar bunun için iyi bir metafor olabilir. Kalite bir hedefin kendisi değil, sadece daha iyi bir üretkenlik aracıdır. Teknik borç metaforunun da bu prosedürde bir avantajı vardır: kalite uzlaşmaları sorunlu olabilir, çünkü kullanıcılar veya proje yöneticileri için tanımak kolay değildir ve projenin durmasına yol açabilir. “Teknik borç” terimi tam olarak bunu temsil eder.
TL; Dr.
Teknik borçlar, bazı farklı zayıflıklara ve yorumlara sahip yazılım projelerinde kalite için bir metafordur. Ancak en önemli şey, takımların teknik borçlarla nasıl karşı karşıya olduğudur.
()