Teknik Borç Yönetimi: Refactoring İçin Doğru Zaman
Geçen sene bir haftada eklenen bir özellik bu sene aynı büyüklükte üç haftaya yayılıyorsa, bir yerlerde bir şeyler birikmiş demektir. Biz SUNS Tech olarak farklı ölçekteki projelerde bu tabloyu sık görüyoruz ve neredeyse hiçbir zaman kod kalitesizliğinden kaynaklanmıyor. Zaman baskısıyla alınan küçük kısa yol kararları üst üste bindiğinde ortaya çıkan sonuç bu oluyor.
Teknik borç yönetimi dediğimiz şey, bu kısa yolları görünür kılmak ve hangisinin ne zaman ödeneceğine karar vermekle ilgili. Konuyu soyut bir kavram değil, bir bütçe kararı olarak ele almak gerekir; çünkü her refactoring çalışması, aynı sprintte yapılamayacak başka bir işin yerini alır. Bu yazıda teknik borcu nasıl fark edeceğinizi, hangisinin öncelikli olduğunu ve refactoring sürecini projeyi durdurmadan nasıl yürüteceğinizi somut kriterlerle ele alıyoruz.
Teknik borç nedir, neden her projede birikir
Teknik borç, bir özelliği en doğru şekilde değil en hızlı şekilde teslim etmenin bıraktığı ek maliyettir. Test yazmadan geçilen bir kod parçası, kopyala-yapıştırla çoğaltılan bir fonksiyon, ya da "sonra düzeltiriz" diyerek bırakılan bir veritabanı tasarımı, hepsi bu borcun farklı biçimleri. Borcun kendisi kötü bir şey değil; bazen pazara zamanında girmek için gerçekten doğru karar olabiliyor.
Asıl sorun, borcun fark edilmeden birikmesi. Bir ekip her sprintte küçük kısa yollar alır, hiçbiri tek başına kritik görünmez, ama altı ay sonra kod tabanının herhangi bir yerine dokunmak yan etkilere yol açmaya başlar. Geliştiriciler değişiklik yapmaktan çekinmeye başlar, testler yetersiz kaldığı için her düzeltme yeni bir hataya kapı aralar. Yazılım danışmanlığı taleplerinde sık karşılaştığımız senaryo tam olarak bu: iş büyümüş ama kod tabanı o büyümeye ayak uyduramamış.
Yaygın yanlış inanış: teknik borç sadece eski kod demektir
Birçok ekip teknik borcu yalnızca eski, bakımı zor kodla ilişkilendiriyor. Oysa iki ay önce yazılmış, henüz hiç dokunulmamış bir kod da borç taşıyabilir. Test kapsamı yoksa, dokümantasyonu eksikse veya tek bir kişinin anladığı bir yapıdaysa borç orada da vardır. Teknik borcu yaşına göre değil, değişikliğe ne kadar dirençli olduğuna göre ölçmek daha doğru bir yaklaşım.
Teknik borcu nasıl görünür hale getirirsiniz
Teknik borç yönetiminin ilk adımı, borcu tahmin etmek değil listelemektir. Ekiplerin genellikle üç kaynağa bakması yeterli oluyor: kod inceleme sırasında düşülen "burayı sonra düzeltelim" notları, hata takip sisteminde tekrar eden bug kategorileri ve geliştiricilerin belirli dosyalara dokunmaktan kaçınma eğilimi. Bu üçü bir araya geldiğinde, kod tabanının hangi bölgelerinin riskli olduğu netleşiyor.
Bazı ekipler bunu bir "borç kaydı" olarak tutar: her kalem için kısa bir açıklama, tahmini etki alanı ve ödenmediği takdirde ortaya çıkabilecek risk yazılır. Bu kayıt, ürün yöneticisiyle konuşurken teknik borcu somut bir dille anlatmayı da kolaylaştırıyor. "Bu kısmı refactor etmemiz gerekiyor" demek yerine "bu modülde yapılan her değişiklik test süresini iki katına çıkarıyor" demek, kararı iş tarafına çok daha anlaşılır kılıyor.
Hangi teknik borç önce ödenmeli
Tüm borcu aynı anda ödemeye çalışmak, hiçbirini ödeyememekle sonuçlanır. Öncelik sırası kurarken iki eksene bakmak işe yarar: bu borcun ne sıklıkla değişikliğe engel olduğu ve değişmediği takdirde ne kadar büyük bir hataya yol açabileceği. Sık dokunulan ama düşük riskli bir alan, nadiren dokunulan ama kritik bir alandan farklı bir aciliyet taşır.
- Sık değişen ve hata üretmeye açık kod: öncelik listesinin başında olmalı, çünkü her sprintte tekrar maliyet doğuruyor.
- Nadiren dokunulan ama kritik iş mantığı içeren kod: risk yüksek olsa da acil değildir, planlı bir zaman diliminde ele alınabilir.
- Sık değişen ama düşük riskli kod: geliştirici deneyimini iyileştirir, iş sürekliliğini tehdit etmez.
- Nadiren dokunulan ve düşük riskli kod: genellikle dokunmaya değmez, kaynak burada harcanmamalı.
Bu sınıflandırma yapıldığında, "hangi refactoring bu çeyrekte yapılmalı" sorusu bir tercih meselesi olmaktan çıkıp veriye dayalı bir sıralamaya dönüşüyor.
Refactoring stratejileri: projeyi durdurmadan borç ödemek
Refactoring, mevcut davranışı değiştirmeden kodun iç yapısını iyileştirmek demek. Kullanıcı için görünen hiçbir şey değişmez, ama kodun bakımı ve genişletilmesi kolaylaşır. Bu tanımı net tutmak önemli, çünkü refactoring sırasında yeni özellik eklemeye kalkışmak hem test etmeyi hem de hata ayıklamayı zorlaştırır.
Büyük ölçekli projelerde tek seferde büyük bir refactoring yapmak yerine kademeli bir yaklaşım genellikle daha az riskli sonuç verir. "Boy scout kuralı" denen basit bir prensip burada işe yarıyor: bir dosyaya her dokunduğunuzda, o dosyayı biraz daha iyi bırakın. Ayrı bir refactoring sprinti planlamadan borcu yavaş yavaş azaltmanın pratik bir yolu bu.
Büyük refactoring gerektiren durumlarda dikkat edilecekler
Bazı durumlarda küçük adımlar yetmiyor; veritabanı şeması değişecekse veya bir modülün mimarisi baştan kurulacaksa kademeli yaklaşım işlemez. Bu tür büyük çalışmalarda test kapsamının önceden güçlendirilmesi kritik bir ön koşuldur, çünkü testler olmadan yapılan değişikliğin davranışı bozup bozmadığını anlamanın güvenilir bir yolu kalmaz. Değişikliği küçük, geri alınabilir adımlara bölmek de üretimde bir sorun çıktığında etkiyi sınırlı tutar.
Maliyet ve süre dengesini nasıl kurarsınız
Teknik borç yönetiminde en sık yapılan hata, refactoring için boş bir zaman aralığı bulmayı beklemektir. Böyle bir zaman genellikle gelmiyor, çünkü iş her zaman yeni özellik istiyor. Bunun yerine her sprint kapasitesinin küçük bir kısmını sürekli olarak borç ödemeye ayırmak daha gerçekçi bir model; bu oran projeye göre değişir ama sabit bir oran belirlemek, borcun tekrar kontrolsüz büyümesini önler.
Burada gerçek bir denge kurma meselesi var: sprint kapasitesinin bir kısmını refactoring'e ayırırsanız, aynı dönemde teslim edilecek yeni özellik sayısı azalır. Bunu iş tarafına saklamak yerine açıkça söylemek, ilerideki beklenti yönetimini kolaylaştırır. Kısa vadede daha az özellik, uzun vadede daha öngörülebilir teslim süreleri ve daha az üretim hatası anlamına gelir.
Ekip içinde teknik borç kültürü nasıl kurulur
Teknik borç yönetimi tek bir kişinin sorumluluğunda kalırsa sürdürülemez. Kod inceleme sürecine "bu değişiklik yeni borç ekliyor mu" sorusunu dahil etmek, borcun büyüme hızını yavaşlatan basit ama etkili bir alışkanlık. Mimari kararların belgelenmesi de, yeni katılan geliştiricilerin mevcut borcu tekrar üretmesini önlüyor.
Uzun soluklu projelerde, özellikle outsource ekiplerle veya birden fazla tedarikçiyle çalışılan yapılarda, teknik borcun sorumluluğu belirsizleşebiliyor. Bu riski azaltmak için proje başında kod kalite standartlarını ve refactoring beklentilerini yazılı hale getirmek, ilerideki anlaşmazlıkları büyük ölçüde önler. Ekibimizin hizmetlerimiz kapsamındaki danışmanlık çalışmalarında mevcut kod tabanını değerlendirirken tam olarak bu noktalara bakıyoruz: borcun nerede yoğunlaştığını, hangi kısmının acil olduğunu ve ekibin bunu kendi başına yönetip yönetemeyeceğini.
Bir web projesini sıfırdan kurarken bile bu disiplini baştan tanımlamak işleri kolaylaştırıyor. Web tasarım ve geliştirme süreçlerimizde kod standartlarını proje başında netleştirmek, ileride birikecek borcun önünü büyük ölçüde kesiyor.
İlk adım: bir envanter çıkarmak
Teknik borç yönetimine başlamanın en pratik yolu bir envanterdir: hangi dosyalara en sık dokunuluyor, hangi alanlarda tekrar eden hatalar çıkıyor. Bu envanteri çıkardıktan sonra, sprint kapasitesinin bir kısmını sürekli olarak borç ödemeye ayırmak ve bu kararı iş tarafına açıkça anlatmak, projenin uzun vadede sürdürülebilir kalmasını sağlıyor.
Mevcut kod tabanınızın nerede durduğunu birlikte değerlendirmek isterseniz, teklif al sayfamızdan bize ulaşabilirsiniz.
