Teknik Borç: Yazılımda Biriken Görünmez Maliyet Nasıl Yönetilir?

Merhaba,

Teknik borç kavramını Ward Cunningham 1992'de ortaya attı. Finansal borç gibi birikir ve faiz işler. Küçük kestirme yollar, ertelenen düzeltmeler, geçici çözümler zamanla kodun üzerine çöküyor ve her yeni özellik eklemeyi, her hatayı düzeltmeyi giderek daha pahalı hale getiriyor. Ama bunu yöneticilere ya da ürün sahiplerine anlatmak çoğu zaman çok zor arkadaşlar.

Teknik Borcun Türleri

Tüm teknik borçlar eşit değil. Kasıtlı ve bilinçli alınan borç var: ürünü hızlı çıkarmak için bir kısayol seçildi, sonradan düzeltilmesi planlandı. Bu yönetilebilir bir borç. Kasıtsız borç var: geliştirici iyi niyetle yazdı ama sonradan daha iyi bir yaklaşım öğrendi. Bu da normaldir. Bir de ihmalden kaynaklanan borç var: test yazılmadı, dökümantasyon olmadı, kod review yapılmadı, standartlar görmezden gelindi. Bu tür borç en tehlikeli ve en pahalı olanı. Bunu ayrıştırmak borca yaklaşım stratejisini belirliyor.

Teknik Borç Ne Zaman Krize Döner?

Küçük teknik borç hızı yavaşlatıyor. Büyük teknik borç geliştirmeyi neredeyse durduruyor. Şunlar kritik seviyeye yaklaştığın işaretleri: basit bir değişiklik beklenmedik yerleri kırıyor, yeni geliştirici sistemi anlamak için haftalar harcıyor, test kapsamı düşük olduğu için deployment korkutucu hale geliyor, üretim hataları giderek artıyor ve her düzeltme yeni hata açıyor. Bu noktada borcu ödemeden yeni özellik eklemek giderek daha az verimli hale geliyor. Ama bunu iş paydaşlarına anlatmak teknik dilde değil iş dilinde yapmayı gerektiriyor.

İş Paydaşlarına Nasıl Anlatılır?

Teknik borcu kod kalitesi olarak anlatmak yöneticide karşılık bulmaz. Şöyle anlatın: bugün bir özellik iki sprint alıyor. Altı ay önce bir sprint alıyordu. Bu yavaşlamanın maliyeti aylık şu kadar geliştirici günü. Borcu ödemek için şu kadar sprint ayırırsak hız yüzde otuz iyileşir ve önümüzdeki yıl şu kadar geliştirici günü kazanırız. Somut, ölçülebilir ve iş çıktısıyla ilişkilendirilmiş bir anlatım teknik borcun öncelik almasını kolaylaştırıyor. Görünmez sorunu görünür yapmak yönetimin kararını kolaylaştırıyor.

Teknik Borç Stratejisi

Sıfır teknik borç gerçekçi değil. Hedef borcu sıfırlamak değil yönetilebilir tutmak. Birkaç yaygın strateji var. Boy Scout kuralı: kodu bıraktığınızda bulduğunuzdan biraz daha temiz bırakın. Her PR'da küçük bir iyileştirme zamanla birikinç etkisi yaratıyor. Sprint bütçesi: her sprint'in yüzde on ila yirmi beşini teknik borç ödemesine ayırın. Bu oran tartışmalı ama pek çok ekip sürdürülebilir bulduktan sonra benimsedi. Refactoring yolu: büyük borç alanları tek seferde değil yeni özellikler eklenirken adım adım temizleyin. Tam yeniden yazma son çare olmalı ve yalnızca mevcut sistemin gerçekten yeniden yazılması gereken durumda değerlendirilmeli.

Teknik Borcu Takip Etmek

Görünmez kalan borç yönetilemez. Code smell'leri ve borç alanlarını takip etmek için statik analiz araçları kullanın: SonarQube, CodeClimate ya da Resharper bunların başında geliyor. Tespit edilen sorunları backlog'a ekleyin ve düzenli olarak gözden geçirin. Her üç ayda bir teknik borç değerlendirme toplantısı yapın, hangi borçların kritik olduğuna ve hangisine bu dönem odaklanılacağına karar verin. Borcu belgelemek hem önceliklendirmeyi kolaylaştırıyor hem de ekip içinde ortak bir dil oluşturuyor. Göremediğiniz şeyi yönetemezsiniz.

İyi Günler Dilerim,