Teknik Borç

     
Martin Fowler
1 Ekim 2003

“Bu çeviri tarafımdan, dilim döndüğünce yapılmış olup, yazarın izni ile yayınlanmıştır.”

Sisteminize eklemek istediğiniz bir fonksiyon var diyelim. İki seçeneğiniz var, biri hızlı ve çirkin – biliyorsunuz ki ileride yapacağınız değişiklikleri daha zora sokacak. Diğeri ise temiz bir tasarımla sonuçlanacak, ama devreye almak için daha çok zamana ihtiyaç var.

Teknik Borç, Ward Cunningham tarafından bu sorun üzerinde düşünmemizi sağlamak için geliştirilmiş harika bir metafor. Bu metaforda, hızlı ve çirkin işler yapmak teknik olarak, aynı finansal anlamdaki gibi sizi borçlandırıyor. Bir finansal borç gibi teknik borç da, hızlı ve çirkin bir tasarım seçiminden dolayı ilerde yapılacak geliştirmelerde daha fazla güç sarf etmek zorunda kalmak şeklinde bir faiz ile geri ödeniyor. Faizi ödemeye devam edebilir yada hızlı ve çirkin tasarımı daha iyi bir tasarıma dönüştürmek için yapıyı tekrar düzenleyerek anaparayı ödeyebiliriz. Her ne kadar bu bize anapara ödemesi kadar bir maliyete yol açsa da, gelecekte ödeyeceğimiz faizi düşürmüş oluruz.

Bu metafor ayrıca hızlı ve çirkin yaklaşımın ne kadar hassas bir konu olabileceğini de açıklıyor. İşletmelerde pazar fırsatı avantajı sağlamak adına borçlanmak ne ise, uygulama geliştiren biri için de önemli bir termini yakalamak uğruna teknik borçlanmaya girmek aynıdır. Ortak sorun, geliştirme birimlerinin borçların kontrolden çıkmasına izin vermeleri ve gelecekteki geliştirme faaliyetleri için harcadıkları gücün çoğunu bu felç edici faiz ödemelerine harcamalarıdır.

Teknik borçlanmadaki incelik, tabi ki para gibi etkin bir şekilde ölçmenin imkansız olmasıdır. Faiz ödemeleri bir ekibin verimliliğini zedeleyebilir, ama verimliliği ölçemediğimizden teknik borcumuzun gerçek etkisini tam olarak göremeyiz.

Çok kolay gözden kaçan bir şey de sadece yazılım dağıtımı vasıtasıyla borçlanarak para kazanabilirsiniz. Tasarım dayanıklılığı hipotezine göre, tasarım mantığını oturtmadan önce yazılım dağıtımını yapmalısınız ki borcunuzu azaltma şansınız olsun. Hatta öncesinde faiz ödemelerine ve maruz kalacağınız anapara ödemesine karşın erken yazılım dağıtımının bedelini dengelemeniz gerekir.

Teknik borç, kimi iyi kimi kötü, çok değişik yapılarda gelebilir- ben tanımlamak için “Teknik Borç Çeyreği”ni kullanıyorum.

(Bildiğim kadarıyla söyleyebileceğim, Ward bu kavramı ilk kez OOPSLA 1992 deneyim raporunda dile getirdi. Ayrıca wiki üzerinde de tartışıldı.)

Daha fazlası için

Ward Cunningham’ın yarattığı bu metafor hakkında görüşlerini belirtiği bir videoya buradan erişebilirsiniz.

Bir kaç okuyucu bazı benzer isimler göndermiş. David Panariti çirkin programlamaya noksan programlama şeklinde ilgi kurmuş. Anlaşılan aslında bir kaç yıl önce kullanmaya hükümet prensibine uymasıyla ile başlamış; sanırım şimdi tekrar normale dönüşmüş.

Scott Wood, “Teknik enflasyon mevcut teknoloji seviyesinin geliştirmek istediğiniz ürünün temelini aşması durumunda endüstri ile uyumluluğunu kaybetmeye başlar ve bu işlerin kötüye gitmesi şeklinde görülebilir. Buna örnek olarak bir programlama dilinin versiyonunda geri kalarak ana akım derleyicilerin kodunuzla artık uyumlu olamaması gösterilebilir” şeklinde bir öneride bulundu.

Steve McConnell bu metaforda bir çok güzel noktanın görülmesini sağladı, özellikle yanlışlıkla girilen borcun düşük seviyede tutulmasının nasıl gerektiğinde kasten borca girmek üzere yer açtığını belirtti. Ayrıca en az ödeme kavramı da hoşuma gitti (gömülü sistemlerdeki sorunların giderilmesindeki ödemeler web sitelerine nazaran çok yüksektir).

Aaron Erickson Enron finansı hakkında konuştu.

Henrik Kniberg en büyük soruna sebep olan daha eski teknik borç olduğunu ve bunu yönetmeye yardımcı olması için nitel borç tavanının akıllıca olduğunu savundu.

http://martinfowler.com/bliki/TechnicalDebt.html

Bir Cevap Yazın