Salı, Ağustos 15, 2006

Yazılım ve Performans

Yazılım geliştirme safhasında veya tasarım aşamalarında, performans ile ilgili konuların dikkate alındığı durumlar gözlemlendiğinde, genelde performans ile ilgili kaygısı olan yazılımların yazılmasının böyle bir kaygısı olmayan projelere göre daha uzun ve daha maliyetli olduğu gözlemlenir. Bunun böyle olacağı önceden öngörülebilecek bir durumdur, sürpriz değildir.

Sürpriz olabilecek konular, yazılımın performansını artırmak için verilen uğraşların her zaman işe yaramaması, kimi yerde üzerinde uzun zaman uğraşılan performans artırıcı bazı tekniklerin aslında performansı artırmadığının farkına varılmasıdır.

İstisnalar dışında, performans ile ilgili şu yöntemin izlenmesinin katma değer oluşturacağı kanaatindeyim. Bir yazılım projesini ele alacak olursak, günümüzde asıl masraf hardware değil softwaredir. Bir yazılımın geliştirilmesi, onun çalışacağı ortamın maliyetlerine kıyasla çok daha fazla olacağıdır. Bir application server üzerinde çalışacak bir yazılımı ele alırsak, 2000 $ lık bir server bir yazılım için yetersiz kalırken, 5000$ lık bir serverin yeteceği durumunu düşünürsek, 10 kişinin üzerinde 1 yıl çalıştığı bir yazılım projesi için, ortalama 1000$ maaş düşünürsek, aylık 10000$ bir maaş gideri vardır .Eğer performans ile ilgili harca nan zaman, toplamda 1 haftanın üzerindeyse, gider minimizasyonu yapılmamış olur.

Ayrıca, performans uğruna kod üzerinde veya tasarımda yapılan değişiklikler, çoğu zaman, sistemi test edilemez, anlaşılmaz ve değiştirilemez duruma sokar. Özellikle intermediate seviyede yazılımcıların yaptığı bir hata performans yönelimli çalışmaktır. Örnek olarak, business mantığının stored procedurelar ile rdbms üzerinde tutulması, performansı artırabilecek bir etkenken, aynı zamanda kodun kalitesini ciddi anlamda düşürüp mimariye zarar verirken, ileride bir sürü soruna yol açması da mümkündür. (Veritabanı sağlayıcının değiştirilmesi, test edilebilme, değişiklik, tekrar kullanılabilirlik vb.)

Bu risk alınıp performans düşünülmeden yola çıkılıp daha sonra performans sorunları ile yüzleşilirse gene bir çözüm yolu mevcuttur. Eğer kod uygun şekilde yazılmış ise, sistemin tamamı test edilip, performans sıkıntısı olan noktalar yakalanıp performans ile ilgili değişiklikler sadece o noktalarda yapılır. Böylece, faydası olmayacak optimizasyonlara giden zaman da minimuma indirilmiş olur. Çoğu projenin böyle bir çalışmaya ihtiyacı dahi olmaz.

Son olarak, bahsettiklerim, tabii ki kod yazma esnasında performans seçimleri durumunda kötünün yönüne doğru gitmeyi özendirmemelidir, israf her durumda olduğu gibi bunda da zararlı olacaktır, arada bahsettiğim noktalara sıkıntı oluşturmayacak ve kullanımı ile avantajı apaçık ortada olan durumlar olur ise de bunlara dikkat edilmelidir.

Hiç yorum yok: