Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Ekipler uzun vadeli teknik etkileri yalnız “kod kötü” veya “refactor lazım” diyerek anlattığında neden şimdi yatırım yapılması gerektiği belirsiz kalır.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Technical Debt dili; hangi teknik bağlamın değişikliği zorlaştırdığını, bugün hangi değerin elde edildiğini, ertelemenin hangi tekrarlayan maliyeti yarattığını ve hangi remediation seçeneğinin bulunduğunu aynı karar çerçevesine taşır.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-006'da ekip yeni bir ödeme özelliği ile sık değişen ödeme modülündeki Technical Debt'i karşılaştırıyor. “Kod eski” demek yerine debt item'ı hangi değişikliklerin tekrar tekrar yavaşladığını, hangi hata veya operasyon riskini artırdığını, bekletmenin etkisini ve önerilen remediation scope'unu açıklıyor.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Refinement sırasında kanıt ve bağımlılıklar netleştiriliyor; Product Goal ve mevcut risk bağlamında Backlog order'ı tartışılıyor.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Bu modüle her yeni ödeme tipi eklediğimizde aynı branching mantığını üç yerde değiştiriyoruz. Debt item'ına etkilenen akışları, son üç değişiklikteki tekrar işi ve dar remediation seçeneğini ekleyelim; sonra feature ile order trade-off'unu konuşalım.”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Technical Debt, bug, code smell, refactoring ve legacy ifadelerinin otomatik olarak eş anlamlı olmadığını fark edebilmelisin.
- Açıkla: Kısa vadeli delivery değeri ile gelecekteki değişiklik maliyeti arasındaki debt metaforunu, bunun neden kesin bir finansal ölçü olmadığını anlatabilmelisin.
- Uygula: Somut bir debt item'ında etkilenen alanı, tekrar eden maliyeti, erteleme riskini, kanıtı, remediation seçeneğini ve Owner'ı sorabilmelisin.
- Şimdilik bilmesi gerekmeyen: Organizasyon çapında debt metric sistemi, refactoring portfolio modeli veya sabit kapasite politikası tasarlamak.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Ward Cunningham bu metaforu çalışan yazılımı erken teslim edip gerçek kullanım üzerinden öğrenmenin değerini savunurken kullandı.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
İlk model işe yarayabilir, fakat edinilen anlayış koda geri yansıtılmazsa sonraki her değişiklik not-quite-right yapı üzerinde ek çaba gerektirir. Finansal borç benzetmesi, erken kazanım ile daha sonra ödenen maliyeti teknik olmayan paydaşlarla konuşmaya yardım etti.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler feature delivery ile sistemin değiştirilebilirliği arasındaki trade-off'u görünür kılmak için debt item'ları izleyebilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Bu item'lar Backlog'da başka işlerle birlikte değerlendirilebilir, design veya release review'larında yeniden ele alınabilir ve belirli bir Owner ile remediation stratejisine bağlanabilir. Araç taraması sinyal üretebilir; debt kararının sistem ve iş bağlamını tek başına belirleyemez.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Her debt item'ını hemen çözmek doğru değildir. Az değişen bir alandaki remediation maliyeti beklenen interest'ten yüksek olabilir; hızlı öğrenme gereken yeni bir üründe geçici bir karar bilinçli yatırım olabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Buna karşılık sık değişen kritik bir alandaki görünmez debt her feature'da ek rework ve risk yaratabilir. Karar tek bir skorla değil değer, değişim sıklığı, risk, bağımlılık ve çözüm maliyetiyle yeniden değerlendirilir.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Technical Debt, kötü veya eski kodun başka adıdır.” Yanlış; somut gelecek değişikliği maliyeti ve karar bağlamı açıklanmadan etiket fazla belirsizdir.
- “Debt yalnız bilinçli kısa yol alınca oluşur.” Yanlış; yeni bilgiyle daha iyi tasarımın sonradan anlaşılması gibi inadvertent debt de tartışılabilir.
- “Bütün Technical Debt hemen ödenmelidir.” Yanlış; remediation ile taşımaya devam etme kararı değer, risk ve beklenen maliyete göre değişir.
- “Code quality aracı debt'i kesin para veya gün olarak ölçer.” Yanlış; araç sinyal sağlar, SEI tek genellenebilir metric olmadığını vurgular.
- “Backlog'a debt Ticket'ı açmak borcu yönetmiş olmak demektir.” Eksik; görünürlük başlangıçtır, etki, order, Owner ve remediation takibi gerekir.
- “Her refactoring Technical Debt ödemesidir.” Yanlış; refactoring farklı amaçlarla yapılabilir ve debt code dışındaki design, dependency veya platform kararlarını da içerebilir.
Gerilim ve çözüm1. bölüm