Technical debt, geliştiriciyi işten çıkmaya götürür mü?

“Yazılım geliştirmede teknik borç (technical debt), daha uzun sürecek daha iyi bir yaklaşım kullanmak yerine kolay bir çözüm seçmenin neden olduğu ek yeniden çalışmanın zımni maliyetidir. Parasal borca ​​benzer şekilde, teknik borç geri ödenmezse, “faiz” biriktirebilir ve değişikliklerin uygulanmasını zorlaştırabilir.” (Wikipedia)

Developerlar genellikle meydan okumaları, yenilikleri seven, heyecanlı ve hevesli insanlardır. Yeni bir çözüm geliştirdiklerinde veya bulduklarında bisiklette ilk kez direksiyonu bırakarak ilerleyebilen çocuk misali “Look mom!” diye bağırma isteği duyarlar. Bu heyecanları doğru kanalize edilmezse ve refaktör zamanı tanınmazsa over engineering veya teknik borç yığını kaçınılmaz olur.

Herkes hatay yapar

Hayatta ve teknolojide sorunları çözmenin onlarca yolu vardır. Junior developerların sorunlar karşısında ürettikleri ilk çözümler genellikle anlık olarak iş görür ama uzun vadede kod karmaşası yaratır. Öyle ki birçok developer (bu durumun farkında olsa bile) bugün yazdığı kodları birkaç hafta sonra “Neden böyle saçma bir kod yazmışım” diye düşünerek okuyacaktır.

Bu canavarı kim besliyor?

En yaygın teknik borçlanma nedeni yakın deadlinedır. Bir an önce bitmesi gereken her iş, ilerleyen safhalarda bitmek bilmez. Çünkü developer bir an önce bitsin diye gelişi güzel kodlar. Oturup projenin gereksinimlerini anlamaya, ileride gelebilecek talepleri öngörmeye, daima geliştirilebilir doğurgan bir yapı kurmaya zaman ayırmaz. Buna zaman ayırırsa, deadline geldiğinde liderinin karşısına çok az bir kısmı tamamlanmış projeyle çıkmaktan korkar.

Müşteriye deadline verilmeden önce olası tamamlanma süresi hakkında developerlardan fikir alınarak yakın deadline’ın yarattığı sorunların önüne geçilebilir.

Teknik borçlanmanın developerdaki etkisi

Kendimden ve birçok developer arkadaşımdan yola çıkarak rahatlıkla söyleyebilirim ki, “Şimdilik çalışsın da ilerde oturur bir güzel refaktör ederiz” denilerek kodlanan bölümler er geç tüm ekibin başına bela oluyor. Ve genellikle bu söz öylesine söyleniyor. Çünkü o bölümler kodlanıp bittiğinde yeni yeni bölümler geldiği için, developer liderine “Hadi beni refaktöre götür” diyemiyor. Yeni bölümlerde de borçlana borçlana geliştirmeye devam ediliyor.

Teknik borçlanma tüm ekibi yoran bir durum olsa da en çok borç sahibini yoruyor. Orada bir yerlerde düzeltilme zorunluluğu olan kirli kod yığını beklerken, bir yandan da yeni görevleri tamamlamak gerekiyor.

Tüm bu süreç başta bahsettiğim developer hevesini masadan kaldırabiliyor. Developerı yeni bir şey keşfetmek istemeyen, “Çözümse çözüm basar geçerim” diyerek kod yazan birine dönüştürüyor. Bu kısır döngü birileri tarafından kırılmazsa developer karşısına çıkan ilk iş fırsatını kabul ederek bu sorunlardan kaçabilir. Bizzat tanıdığım hiçbir developerdan böyle bir hikaye dinlemedim ama kesinlikle yaşanıyordur.

Temiz kod yoktur, temiz yapı vardır

Proje ve ihtiyaçlar belirlendikten sonra temiz bir yapı kurulduğunda en tecrübesiz developer bile yapıyı bozmamaya dikkat ettiği sürece istese de kirli kod yazamaz.

Ama başta kurulan yapı metafizik ögelerine emanetse, master developer gelse bile yapıya düzgün bir kod ekleyemez. “İyisi mi baştan yazalım” teklifini masaya koyar.

Akışı iyi anlamak ve temiz bir yapı kurmak, şu anki developerı ve projeye dahil olacak sonraki developerları hem geliştirir hem de ruh sağlığı ayarlarını korur.

Teknik borçlanmadan kaçış yok

En master developerlar bile dar zamandaki küçük sorunlara ideal olmayan çözümler geliştirip geçebilirler. Bir gün refaktör edecek fırsatları olduğunda bu borçlarını öderler ve yine “Look mom!” heyecanına kavuşurlar.

Bir proje için deadline vermeniz gerekirse refaktör sürecini de göz önünde bulundurmalısınız.