Büyümeyi Yavaşlatan Eski Kararlar

0

BEĞENDİM

ABONE OL

News

0

Teknik borç çoğu ekipte bir temizlik listesi olarak konuşulur. Uygun zamanda ele alınacak birkaç eski modül, yenilenecek bir altyapı veya yazılması gecikmiş testler vardır. Ancak borç, yalnızca kodun yaşlanması değildir. Eksik dokümantasyon, kırılgan süreçler, yanlış soyutlamalar ve neden alındığı unutulmuş mimari kararlar da bu birikimin parçasıdır. Sorun, borcun varlığı değil; büyümenin yönünü sessizce değiştirmesidir.

Olgu: Bir sistemdeki teknik borç, değişiklik yapmanın maliyetini ve belirsizliğini artırabilir. Yorum: Bu maliyet ilk günlerde küçük göründüğü için borcun etkisi çoğu zaman gelir kaybı ya da açık bir arıza olarak değil, yavaşlayan kararlar ve daralan seçenekler biçiminde ortaya çıkar.

Hızın sakladığı maliyet

Bir özelliği kısa sürede yayımlamak, özellikle belirsiz bir ürün döneminde makul olabilir. Fakat bu hız, testlerin atlanması, geçici çözümlerin kalıcılaşması veya sorumlulukların belirsiz bırakılmasıyla sağlanıyorsa maliyet sonraki işlere taşınır. Yeni bir geliştirme, önceki kararların istisnalarını hesaba katmak zorunda kalır.

Bu noktada “hemen çalışıyor” ile “değiştirilebilir durumda” arasındaki fark belirleyicidir. Çalışan bir sistem bile neden böyle çalıştığı bilinmiyorsa kırılgan olabilir. Teknik borç, tam da bu bilgi boşluklarında görünmeden büyür.

Kritik eşik nasıl fark edilir?

Teknik borcun büyümeyi yavaşlatmaya başladığını anlamak için tek bir göstergeye bakmak gerekmez. Aynı değişikliklerin tekrar tekrar farklı yerlerde yapılması, küçük taleplerin uzun tartışmalara dönüşmesi, hataların nedeninin bulunmasının zorlaşması ve yeni ekip üyelerinin sistemi kavramakta zorlanması birlikte değerlendirilebilir.

Yorum: En önemli işaret, ekibin seçenekleri teknik nedenlerle değil, mevcut yapıyı bozmaktan korktuğu için daraltmasıdır. Bir kararın değiştirilmesi mümkün görünmüyorsa borç artık yalnızca verimlilik sorunu olmaktan çıkıp stratejik esneklik sorunu haline gelmiştir.

Borcu ödemek, her şeyi yeniden yazmak değildir

Teknik borç konuşulunca akla çoğu zaman büyük bir yeniden yazım gelir. Oysa bütün sistemi baştan kurmak, yeni ve daha riskli bir belirsizlik yaratabilir. Daha ölçülü yaklaşım, en çok değişen veya en fazla bağımlılık yaratan alanları belirleyip küçük ve doğrulanabilir adımlarla iyileştirmektir.

Otomatik testler, sadeleştirilmiş arayüzler, güncel belgeler, gözlemlenebilirlik araçları ve açık sahiplik tanımları bu adımlar arasında olabilir. Her borcun aynı öncelikte olmadığı kabul edilmelidir. Değişmeyen bir modül ile her hafta yeni taleple karşılaşan kırılgan bir modül aynı yöntemle ele alınamaz.

Sonuç: Borç, ertelenmiş bir yönetim kararıdır

Teknik borç büyümeyi, ekip daha fazla kod yazamadığı zaman değil, her yeni karar geçmişteki sınırlamalara mahkûm hale geldiğinde yavaşlatır. Bu yüzden borcu yalnızca mühendislik temizliği olarak görmek eksiktir. Ürün ve teknik ekipler, hangi hız kazanımının hangi gelecekteki maliyeti doğurduğunu birlikte değerlendirmelidir. Sağlıklı büyüme, borçsuz olmakla değil, borcun nerede ve neden taşındığını bilmekle mümkündür.