Teknik Borç: Production'da Ne Zaman Temizlik Yapılır?

Her production sisteminin teknik borcu vardır. 1 gün çalışmış bile olsa. Bu kaçınılmaz. Asıl mesele teknik borcu tanımak, önceliklendirmek ve ödemekle ilgili — yoksa bir gün seni büyük bir noktada yakalar.

14 yıllık deneyimde hiç "teknik borçsuz sistem" görmedim. Gördüklerimin hepsinde iyi yönetilmiş teknik borç ve fonksiyonsuz olarak biriktirilmiş teknik borç farkı vardı. Bu yazı ikisinin ayrımını anlatıyor.

Teknik borç nedir, ne değildir

Teknik borç = kısa vadeli hız için bilinçli seçilen, uzun vadeli maliyet üreten teknik kararlar.

Örnekler (borç):

• "Şimdi hızlıca yazalım, sonra refactor ederiz" denen kod
• Test yazmadan merge edilen bir özellik
• Geçici workaround olarak yapılan ama kalıcılaşan şeyler
• Eski versiyonu upgrade edilmemiş kütüphane

Örnek değil (borç değil):

• Bir hata (hata sadece hata, borç değil)
• Yeni bir özellik eklenmesi gereken yer (eksiklik, borç değil)
• Bugün daha iyi yazılabilecek şeyin dün iyi yazılmış hali (retrospektif etrafındaki bilgelik, borç değil)

Bu ayrımı yapmadan "teknik borcumuz çok" demek anlamsız. Her takımda her türden problem vardır — borç ayrı bir kategori.

Teknik borcu kategorize etmek

Teknik borcu iki boyutta düşünüyorum:

1. Ne kadar pahalı yaşamak?

• Her gün acı veriyor mu, yılda bir mi canımızı yakıyor?

2. Düzeltmek ne kadar pahalı?

• Bir öğleden sonra mı, bir sprint mi, aylar mı?

Bu iki boyutu 2x2'ye koyarsanız dört kategori:

"Pahalı yaşar + ucuz düzeltir" → en hızlı ROI burada. Genelde herkesin kaçırdığı nokta. Bir saatlik bir düzeltme her gün 5 dakika veriyorsa, 12 iş günü sonra ödemiş olursun. Acilen yap.

"Ucuz yaşar + pahalı düzeltir" → burada yaşamayı kabul et. 5 yıllık bir refactor planı, hiç acı vermeyen bir koda nereye gideceğinizi asla belirlemez. Ekibi tüketir.

Ne zaman büyük refactor yapılır

Büyük refactor sadece iki durumda mantıklı:

1. Mevcut mimari yeni gereksinimi karşılamıyor

Örneğimiz: on-prem sistemimizin Kubernetes'e geçmesi gerekiyordu çünkü bulut native özellikler (segmentasyon, canary, autoscale) manuel taklitle bitmez haldeydi.

Sebep "eski sistem çirkin" değil, "eski sistem yapmak istediklerimizi destekleyemiyor"du.

2. Güvenlik / risk ciddi hale geldi

Üst versiyondan 3 major desteklenmeyen framework, kritik güvenlik açığı, production'da sıklıkla reproduce olan bir race condition — bunlar büyük refactor'u haklı çıkarır.

"Daha okunabilir kod" için büyük refactor yapmak bir tuzak. O refactor hiç bitmez.

Günlük pratik: küçük refactor'lar

Büyük refactor'lar yılda bir olur. Her gün ise küçük refactor'lar iyi bir pratik:

• Bir feature yazarken o dosyadaki eski kodu temizle
• Duplicate olduğunu gördüğün 2-3 yeri aynılaştır
• Kendi kendine açıklayan isim vermek için 1 dakika harca
• Gereksiz abstraction'ı kaldır (under-engineering kadar over-engineering de borç)

"Boy Scout Rule": Kodu bulduğun halden biraz daha iyi bırak.

Teknik borç sprint'i gerekli mi?

Bazı ekipler "teknik borç sprint'i" yapar — normal işi durdurup bir sprint tamamen temizlik. Bende karışık düşünceler var.

Lehinde: hiç yapılmayacak işleri zorlayarak yaptırır. Geriye kalmış update'leri halletmek için iyi.

Aleyhinde: kendi kendine sürdürülemez. "Haftada bir gün borç gününe ayırmak" gibi sürekli pratikler, sprint patlamalarından daha iyi. Çünkü her geliştirici, her gün, zaten bir ölçüde borç ödüyor olmalı.

Önerim: ayrı sprint yerine, her sprint'te %15-20'lik bir "improvement" ayır. Bu, teknik borç + tooling + dokümantasyon için. Her sprint biraz daha iyiye gider, büyük patlama olmaz.

Ne kaydetmeli, ne kaydetmemeli?

Teknik borç envanteri yapıyorsanız, bir JIRA epic'i açıp 100 bilet içine borç koymayın. %90'ı hiç okunmaz.

Yerine:

• Her büyük servis için bir sayfalık "bilinen borçlar" listesi
• Her biri için: ne, ne zaman eklendi, neden, öncelik, beklenen ödeme maliyeti
• Quarterly (3 aylık) revize edilir — yeniler eklenir, ödenenler silinir, eskimişler yeniden değerlendirilir

Bu basit disiplin, borç konusunda ekibin ortak görüşünü korur. Ekip liderinin sorumluluğu bu sayfa güncel tutmak.

Sonuç

Teknik borç, başarılı bir yazılım işinin normal bir parçası. Borç olmadan yapılan bir sistem ya çok yavaş hareket eder ya da hiç önemli hale gelmez.

Önemli olan borcu bilinçli almak ve bilinçli ödemek. Geri adım atıp ne kadar borcunuz olduğuna, hangi boyutta acı verdiğine bakabilmek gerek. Bunu yapan ekipler teknik borçtan zarar görmez; yapmayan ekipler 3 yıl sonra "her şeyi baştan yazalım" diye yalvararak gelir.

Büyük ya da küçük, borcu gör, tanımla, önceliklendir, öde. Bu basit döngü, yıllar içinde sistemin sağlığını belirler.