Teknik Borç Ne Zaman Gerçek Bir İş Problemine Dönüşür?

Teknik borç, yazılım ekipleriyle iş tarafı arasındaki en sık kullanılan ve en az anlaşılan terimlerden biridir.

Geliştirici tarafında genellikle bir rahatsızlığı anlatır: kod eski, yapı karışık, dokunmak zor. İş tarafında ise çoğu zaman bir erteleme talebi gibi duyulur — şimdi değil, sonra bakarız.

İki taraf da haklı olabilir, çünkü aynı kelimeyi farklı şeyler için kullanmaktadırlar. Terimi yararlı kılmak için metaforu ciddiye almak gerekir: borç, faiz ödediğiniz şeydir.

Faiz ödemiyorsanız, o borç değil

Bir sistemin eski olması tek başına borç anlamına gelmez. On yıllık, kimsenin dokunmadığı, sorunsuz çalışan ve değişmesi de gerekmeyen bir modül teknik borç değildir. Çirkin olabilir; maliyeti yoktur.

Borç, tekrar tekrar ödediğiniz şeydir. Her yeni özellik o alana çarptığında fazladan gün harcanıyorsa, her değişiklikten sonra beklenmedik bir yer bozuluyorsa, ya da o kısmı yalnızca bir kişi güvenle değiştirebiliyorsa faiz işliyordur.

Bu ayrım pratikte çok şeyi değiştirir. "Kod kalitesi düşük" bir estetik yargıdır ve önceliklendirilemez. "Bu modüle dokunan her iş iki kat sürüyor" ölçülebilir bir ifadedir ve bütçelenebilir.

Sonuç olarak doğru soru "borcumuz var mı" değildir — her sistemde vardır. Doğru soru şudur: bu borcun faizini nerede ve ne kadar ödüyoruz?

Faizin göründüğü dört yer

Teknik borç kod okunarak değil, ekibin davranışı izlenerek fark edilir. Genellikle şu dördünden birinde ortaya çıkar.

Teslim süresi. Benzer büyüklükteki işler zamanla uzuyorsa, aradaki fark faizdir. Ekip yavaşlamamıştır; aynı işi yapmak için daha fazla engel aşmaktadır. En görünür belirtisi, tahminlerin sürekli aşılması ve "basit görünüyordu" cümlesinin sıklaşmasıdır.

Hata oranı ve tekrar açılan işler. Bir düzeltmenin başka bir yeri bozması, sistemin parçalarının birbirine beklenenden sıkı bağlı olduğunu gösterir. Aynı hatanın farklı biçimlerde geri dönmesi de aynı sinyaldir.

Kişi bağımlılığı. Bazı alanlara yalnızca belirli bir kişinin dokunabilmesi teknik değil operasyonel bir risktir. O kişi izne çıktığında duran bir iş akışı, kod kalitesinden bağımsız olarak bir borçtur.

Yeni kişinin ilk katkı süresi. Ekibe katılan birinin ilk anlamlı değişikliği yapması haftalar sürüyorsa, sistem kendini anlatmıyordur. Bu ölçüt kolay toplanır ve zamanla karşılaştırılabilir.

Bu dördü, teknik olmayan bir yöneticinin de takip edebileceği ölçütlerdir. Teknik borcu bütçe konuşmasına sokmanın en pratik yolu genellikle budur.

Borcun nasıl oluştuğu da izlenmeye değer. Bir kısmı bilinçlidir: bir tarihe yetişmek için geçici bir çözüm seçilir ve bunun geçici olduğu bilinir. Bu, sağlıklı bir ödünleşmedir — kaydedildiği sürece. Kayıt tutulmadığında aynı çözüm birkaç ay içinde kalıcı sayılır ve üzerine yenileri eklenir. Diğer kısmı ise farkında olmadan birikir; kimse yanlış bir karar vermemiştir, yalnızca sistemin ne hâle geldiğine uzun süre kimse bakmamıştır.

Her borç ödenmez

Borcun tamamını kapatmak bir hedef değildir. Bazı borçlar bilinçli olarak taşınır ve bu doğru karardır.

Belirleyici olan, borcun gelecek işlerin yolunda olup olmadığıdır. Önümüzdeki altı ayda hiç dokunulmayacak bir alandaki karmaşa, faiz üretmez; onu düzeltmek estetik bir tercih olur. Buna karşılık, planlanan üç işin de üzerinden geçeceği bir modüldeki karmaşa her seferinde ödenir.

Pratik yaklaşım, borcu yol haritasının üzerine koymaktır. Sıradaki işler belliyse, hangi borcun onların yolunda durduğu da bellidir. Önceliklendirme o zaman soyut bir "iyileştirme" tartışması olmaktan çıkar.

İkinci ölçüt risktir. Güvenlik güncellemesi almayan bir bağımlılık, yedeği doğrulanmamış bir veri katmanı veya tek kişinin bildiği bir dağıtım süreci, faizden bağımsız olarak ele alınmalıdır; çünkü bunların maliyeti kademeli değil ani gelir.

