Murat Uysal

Her ne kadar yazılım geliştirme yöntemlerinin isimlerini projeye başlamadan önce sık sık kullanarak plan yapılsa da işler bir noktaya geldiğinde artık yöntemler sorgulanamaz hale gelmektedir. Amaç günü kurtarmak olduysa da artık yazılımın kalitesini sorgulamak kimsenin bir derdi olmaz. Müşteriden gelen negatif feeback'ler giderildiğinde ekip görevini yapmış sayılmaya başlar.

Elbette böyle bir durumu asla istemiyoruz. Hedefimiz daima tercih ettiğimiz geliştirme yöntemlerine bağlı kalmak, ve her aşamada projenin sağlıklı şekilde ilerlemesini sağlamaktır. Ama gerçek dünya tüm işleri planladığınız şekilde gitmesi için çok uygun değil, sürekli değişim içinde. Buna adapte olmaya çalışan yazılım ekiplerinin işleri gerçekten zor ve bu nedenle yazılım geliştirme yöntemleri konusunda standartlaşmaya ihtiyaç duyulmuştur.

Extreme programing şeklinde bir yöntem çıkmadan önce yazılımcıların kullanmaya başladığı ve fayda gördüğü metotlar gelişmişti. Bu metotların birbiriyle birlikte kullanımı ile daha büyük başarı elde edilmesi sonucu da bu yöntemlerin tümüne bir isim belirlendi ve Extreme Programing doğmuş oldu.

Bu metotta birçok yöntem var ancak en önemlileri üzerinde biraz durmak istiyorum.

- Kod Kontrolü

Ekipte birçok bilgi seviyesinde yazılım uzmanı görev almaktadır. Bu durumda da her ekip üyesinin yazdığı kod aynı kalitede olması imkansızdır. Aynı olmasa bile ortalama bir kaliteyi sağlamak gerekir. Bunun amacı okunabilirliği yüksek ve esnekliğini kaybetmeyen bir yazılıma ulaşmaktır. Bu nedenle daima her yazılan kodu ikinci bir göz kontrol etmesi ileride işleri kilitlenir noktaya getirmemek için çok değerlidir.

- Bilgi Akışı

Ekipte herkes aynı bilgi düzeyinde olmaması kabul edilebilir bir durum elbette. Ancak bu durum daha iyi seviyedeki uzmanların bir alt seviyedeki ekip üyelerini bilgi düzeyini arttırıcı iletişim ağı olmalı. Bu aynı zamanda işten ayrılmak zorunda kalan bir ekip üyesi olması halinde de hayat kurtaracak bir gerekliliktir.

 

- Açık ve Korkusuz Ekip Ruhu

Açık sözlü bir ekip daima en iyisidir. Eğer işler kötü gidiyorsa kimsenin rol yapmasına gerek yoktur. Çünkü en nihayetinde olacak olan olacaktır. Bu nedenle öz düşüncelerin rahatça söylenebileceği ve makul değerlendirmeler sonucu kurtarıcı rol oynayacak kararlar alınmasını sağlayabilir. Ekip üzerinde korku ve endişe yerine takım ruhu kazandırılmalıdır.

- Kısa Süreli Versiyonlama

Geliştirilmekte olan yazılım iyi analiz edilmiş olmalı ve küçük parçalara ayrılarak çözümler geliştirilmelidir. Her küçük çözüm uygulandığında uygulama subversion üzerinde commit edilmelidir. Bu sayede uzun süren geliştirmeler sonrası büyük bir update sonucu oluşabilecek sorunlara karşın küçük geliştirmeler sonucu çıkan problemleri gidermek çok daha kolay olacaktır.

- Farkındalık

Projelerde hedeflenen uygulamayı her ekip üyesi net olarak bilmelidir. Bu farkındalığı oluşturmak için proje başlamadan önce ekiple görsel öğelerle hedef uygulamayı izah eden etkileşimli bir sunum yapılmalıdır. Soru cevap bölümü ile oluşan soru işaretleri giderilmelidir. Bunun en büyük faydası planlama aşamasında atanan bir görevin daha etkili ve verimli bir yönü varsa programcı bunu hedef uygulamayı bildiği için bunu tercih edebilme özgürlüğüne sahip olacaktır. Kaliteli bir yazılım olması için bu gerçekten yadsınamaz bir gerekliliktir. Ekibe yeni katılan kişiler de aynı şekilde detaylıca bilgi verilmesi gereken kişilerdir. Ve mümkünse yeni katılan kişi her ne kadar işinde iyi olsa bile en az 2 hafta kod yazımına başlamaması ve bu süre içinde ekibin uyduğu geliştirme standartlarına uyabilmesi için eğitim alabilmesi gerekir.

Benim en önem verdiğim yöntemleri ifade etmeye çalıştım. Tabi ki daha birçok faydalı yöntem var ancak bu yöntemler en çok ihmal edilen veya yapılmadığında en büyük zarara sebep olanlardır. Her ne kadar harfiyen uymanın imkansızlığını biliyor olsak bile ekip olarak bu yöntemlere bağlı kalma mücadelesi verilmelidir. 

Günü kurtaran değil, değerli kod yazan programcılar olmamız dileğiyle.

Felsefem;

Basit Düşün, Çözüm Üret, 

Yazılıma Değil, Çözüme Odaklan...

1-) Eğer kullananılacak veritabanı sadece TCP üzerinden bağlantı kurularak erişilecek ise shared bağlantı desteği disabled yapılması performans için faydalıdır. Eğer bu yapılmaz ise SQL server her bağlantı yapılacağında ilk olarak local bağntı geldiğini varsayıp işlem yapacak sonra TCP olduğunu anlayıp asıl istediğiniz işlemi yapacaktır. Bu da her sorgunuzun daha geç cevaplanmasına sebep olacaktır.

2-) Veritabanından çekilecek sorgularda genellikle SELECT* FROM TABLO_ADI şeklinde kullanılır. Ancak * karakterinin kullanımı performansın önemli olduğu uygulamalarda kullanılmaması faydalı olacaktır. Çünkü * karakteri karşılığında sql server öncelikle ilgili tablonun kaç stünü olduğunu sonra da bu stünların isimlerinin neler olduğunu öğrenip sorguyu kendisi oluşturmakta ve çalıştırmaktadır. Daima gerektiği kadar bilgiyi sorgulamak faydalıdır. SELECT AD,SOYAD from TABLO_ADI şeklinde sorgular ile gerektiği kadar bilgi almak en doğrusu ve performansı en yükseğidir.

3-) Veritabanının FILEGROWTH özelliğini belirlemek stratejik karardır. Bir veritabanına bir kaynaktan veri alarak başlatacağınız belli ve örneğin bu verinin boyutu veritabanı için 100MB a kadar çıkmasını sağlayacak ise veritabanı default ayarlar ile oluşturulmuş veritabanı 100MB ulaşmak için 30 kez alan büyütme işlemi yapmak zorunda kalacaktır. Eğer böyle bir durum belli ise veritabanının başlangıç alanını 100MB ile başlatmak ve gelecek olan veri yoğunluğuna göre veritabanının çok fazla genişleme işlemi yapmasına gerek kalmayacak şekilde büyüme oranı verilmesi yerinde olacaktır. Çünkü veritabanının alan arttırma işlemi performans konusunda ciddi maliyetleri olan bir işlemdir.