Tanıştığım her mühendislik ekibi teknik borçtan hava durumuymuş gibi söz eder. Bir gecede eski (legacy) kod yağmış, veritabanı şeması taşmış ve şimdi yol haritası su altında kalmış. Kimse bunu seçmemiş; öylece başlarına gelmiş. Bu hikâye rahatlatıcıdır. Aynı zamanda büyük ölçüde yanlıştır.
Gerçek borç, bilerek alınır. Onu şu an ihtiyacınız olan bir şeyi satın almak için alırsınız: bir rakibinizden önce yayına alınan bir özellik, bu çeyrekte kapatılan bir anlaşma, onu "gerektiği gibi" inşa etmek için üç ay beklerseniz kaybedeceğiniz bir pazar. Krediyi almak hata değildir. Onu şartlarını okumadan almak hatadır.
Herkesin alıntıladığı ve yarım hatırladığı metafor
Ward Cunningham "teknik borç" terimini ortaya attığında, özensiz bir işi tanımlamıyordu. Kastettiği şey bilinçli bir takastı: mevcut anlayışınızı yayına alın, gerçek kullanımdan öğrenin, ardından bu anlayış keskinleştikçe yeniden düzenleme (refactor) yapın; anaparayı henüz ucuzken ödeyerek. Borç, bilerek daha hızlı ilerlemek için bir araçtı, karmaşanın eş anlamlısı değil.
Martin Fowler daha sonra bunu dört çeyreğe ayırdı ve bu ayrım hâlâ hakkını veriyor. Borç ya bilinçli ya da farkında olmadandır ve ya basiretli ya da pervasızdır:
- Basiretli ve bilinçli — "Şimdi manuel adaptasyonu yayına al, Q3'te otomatikleştir." Ekinde bir geri ödeme planı olan bir iş kararı.
- Pervasız ve bilinçli — "Testlere zaman yok." Daha sonra cezalandırıcı bir oranla ödeyeceğiniz şartları atlama kararı.
- Basiretli ve farkında olmadan — "Artık canlıda olduğuna göre, onu nasıl modellememiz gerektiğini görüyoruz." Öğrenmenin dürüst bedeli.
- Pervasız ve farkında olmadan — ekip daha iyisini bilecek kadar bilgiye sahip değildi. Bu, borç kılığına girmiş bir işe alım ve mentorluk eksikliğidir.
Bu dördünden yalnızca biri bir kazadır. Diğer üçü birer seçimdir ve seçimler yönetilebilir.
Bazı borçlar her kuruşuna değer
Bir kod tabanını el değmemiş tutma içgüdüsü, güvenmemekte fayda olan bir içgüdüdür. Ekiplerin, asla sözleşme imzalamayan ikinci bir müşteri için bir soyutlamayı genelleştirmekle altı hafta harcadığını gördüm. Bu sırada rakip, çirkin ve sabit kodlanmış (hardcoded) şekilde yayına aldı ve müşterilerin gerçekte ne istediğini öğrendi.
Satın aldığınız şey bilgi olduğunda, bilinçli borç çoğu zaman doğru karardır. Bir özelliğin önemli olup olmayacağını henüz bilmiyorsanız, bunu kanıtlayan en ucuz versiyon sorumlu olan versiyondur; yeter ki neyi atladığınızı yazın. Sabit kodlanmış bir yapılandırma, daha sonra böleceğiniz bir monolit, bir cron betiğiyle taklit ettiğiniz bir iş kuyruğu: birisi senedi imzaladığı sürece hepsi savunulabilir.
Asıl sorun, eksik olan defterdir
Ekipleri batıran borç değildir. Kayıt altına alınmamış borçtur. Kısayolu kullanan kişi ayrıldığında, kısayol ayrılmaz; yalnızca kâğıt izini kaybeder ve "işlerin böyle yürüdüğü hal" olur. Altı ay sonra kimse onun bir zamanlar bir karar olduğunu hatırlamaz, yalnızca o modüle dokunmanın canını yaktığını hatırlar.
Görebildiğiniz borç bir kalemdir. Göremediğiniz borç ise bir sürprizdir; ve sürprizler bileşik faizle büyür.
Onu görünür kılmanın neredeyse hiçbir maliyeti yoktur. Kısa bir borç kaydı tutun; bir sistem değil, bir sayfa. Her kayıt için üç şeyi belirtin: neyi atladığınızı, nedenini ve faiz oranını; yani onun yakınında her çalıştığınızda sizi ne kadar yavaşlattığını. İşte o son rakam, belirsiz bir sızlanmayı önceliklendirilebilir bir maddeye dönüştüren şeydir.
Onu geri ödemek bir portföy kararıdır
İşte çoğu yeniden düzenleme tartışmasının yanlış gittiği nokta burası: kodun kötü olup olmadığını tartışırlar, oysa karşılığını veren tek soru faizin yüksek olup olmadığıdır. Faiz kabaca koda ne sıklıkta dokunduğunuz çarpı her dokunuşun ne kadara mal olduğudur.
- Yoğun trafikli, yüksek sürtünmeli kod — haftalık faiz ödüyorsunuz. Onu yeniden düzenleyin; geri dönüşü hızlı ve nettir.
- Kimsenin dokunmadığı çirkin kod — faiz neredeyse sıfırdır. Onu olduğu gibi bırakın. Estetik anlayışınızı tatmin etmek için soğuk kodu yeniden yazmak, hiçbir şey satın almamak için anapara harcamaktır.
Bu şekilde çerçevelendiğinde, "yeniden düzenleme yapmalı mıyız?" sorusu mühendislik ile ürün arasında bir değerler tartışması olmaktan çıkar ve her iki tarafın da gerçekten yürütebileceği bir rakamlar sohbetine dönüşür.
Pazartesi nereden başlamalı
Bir olgunluk modeline ya da çeyrek boyu süren bir denetime ihtiyacınız yok. Kazaları yeniden kararlara dönüştürmeniz gerekiyor:
- Tek sayfalık bir borç kaydı açın. Onu, herkesin zaten şikâyet ettiği üç şeyle doldurun.
- Her biri için faiz oranını yazın; haftalık, aylık ya da "aslında hiçbir zaman."
- Yalnızca yüksek faizli maddeleri geri ödeyin ve bunu normal özellik çalışmasının içinde yapın; asla onaylanmayan kahramanca bir "yeniden düzenleme sprinti" olarak değil.
- Bilerek yeni bir borç aldığınızda, bunu pull request içinde yüksek sesle söyleyin. Tek cümle: "Son teslim tarihine yetişmek için bu köşeyi kesiyorum; kayıt açıldı."
Teknik borç, disiplinsiz bir ekibin işareti değildir. Sessiz teknik borç öyledir. Yıllarca en hızlı ilerleyen ekipler, hiç borcu olmayanlar değildir; tam olarak ne kadar ve kime borçlu olduklarını her zaman bilenlerdir.
Öyleyse bir sonraki planlama toplantınızda sorulmaya değer soru "teknik borcumuzu nasıl ortadan kaldırırız?" değildir. "Bu borçlardan hangilerini gerçekten biz seçtik ve makbuzu hâlâ bulabilir miyiz?" sorusudur.