Bakım borcu ile yapısal borç

Aynı başlık altında toplanan iki farklı şey vardır ve karıştırıldıklarında yanlış işe bütçe ayrılır.

Yapısal borç, sistemin nasıl kurulduğuyla ilgilidir: hatalı bölünmüş sorumluluklar, birbirine fazla bağlı modüller, veriyi doğru temsil etmeyen bir model. Bunu düzeltmek tasarım kararı gerektirir ve genellikle pahalıdır.

Bakım borcu ise ihmalden doğar: güncellenmeyen bağımlılıklar, geride kalmış çalışma zamanı sürümleri, yıllardır elden geçirilmemiş yapılandırma. Bunların hiçbiri kötü tasarımın sonucu değildir. Yalnızca yapılmamıştır.

İkisi arasındaki en önemli fark maliyetin şeklidir. Yapısal borcun maliyeti doğrusaldır: her dokunuşta bir miktar fazladan zaman. Bakım borcunun maliyeti ise birikimlidir ve sonunda basamak yapar.

Bunun tipik örneği sürüm atlamalarıdır. Bir bağımlılığı her çıktığında güncellemek küçük ve rutin bir iştir. Üç büyük sürüm geriden gelmek ise ayrı bir projeye dönüşür — çünkü artık aradaki tüm kırıcı değişiklikler aynı anda karşılanır. Aynı iş, ertelendiği için pahalılaşmıştır.

Pratik sonuç şudur: bakım borcu önceliklendirme konusu olmamalıdır. Düzenli ve küçük parçalar hâlinde yapılan bakım, ayrı bir bütçe kalemi hâline gelmeden önce halledilir. Yapısal borç ise gerçekten önceliklendirilmelidir, çünkü her zaman düzeltilmesi gerekmez.

Bir ekip "teknik borç için zaman istiyoruz" dediğinde, ilk sorulacak soru genellikle hangisinden bahsedildiğidir.

Tamamen yeniden yazma yanılgısı

Borç belirli bir eşiği geçtiğinde en cazip öneri her şeye sıfırdan başlamaktır. Bu öneri, üç şeyi birden hafife alır.

Birincisi, mevcut sistemin görünmeyen bilgisidir. Yıllar içinde eklenmiş tuhaf koşulların çoğu keyfi değildir; gerçek durumların izidir. Sıfırdan yazan ekip aynı durumlarla yeniden karşılaşır ve aynı tuhaflıkları yeniden keşfeder — bu kez müşteri kaybederek.

İkincisi süredir. Yeniden yazma sırasında ürün genellikle durmaz; eski sistem bakım almaya devam eder. Bu, ekibin bir süre iki sistemi birden taşıması demektir.

Üçüncüsü, yeni sistemin de borç üreteceğidir. Aynı ekip, aynı baskı altında, aynı kararları verecektir. Sorun yalnızca koddaysa yeniden yazma işe yarar; sorun karar biçimindeyse yeni sistem daha hızlı eskir.

Genellikle daha iyi çalışan yaklaşım, sınırı çizip kademeli değiştirmektir: yeni işler yeni yapıda yapılır, eski alanlar yalnızca dokunulduğunda taşınır. Yenileme kararında olduğu gibi, tam yeniden yazmayı haklı çıkaran şey estetik değil temeldir.

Borcu görünür tutmak

Teknik borcun en büyük sorunu genellikle boyutu değil, görünmezliğidir. Kimse ölçmediği için tartışma sezgiyle yürür.

Bunu değiştirmek için ağır bir süreç gerekmez. Ekibin bir iş sırasında karşılaştığı engelleri kısa notlar hâlinde biriktirmesi, çeyrek başında bu listeye bakılması ve yalnızca yol haritasının üzerindeki maddelerin alınması çoğu şirket için yeterlidir.

Buradaki asıl kazanç, borcun bir talep olmaktan çıkıp bir kalem hâline gelmesidir. Kalem olduğunda tartışılabilir, ertelenebilir veya kabul edilebilir — üçü de sezgiyle verilen karardan iyidir.

Listenin kısa tutulması da önemlidir. Yüz maddelik bir borç envanteri kimsenin bakmadığı bir belgeye dönüşür; on maddelik ve yol haritasına bağlı bir liste ise her çeyrekte gerçekten kullanılır.

Sonuç

Teknik borç, kötü mühendisliğin kanıtı değildir; hız ile dayanıklılık arasında verilmiş kararların birikimidir. Bu kararların bir kısmı doğruydu ve hâlâ doğrudur.

Problem, borcun varlığında değil, kimsenin ne kadar ödediğini bilmemesindedir. Faiz ölçüldüğünde tartışma teknik olmaktan çıkar ve sıradan bir önceliklendirme konuşmasına dönüşür.

Yazılım danışmanlığı çalışmalarımızda bu konuşmayı genellikle koddan değil, son üç ayda hangi işlerin neden beklenenden uzun sürdüğünden başlatıyoruz.