Nedir bunun hikmeti? “Test-Driven Development”
Kurumsal hayatta yazılımlar çoğunlukla iş biriminden gelen talep ile başlayıp analiz ekipleri ve sonrasında art arda devreye giren bir dizi farklı rol ve sorumluluklar ile hayata geçiriliyor. (Yazılım Geliştirme Yaşam Döngüsü)
Bu döngüde akış iş biriminden uzaklaştıkça daha teknik detay uzmanlıklar içeren bir hal alıyor ve iş birimlerinin, analistlerin konuya etkinliği azalıyor.
Tam da noktada projenin inşaası başlıyor ve geliştirmeyi yapan kişinin uzmanlığı, tecrübesi, yetkinliği projenin gidişatını önemli bir şekilde şekillendiriyor. Geliştirmede yapılan hatalı tasarım, atlanan fonksiyon test sürecinde karşımıza çıkabiliyor. Bazen bu durum neredeyse projenin toplam geliştirme süresi kadar bir maliyeti doğurabiliyor. Büyük bir teknik borç ile karşılaşılabiliyor.
Teknik borçlanmaları azaltmanın en kolay ve etkin yolu da geliştirmeye başlamadan önce geliştirmeyi iyi planlamaktan geçiyor. Buraya odaklanıldığında ortaya çıkarılan geliştirme yönteminin adı “Test-Driven Development”
Yöntem diyor ki;
Geliştirme öncesinde işe test senaryolarını yazarak başla. Test kapsamını ne kadar büyük tutarsan teknik borçlanman o kadar azalacaktır.
Test senaryolarını işin başında çıkarmak için işin başında akıl koymak, efor harcamak gerekiyor. İşin en zorlayıcı ve aynı zamanda değerin oluştuğu yer de tam burası. Teknik tasarım, geliştirmeler ortaya konan akılın üzerine inşaa ediliyor. Test senaryolarını bilmesi geliştirmecinin neye odaklanacağını bilmesini de sağlıyor ve işin kalitesi artmaya başlıyor. Geliştirme kalitesi ile birlikte test ve analiz kalitesi de pozitif etkileniyor. Projelerin uçtan uca başarısı artıyor.
Bir hatanın geliştirme maliyeti teknik olarak geliştirme sürecinden uzaklaştıkça artıyor. Geliştirme sürecinde yakalanan bir hata çok hızlı düzeltilebilirken, testte yada canlıda yakalanan bir hata o kadar kolay düzeltilemeyebiliyor. Hatayı geliştirme sırasında yakalamak çok kritik.
Yapılan araştırmalar ve yöntem denemelerinde “Test-Driven Development” yönteminin koddaki hata sayısını önemli ölçüde azalttığı ispatlanmış durumda.
İş birimi ve analistler için de bu yöntem projelerin daha hatasız hayata geçmesi ve canlıda daha az şikayet ve problem ile karşılaşılması anlamına geliyor.
Büyük organizasyonların hemen yöntem değiştirmesi ve yeni alışkanlıklar kazanması mevcut işlerin içerisinde kolay olmuyor.
Büyük bir değişimden ziyade küçük denemelerle başlamak ve başarısını gördükçe genele yaymak bu işe başlamak için en güzel adım olabilir…
