Teknik Borç Nedir ve Nasıl Ödenir?

Her borçlanmanın sonu, bedeli ödenmediği zaman iflastır. Aynı şey yazılım projeleri için de geçerli. Teknik borcu ödenmeyen projelerin başarıyla tamamlanmaları ya da sürdürülebilmeleri mümkün değildir. Bu yazımda projelerde yaşanan teknik borçlanmalardan ve bu borçların nasıl ödenebileceğinden bahsetmek istiyorum. Önce teknik borcun tanımını yaparak başlayayım.

Teknik borçlanma uygulamanın kalitesinden ödün vermektir. Geliştirme sürecinde kalitesi düşen uygulamada teknik borçlanma artar. Teknik borçlanma kötü kaliteye sahip bir uygulamanın, iyi kaliteye sahip bir uygulama haline dönüştürülmesi için planlanması gereken çalışmaların neden olduğu maliyettir.

Teknik borçlanmanın ana sebepleri şunlardır:

• Sürüm oluşturma baskısı
• Projenin sahip olduğu kalite kontrol mekanizmalarının yetersiz olması.
• Ekibin teknik yetersizliği.
• Kodun yeni müşteri isteklerini tatmin edecek şekilde yeniden yapılandırılmaması (refactoring).
• Uygulamanın sürekli entegre edilmemesi.

İki teknik borçlanma türü vardır. Bunlar:

• Bilinçli olarak teknik borçlanma
• Bilinçsiz olarak teknik borçlanma

Sürüm oluşturma baskısı bilinçli teknik borçlanmaya gidilmesini beraberinde getirebilir. Sürümü yetiştirmek için her şey mubahtır filozofisi teknik borçlanmayı kolaylaştırır. Sürüm oluşturulduktan sonra teknik borçlanmalar gerekli yapısal değişikliklerle ödenebilir. Bu yapılmadığı taktirde teknik borçlanmanın faizi işlemeye başlar. Çoğu projede teknik borçlanma bilinçli olarak gerçekleşir. Bu bilincin var olmasına rağmen birçok projede teknik borçların ödenmesi konusunda bilinçli bir çalışma yapılmaz.

Bilinçsiz olarak gerçekleşen teknik borçlanmanın temelinde teknik yetersizlik yatar.

Teknik Borçlanma Örnekleri

Orta ve büyük çaplı projelerde tasarım prensipleri uygulanmadığı taktirde, doğrudan teknik borçlanma oluşur. Bunun en güzel örneğini tek sorumluluk prensibi oluşturmaktadır.

Tek sorumluluk prensibine göre bir sınıf ya da bir metot sadece bir işten sorumlu olmalıdır. Bu prensibe uyulmadığı taktirde, birden fazla işten sorumlu olan sınıf ve metotlar oluşur. Birden fazla sorumluluğu olan sınıf ve metotlar kırılgandır. Mevcut bir sınıfa ikinci bir sorumluluk yüklendiği andan itibaren teknik borçlanma başlar, çünkü sınıfın sahip olması gereken teknik yapıdan taviz verilmiştir. Burada tek sorumluluk prensibine uygun bir yapının oluşturulması için gerekli zaman dilimi teknik borcun miktarını belirlemektedir. Eğer bu anomaliye anında müdahale edilmezse, teknik borçlanma oluşur ve sınıf bu teknik borcu geleceğe doğru sırtında taşımaya başlar. Sınıf için gerekli teknik yapı düzeltilmediği sürece teknik borçlanma devam eder. Bu sınıfa yeni bir sorumluluk verildiğinde, teknik borçlanma artar.

Yazılım projelerinde en büyük sıkıntılar uygulama entegrasyonlarında yaşanır. Yazılım geliştirme sürecinde ileriye atılan entegrasyon çalışmaları için her an teknik borçlanma gerçekleşir. Şimdi bu ve buna benzer teknik borçlanmaların nasıl ödenebileceğini inceleyelim.

Teknik Borçlar Nasıl Ödenir?

