Teknik borç, ölçülebilir tek bir biçimde para kaybettirir: mühendislik kapasitesinin, sistemi genişletmek yerine sistemin etrafından dolaşmaya harcanan payı. Sektör araştırmaları bunu, ciddi borç taşıyan kuruluşlarda geliştirme bütçesinin %20 ile %40'ı arasına koyuyor; Stripe'ın 300'den fazla mühendislik ekibiyle yaptığı çalışma ise geliştiricilerin zamanının yaklaşık üçte birini kötü koda kaybettiğini buldu. Kendi rakamınızı söyleyemiyorsanız işi önceliklendiremezsiniz.
Bu rehber borcun iş diliyle nasıl sayısallaştırılacağını, bütçe görüşmesinde ayakta kalan metrikleri, neyin düzeltileceğinin nasıl önceliklendirileceğini ve kimsenin göremediği bir proje istemeden bunun nasıl finanse edileceğini kapsar.
Önemli noktalar
- Borcun anaparası ve faizi vardır: Düzeltme maliyeti anaparadır; her sprintte kaybedilen kapasite faizdir ve asıl argüman faizdir.
- %15–20'yi ölçüt alın: Ortalama kod tabanları bu kadar borç taşır; girişimler yaygın olarak %25–40; güçlü ekipler %10'un altında kalır.
- Her borç ödenmeye değmez: Emekliye ayıracağınız koddaki borç bedavadır.
- Kalıcı bir tahsisle finanse edin: Kapasitenin sürekli %15–20'si, tek seferlik bir iyileştirme projesinden iyidir.
Teknik borcun ne olduğunu tanımlayın
Teknik borç, bir sistemin nasıl kurulduğu ile bugün bildiklerinizle sıfırdan başlasanız nasıl kuracağınız arasındaki farktır. Bir kısmı bilinçli ve doğruydu, pazarı test etmek için hızlı yayına çıkmak makul bir takastır. Bir kısmı gereksinimler değiştiği, bağımlılıklar eskidiği veya bir kararı anlayan kişiler ayrıldığı için birikti.
"Beğenmediğim kod" değildir. Bu ayrım önemlidir; çünkü mühendislik tercihi ile iş maliyeti farklı argümanlardır ve ikisini karıştırmak bu görüşmelerin tıkanma nedenidir.
Finansal benzetme birebirdir. Anapara, düzeltmenin maliyetidir. Faiz, düzeltene kadar her sprintte ödediğinizdir. Ekipler bu görüşmeleri anaparayı söyleyerek kaybeder; çünkü o bir gider gibi duyulur. Gerekçeyi kuran faizdir.
Üç sayıyla ölçün
Teknik borç oranı. Düzeltme maliyetinin sistemi kurma maliyetine bölümü. %10'luk bir oran, her on saatlik yeni iş için kabaca bir saat düzeltme demektir. Statik analiz araçları bunu otomatik tahmin eder ve mutlak sayıdan çok zaman içindeki yönü önemlidir.
Faiz oranı veya hız vergisi. Bakım saatlerinin toplam geliştirme saatlerine bölümü, çarpı olağan destek değil borca atfedilen pay. Bu, ekibinizin alamadığınız yüzdesidir.
Değişiklik hata oranı ve teslim süresi. Bir sürümün ne sıklıkla olaya yol açtığı ve küçük bir değişikliğin talepten üretime ne kadar sürdüğü. Borç biriktikçe ikisi de bozulur ve ikisi de çoğu ekipte yeni araç gerektirmeden zaten ölçülebilir.
| Ölçüt | Rakam | Karşılaştırma kaynağı |
|---|---|---|
| Ortalama kod tabanı borcu | %15–20 | Sektör kod kalitesi analizleri |
| Girişim kod tabanları | %25–40 | Hız, yapıya karşı bilinçli takas edilmiş |
| Güçlü mühendislik kuruluşları | %10'un altı | Sürekli yatırım |
| Kötü koda kaybedilen geliştirici zamanı | ~%33 | Stripe, 300+ ekip |
| Borca giden geliştirme bütçesi | %20–40 | McKinsey, ciddi borcu olan kuruluşlar |
| Aylık mühendis başına borç zamanı | 2–5 gün | Mühendislik bütçesinin dörtte birine kadar |
Bunlardan iki üçünü çeyreklik izlemek yeterlidir. Kendisi bir projeye dönüşen ölçüm programı başarısız olmuştur.
Yönetim kurulunun anlayacağı bir cümleye çevirin
"Teknik borç oranımız %22" kimseyi harekete geçirmez. Çevirisi şudur: altı mühendisimiz var, mevcut sisteme zamanlarının kabaca üçte birini kaybediyoruz, bu iki mühendisin maaşı kadar hiçbir şey üretmeyen kapasite demek ve mart ayında sorduğunuz sürümün hâlâ çıkmamış olmasının nedeni bu.
İşin zaten fark ettiği gecikmeye bağlayın. Borç, kod kalitesi sorunu olarak anlatıldığında değil, kayan bir taahhüde bağlandığı anda finanse edilebilir hale gelir.
Değişikliğin gerçekte olduğu yere göre önceliklendirin
Borcun çoğu zararsızdır. Çalışan, dokunulmayan ve değişmeyecek kod, nasıl yazıldığından bağımsız olarak size hiçbir şeye mal olmaz.
Borcu şu ölçütlerle sıralayın: o alandaki değişiklik sıklığı, desteklediği işin değeri, olay geçmişi ve düzeltme maliyeti. Yüksek değişimli, yüksek değerli, kötü sağlıklı alanlar iyileştirmenin karşılığını verdiği yerlerdir. Kimsenin düzenlemediği kararlı kod, ne kadar itici görünürse görünsün bırakılmalıdır.
Pratik filtre: son altı ayda en çok değişen dosyalara bakın ve olayların kaynaklandığı yerlerle kesiştirin. O kesişim listenizdir.
Hangi borcun ödenmeye değmediğini bilin
- Bir yıl içinde emekliye ayırmayı planladığınız sistemdeki kod
- İki yıldır düzenlenmemiş ve olaya yol açmayan modüller
- Düzeltme maliyetinin kalan ömür değerini aştığı her şey
- Başka nedenlerle yeniden inşa edilecek bir alandaki borç
Bunu açıkça söylemek, önemli olan kalemler için güvenilirlik kazandırır. Bir kod tabanındaki her yanlışın listesi plan değil şikâyettir.
Proje olarak değil kapasite olarak finanse edin
İyileştirme projeleri öngörülebilir biçimde başarısız olur. Özelliklerle yarışır, ilk ticari baskıda önceliği düşer ve çalışırken görünür hiçbir şey üretmez.
İşe yarayan yaklaşım kalıcı bir tahsistir, yaygın olarak her sprintin %15–20'si, önceliklendirmenin belirlediği alanlara harcanır. Ayrı onay gerektirmez, sürekli iyileşme üretir ve tartışmanın her çeyrek yinelenmesini durdurur.
Buna, yeni işin dokunduğu alanı bulduğundan kötü bırakmaması kuralını ekleyin. Borcun çoğu küçük tavizlerle birikir ve çoğu aynı yolla önlenebilir.
Yaratmak üzere olduğunuz borcu önleyin
Bazı borçlar bilinçli ve sağlam bir takastır. Hata, onu kaydetmeden almaktır.
Bir kestirme seçildiğinde ne yapıldığını, nedenini, geri almanın maliyetini ve yeniden ele almayı tetiklemesi gereken koşulu yazın. Belgelenmemiş kestirmeler kalıcılaşır; çünkü gerekçe, kararı veren kişiyle birlikte gider.
En büyük önlenebilir kaynak belirsiz gereksinimlerdir. Yazılım kuralları kodlar; kurallar hiç netleşmediyse kod bir tahmini kodlar ve sonraki her değişiklik onun etrafından dolaşır. Kararsız bir süreci geliştirmeden önce standartlaştırmak, kod düzeyindeki her disiplinden fazla tasarruf sağlar.
Sinirlenince değil takvimle gözden geçirin
Borcu, her seferinde aynı üç sayıyla çeyreklik incelemeye koyun. Teslimat kararlıyken yükselen oran katlanılabilir; teslim süresi uzarken yükselen oran harekete geçme sinyalidir.
Bunu takvime bağlamak iki başarısızlık biçimini önler: yeniden yazım kaçınılmaz hissettirene kadar hiç ele almamak ve işin gerçekte zaman kaybettiği yerde değil bir mühendisin en sinirli olduğu anda ele almak.
İlgili rehberler
- Teknik Borç: İş Riskleri, Örnekler ve Önceliklendirme rehberinin yanında Yapay Zeka İş Akışı Otomasyonu: Kullanım Alanları ve Riskler.
- Teknik Borç: İş Riskleri, Örnekler ve Önceliklendirme rehberinin yanında Özel Yönetim Panosu Geliştirme: Metrikten Aksiyona.
Teknik Borç: İş Riskleri, Örnekler ve Önceliklendirme rehberinden doğan çalışma; ürün stratejisi, tasarım, geliştirme veya entegrasyon desteği gerektiren somut bir girişime dönüşürse Modernizasyon Planınızı Konuşalım.
Ali Boran Gazel