Bir yazılım ekibinin takviminde bazen şu cümle belirir: “Şimdilik böyle çıkaralım, sonra düzeltiriz.” Bu cümle masum görünür; hatta çoğu zaman doğrudur. Pazar fırsatı beklemez, müşteri demo ister, kritik bir hata gece yarısı çözülmelidir. Sorun hızlı davranmak değildir. Sorun, hız uğruna alınan kararın gelecekte bir maliyet yaratacağını unutmak ya da bu maliyeti kayda geçirmemektir. İşte bu görünmez yükün adı kalıtsal borçtur: Bugünün kod kolaylığı karşılığında yarının geliştirme kapasitesinden alınan kredi.
Finansal borçla benzetme güçlüdür çünkü teknik borç da faiz işler. Bir fonksiyonun içine sıkıştırılmış iş kuralları, kopyalanmış kod blokları, anlamsız değişken adları, test edilmeyen kritik akışlar veya “geçici” diye eklenmiş ama iki yıldır yaşayan bir yapı… Bunların her biri ilk gün küçük bir tasarruf sağlar. Ancak sistem büyüdükçe yeni özellik eklemek zorlaşır, hata ayıklama uzar ve ekip üyeleri kod tabanına dokunmaktan çekinir. Faiz, sadece işlemci zamanı ya da sunucu faturası değildir; geliştiricinin dikkati, motivasyonu ve güveni de bu faizle aşınır.
Borç Her Zaman Kötü Değildir
Teknik borcu şeytanlaştırmak, yazılım geliştirmeyi laboratuvar sterilitesine hapsetmektir. Kontrollü teknik borç stratejik olabilir. Örneğin yeni bir ürün fikrini doğrulamak için kusursuz, ölçeklenebilir bir mimari kurmak yerine küçük bir prototip çıkarmak mantıklıdır. Henüz müşterinin gerçekten istediği bilinmiyorsa, mükemmelleştirilmiş yanlış çözüm üretmek daha pahalıdır. Buradaki ayrım nettir: Bilinçli borç, neyin eksik bırakıldığını, neden bırakıldığını ve ne zaman ödeneceğini bilir. Bilinçsiz borç ise “çalışıyor” sözcüğünü kalite belgesi sanır.
Bu nedenle ekiplerin teknik borcu görünür kılması gerekir. Bir hata kaydı gibi, borç maddeleri de iş listesinde yer almalıdır: hangi modülde bulunduğu, etkilediği alan, olası risk, tahmini çözüm maliyeti ve önceliği belirtilmelidir. “Sonra bakarız” bir plan değildir. Buna karşılık “ödeme altyapısındaki tekrar eden doğrulama kodu, iki sprint içinde ortak servise taşınacak” somut bir taahhüttür. Borç kayda geçince soyut huzursuzluk, yönetilebilir bir mühendislik problemine dönüşür.
Faizi Nasıl Düşürürsünüz?
İlk araç testtir. Otomatik testler, eski kodu değiştirmeyi korkutucu bir kumar olmaktan çıkarır. İkinci araç küçük ve sürekli refaktörizasyondur. Büyük bir “temizlik haftası” beklemek caziptir; fakat iş baskısı altında bu hafta çoğu zaman hiç gelmez. Bunun yerine her özellik geliştirmesinde dokunulan alanı biraz daha anlaşılır, tekrarları daha az ve sınırları daha net hâle getirmek daha gerçekçidir. İz bırakmadan kamp kurmayan iyi dağcı gibi, iyi geliştirici de değiştirdiği modülü gelişigüzel terk etmez.
Üçüncü araç mimari disiplindir. Modüller arası bağımlılık arttıkça borcun faizi katlanır; çünkü küçük bir değişiklik bütün sistemi titreştirir. Açık arayüzler, sınırlı sorumluluklar, anlamlı isimler ve gözlemlenebilir servisler bu titreşimi azaltır. Kod incelemeleri de burada yalnızca hata avı değildir. İyi bir inceleme, ekibin ortak düşünme biçimini koruyan bir kalite filtresidir.
En kritik mesele kültürdür. Yöneticiler yalnızca teslim tarihini ödüllendirirse ekipler borçlanmaya teşvik edilir. Buna karşılık bakım süresi, hata oranı, dağıtım sıklığı ve değişiklik süresi de başarı ölçütü olmalıdır. Yazılım bir kez üretilen bir nesne değil, yaşayan bir sistemdir. Hızlı yazılan kod bazen günü kurtarır; fakat geleceği kurtarmak için o kodun faizini hesaplamayı, ödeme planı yapmayı ve gerektiğinde borç almamayı öğrenmek gerekir.