Gelişim sürecinde bulunan bir uygulama sürekli değişikliğe maruz kalır. Bunun başlıca sebebi, müşteri gereksinimlerinin piyasa koşulları doğrultusunda değişmesidir. Yazılımcı olarak öncelikle değişimin kendisini sabit ve değişmeyen bir parametre olarak kabullenmemiz gerekiyor. Buradan uygulamanın sürekli yeni özellikler eklenerek, yoğrulabilir yapıda olması gerektiği sonucu çıkarabiliriz.

Bir uygulamanın istenildiği şekilde yoğrulabilmesi için bazı teknik özelliklere sahip olması gerekmektedir. Bir uygulamayı yeniden yapılandırmada kullanılabilecek en güçlü silah testlerdir. Birim ya da entegrasyon türünde testleri olmayan bir uygulamayı yeniden yapılandırmak yani hamur gibi yoğurmak mümkün değildir, çünkü yapılan değişikliklerin yan etkilerini ölçmek mümkün olmaz.

Teknik borçlanmayı ödemek demek, uygulamayı hak ettiği teknik seviyeye getirmek demektir. Teknik borçların ödenebilir olmalarını sağlamak için uygulamanın her an yeniden yapılandırılabilir yapıda olması gerekmektedir. Bunu mümkün kılan uygulama testleridir. Testlerin olmadığı ya da yetersiz oldugu bir uygulamada teknik borçların ödenmesi imkansızdır. Bu er ya da geç uygulamanın belli bir büyüklükten sonra bu borcun altında ezilmesi ile kendisini gösterecektir.

Tasarım prensiplerinin uygulanması teknik borçların ödenmesini kolaylaştırır ya da oluşmalarını engeller. Tek sorumluluk prensibine uyulmamasının teknik borçlanmayı nasıl çabuklaştırdığını daha önce inceledik. Aynı şekilde örneğin açık, kapalı prensibinin (Open Closed Principle) uygulanması, uygulamanın teknik borçlanmaya gerek kalmadan, gelecekteki değişikliklere açık olmasını sağlar.

Teknik borçları ödemenin en kolay yolu, oluşmalarını engellemektir. Extreme Programming gibi çevik yazılım süreçleri bu amaçla uygulanabilecek teknik metotlar ihtiva etmektedirler. Örneğin sürekli entegrasyon (continuous integration) yöntemiyle entegre etmemekten doğan teknik borçların oluşması engellenir. Test güdümlü (test driven development) yazılım testlerin oluşmasını, kod kapsama alanının geniş olmasını ve bu şekilde uygulama için gerekli adaptasyonların çok daha kolay yapılabilmelerini beraberinde getirir.

Teknik borçlanma kodun bakımı ve geliştirilebilirliğini doğrudan etkiler. Ciddiye alınmadığı taktirde projenin başarısız olmasını beraberinden getirir. Yazılım ekibi teknik borçları sürekli gözetlemekle yükümlüdür. Bu amaçla örneğin Sonar kullanılabilir. Sonar aracılığı ile kodun teknik analizi yapılır. Bilinçsizce yapılan teknik borçlanmaları Sonar ile keşfetmek mümkündür. Örneğin modüller arası döngüsel bağlar sıkça oluşan teknik borçlanmaların başında gelir. Koda bakarak, bu tür teknik borçlanmaları keşfetmek kolay değildir. Bu yüzden Sonar gibi bir aracın kullanılması, teknik borçlanmanın önüne geçebilmek ya da artmasını engellemek için zaruridir.

Teknik borçlanmanın sürüm baskısı gibi dışsal sebepleri olsada, teknik borçlanmaya sebep veren kodun yazarıdır. Bu sebepten dolayı kodu yazanların bu konuda hassas davranmaları gerekmektedir. Örneğin izci kuralına uyulduğu taktirde, teknik borçların ödenmesi yazılımın bir parçası haline gelir.

Teknik borçlanma yazılımda kullanılan ve uygulamanın içinde bulundugu teknik duruma işaret eden bir metafordur. Bu metafor ekip içinde bu konu hakkında fikir alışverişini sağlar ve yapısal değişikliklerin her zaman gerekli olduğu bilincinin oturmasını kolaylaştırır.

EOF (End Of Fun)
Özcan Acar