Teknik Borç Yönetimi

Teknik Borcun Maliyeti Nasıl Hesaplanır

Teknik borç sezgisel bir kavram olarak kalsaydı önceliklendirme hep ertelenirdi; ancak maliyet hesaplaması yapılabildiğinde tartışma somutlaşır. SonarQube, kod tabanını analiz eder ve her tespit ettiği sorun için "remediation cost" hesaplar; varsayılan oranı saat başına 14 USD'dır. 500 saatlik remediation cost, koda dokunmak giderek yavaşladığı bir noktada 7.000 USD değer olarak raporlanır ve ekibin bu sayıyı sprint planlamasına taşıması gerekir.

Gecikilen her haftanın ek maliyet ürettiğini gösteren başka bir ölçüm yöntemi de geliştirici zamanının takibidir. Yeni özellik eklemek veya bir hatayı düzeltmek için "ilgisiz" kod bloklarına dokunmak zorunda kalan mühendislerin harcadığı fazla zamanı kayıt altına alın; bu veri birkaç sprint içinde birikerek teknik borcun gerçek iş yavaşlatma maliyetini gösterir ve yönetim kuruluna veya yatırımcıya sunulabilecek bir argüman haline gelir.

Refactor vs Yeni Feature Tradeoff

Martin Fowler'ın teknik borç dörtlüsü bu tradeoff'u çerçeveler. Deliberate (bilinçli) borç, ekibin kısayolu bilerek tercih ettiği durumdur; "bunu şimdi hızlı yapalım, sonra düzeltiriz" kararıdır. Inadvertent (farkında olmadan) borç, tasarım hatalarının fark edilmeden biriktiği durumdur. Bu iki eksen reckless (pervasız) ve prudent (tedbirli) olarak da ayrılır; en kabul edilebilir borç deliberate + prudent olanıdır: "bunu bilerek yaptık ve ne zaman düzelteceğimizi biliyoruz."

Refactor kararı vermek için Kent Beck'in "rule of three" ilkesi pratik bir tetikleyicidir: aynı koda üç farklı bağlamda dokunulduğunda soyutlama zamanı gelmiştir. Birinci seferinde yaz, ikinci seferinde not al, üçüncü seferinde refactor et. Bu kural sübjektif "bence temizlenmeli" tartışmasının önüne geçer ve refactor kararını nesnel bir gözlem noktasına bağlar.

Mühendislik Saatlerini Koruma

Sprint kapasitesinin %20'sini teknik borç ödemesine ayırma yaklaşımı Google ve Atlassian gibi şirketler tarafından benimsenmiş bir oran olarak sıkça referans alınıyor. Bu oran 10 günlük bir sprint için 2 tam günü teknik iyileştirmelere ayırmak anlamına gelir. Pratikte bu 2 günü "özellik yoksa dolduruyoruz" şeklinde değil, sprint başından itibaren rezerve etmek gerekir; aksi halde her sprint yeni özellikle dolup teknik borç ödeme zamanı ötelenmeye devam eder.

"Boy scout rule" adıyla bilinen pratiği ekiple ilke olarak benimsemek uzun vadede önemli bir etki yaratır: her commit'te bıraktığınız kodu bulduğunuzdan biraz daha temiz bırakın. Bu ilke büyük refactor oturumu planlamayı beklemeden küçük iyileştirmelerin sürekli akmasını sağlar. Stripe'ın araştırması, teknik borcun yüksek olduğu ekiplerde mühendis ciro oranının (turnover) iki katına çıktığını gösteriyor; bu bulgu teknik borç yönetiminin yalnızca hız değil, ekip sağlığı meselesi olduğunu somutlaştırır.

Borç Envanteri Tutmak

Teknik borç envanteri, kod tabanındaki bilinen sorunların, bunların yaratacağı gecikmelerin ve ne zaman ele alınması gerektiğinin kayıt altına alındığı bir belgedir. Bu belge backlog'dan ayrı tutulur; bir sorun hem backlog'da hem envanterde yer alabilir ama iki ayrı amaç için mevcuttur. Envanterde her kalem şu dört bilgiyi içermelidir: sorunun konumu (dosya veya servis), iş üzerindeki somut etkisi, tahmini düzeltme süresi ve öncelik sırası.

Envanteri oluşturmanın hızlı yolu, mühendis ekibine "en çok hangi koda dokunmaktan kaçınıyorsunuz ve neden?" sorusunu sormaktır; bu soru genellikle birkaç dakikada uzun bir liste üretir. Envanteri haftalık gözden geçirmek yerine sprint kapanışlarında 15 dakika ayırarak güncel tutmak sürdürülebilir bir ritim sağlar. SonarQube raporuyla bu manuel envanteri birleştirmek, hem araçsal hem insani perspektifi birleştirir ve teknik borç yönetimini reaktif değil proaktif bir pratik haline getirir.

Sık Sorulan Sorular

SonarQube ücretsiz mi? SonarQube Community Edition ücretsiz ve açık kaynaklıdır; SonarCloud ise küçük açık kaynak projeler için ücretsiz, ticari kullanım için ücretlidir.

Teknik borç ne zaman "kabul edilemez" düzeye ulaşır? Yeni özellik geliştirme hızının belirgin biçimde yavaşlaması, hata oranının artması veya onboarding süresinin uzaması pratik alarm sinyalleridir; bu üç belirtinin birlikte görülmesi acil bir refactoring döngüsünü işaret eder.

%20 kuralı küçük ekiplerde de uygulanabilir mi? Evet. 2 kişilik bir ekipte bu oran 2 günlük sprint için yaklaşık 5 saat anlamına gelir; küçük ekiplerde oran esnekleştirilebilir ancak sıfıra çekmek borcun birikmesine zemin hazırlar.

Boy scout rule kimden gelir? Robert C. Martin'in (Uncle Bob) "Clean Code" kitabından alınan bir metafordur: askerlerin kampı bulduklarından temiz bırakma geleneğine atıf yapar.

Refactoring sırasında test yazılmalı mı? Evet. Refactoring öncesinde varsa mevcut testlerin geçtiğini teyit edin; yoksa önce mevcut davranışı kapsayan testler yazın ve ardından refactoring yapın. Bu sıralama gerilemeden (regression) korunmanın temel güvencesidir.