Yazılım dünyasında, neredeyse herkesin üzerinde birkaç kelime kullanabileceği konuların başında gelir kalite. Tanıma ihtiyaç duyulmaksızın, her kişinin anladığı (ya da anladığını düşündüğü) bir konsept bu. Ancak, sistematik bir biçimde değerlendirmeye başladığımızda, Halep ile arşın arasındaki korelasyon devreye girer ve “onu demek istemedim, bi dakka, neyden bahsediyoruz, yoo onu sen biliceksin” gibi enteresan ünlemler ya da “efeem CMMI der ki, iso bunun için bir standart ortaya koymuş, Deming üstadın da dediği gibi, ama sen Crosby modeline uymuyosun öyle olmaz” şeklinde iki uca çıkacak söylemlerin duyulması bir bakıma işin asli unsuru haline gelir.
Kalite ile ilgili birçok tanım var ve bu tanımlar ilgi konusuna göre detayda çeşitleniyor. Yazılım dünyası için düşündüğümüzde, kalite, ihtiyaçların karşılanması şeklinde genel bir şablon üzerine tanımlanmıştır. Elbette birçok uzmanın farklı yorum ve tanımları da mevcuttur ancak bu tanımlarla beraber, kalitenin maliyeti referansına da atıfta bulunarak, bir işin ilk defada doğru yapılması şeklinde bir yaklaşımı benimsediğimi de ifade etmem gerekir. Ek olarak, akademik ya da standart tanımların içerisinde, “gördüğümde anlarım” şeklinde bir ifade de mevcuttur. Kalite konusunun ortaya koyduğu resmin ne derece renkli olduğu, tanımların çeşitliliğinden de anlaşılacaktır.
Literatürel ya da entelektüel kalite değerlendirmelerinin “gerçek hayat” varyasyonları düşünüldüğünde de ortaya ironik bir durum çıkmaktadır. Yukarıda da ifade ettiğim gibi, her kişinin konuyla ilgili mutlaka yorum yapma kabiliyeti(?) ve hakkı(?) olduğu bir konudur. Değerli bir arkadaşımızın ifadesiyle, “ne yapıyorsunuz ki, iki tekstbaks bir buton” ile başlayan alan dışı sataşmalar, “şuraya iki if koyuciksin” diyen basic dili ya da excel macro gurularının katkıda bulunduğu kalite, öncelikle hatalı ya da sorunlu yaklaşımları üzerinden tanımlanmalı ve değerlendirilmelidir.
Kalitenin bir tür ölçüm, bir seviyeyi karşılama oranı olduğu düz mantık bakıldığında ortaya çıkacaktır. Ölçümün nasıl olacağı, ya da seviyelerin nasıl belirleneceği konusu ise her daim araştırma ve geliştirmeye açıktır. Yazılımda kullanılan ya da kullanılabilecek birçok kalite modeli vardır. Bu modellerin bazıları doğrudan kalite parametrelerini tanımlayıp ölçüm değerlendirmesi yaparken, bazıları daha genel olarak bir süreç tanımlar ve içerisindeki adımların ne ölçüde karşılandığına bağlı olarak kalite endeksi oluşturur. Ancak her modelde ortak bir yaklaşım göze çarpar: kalite, aşamalı, birbirini tamamlayan süreçler bütünüdür. Yani kimse bir seferde tek bir değişiklik (ya da değişiklikler bütünüyle) kaliteyi elde ettim diyemez. Kişilerin yorumları, kendi aşamalarını ve bütüne nereden baktıkları ölçüde ya değerlendirmeye katkıda bulunur ki nadirdir, ya da köstek olur.
Yazılım, asli itibariyle bir kod geliştirme etkinliğidir. Bu etkinliğe katılan tüm parçalar aslında sonunda kod üretimi için çalışırlar. Her ne kadar geliştirme ya da yazılım denildiğinde kod kısmı özellikle ülkemizde neredeyse ilkel seviyede bir iş ve hatta yazılım geliştirmede önemsiz(!) bir iş gibi görülse de, bir projede, programda ya da iş bütününde kodlama, ana işlemdir. Dolayısıyla, kalite ile ilgili ortaya çıkan tanımlar, yaklaşımlar ya da hatalar, açıktan ifade edilmese de, kodlama üzerine bina edilmiştir. ISO standardında kalite altında birçok parametre vardır mesela ve bunlardan bir tanesi, güvenilirliktir. Yazılımın güvenilir olması ne demektir? Bizi üzmeyecek, sürprizler yapmayacak olması mı? Bir bakıma öyle ama burada güvenilirlik demek, yazılımın belli ölçülerde dengeli ve sürekli çalışabiliyor, yani performansını bu değerlere göre sürdürebiliyor olması demektir. Bunu nasıl sağlayacaksınız? İki if ekleyerek olmayacağı, kod geliştirirken “işte, bizim yazılımcı yapıyor bişeyler ama adam yavaş ya; iki günde çıkaramadı Mernis tabanlı kayıt kontrolünü. Sanki ne yapıyor…” denilmeyeceği açıktır.
Yazılım kalitesi, “hee, biz de yaptık önceden, n’olmuş? Böyle yapacan işte, karıştırma” diyen uzman/kıdemli/kademeli kıdemli yazılımcıların ifadelerine de mazhar olur elbette. Sadece dış mihrakların değerlendirmeleri değil, kendi öz evlatlarının da taşlamasını göğüsler kalite. Burada da “memleketi ben mi kurtaracam” dan başlayıp, “yazdık işte yaa, ne gerek var şimdi bu class içindeki metotları interface içine almaya” ya, “ne varmış benim fonksiyonumda, haa, soldan 8, sağdan 12.sıradaki parametre boolean değer onu çıktı alıcaksan turu göndericen” e, “ne işi var bu property nin bu class ta, ha bire implemente etmem gerekiyor alt classlarda” ya, “object, tamam al sana object, bi saniye… hmm oldu işte Customer, ne oldu, başka customer mı var, o zaman CustomerNew…” den, “bunu kim yazdı, döngü içinde milyon tane geçici değişken tanımlanmış, yarısı kullanılmıyor, üstüne bi de zaten niye bunu döngü dışında yazmadın ki, pl/sql mi yazıyoruz” dan, “adam bi kod yazmış, akıyo abi, mantıksal ayrım hak getire, üstten aşağı okuyosun, ne yaptığını anlıyorsun… aynı if blokları, while blokları, hikaye anlatımı gibi 50 yerde geçmiş, zaten kaç sayfa sürüyor tek metot onu da anlamadık” a kadar çok farklı ifadeyle kod seviyesinde kendini gösterir. Buradaki örnekleri artırmak mümkün ama konu anlaşılmıştır sanıyorum.
Yazılım kalitesi sadece kodlama değil elbette ama tüm bina kodlama temeli üzerine gidiyor. Sonrasında, kullanılabilirlik yaklaşımları da devreye giriyor ve üst yapı, görsellik ve işlevlerin kolaylığı gibi değerlendirmeler de kalite içerisinde yer alıyor. İlk tanıma geri dönersek, ihtiyacı karşılama kalitenin ana felsefesiyse eğer, tüm bu parçaların birleştirilip amacı karşıladığının kontrolü, kaliteyi tamamlıyor olacaktır.
Kalitenin aşamalı oluşu, örnekler düşünüldüğünde, öncelikle yapılan iş ile ilgili farkındalık oluşturma, geliştirici ekibin ne denli kıymetli iş yaptığının bilinmesiyle başlıyor. Bunu yapabilmek için eğitim şart tabi, ama yeterli değil. Sürekli kontrol gerekli ve bir geliştirme yapılırken ihtiyaç duyulan zaman ve mekanın sağlanması da lazım.
Günümüzde özellikle bilgisayar mimarisi, donanımsal altyapı olarak fiziksel sınırlara dayanmış durumda. Yani milimetre kare içerisinde yer alabilecek transistör sayısı için artık farklı bir şeyler yapma imkanı yok. Bu demek oluyor ki, hız artık sorunumuz değil (genel durum için böyle tabi, zaman kritik uygulamalarda çok değişik senaryolar vardır). Hız sorun olmaktan çıkınca da kod geliştirme bir şekilde işi yaptığında yeterli olabiliyor. Kaputun altı o kadar önemli olmuyor ilk zamanlarda. Ama ne zaman ki bir arıza çıkıyor, aha o zaman ne nereye nasıl bağlı kıvranmaya başlıyorsunuz. Bu nedenle kod geliştirme ve kalite üzerinde fazlasıyla duruyorum.
O iş olmaz deyip nasıl olması gerektiğini de ortaya koyamayacak kişi ve oluşumları dışarıda (en azından bir miktar pasif) tutup, asıl elemanları, yazılımın amelelerini sürece dahil etmeli, hatta oradan başlanmalı. Kalite, zamana yayılmış, gün ve haftalarla olgunlaşan bir süreçse eğer, her an bir adım atılmalı ve işi yadırgayanlar dikkate alınmadan bir plan oluşturulmalı.
Bu konuya devam edeceğiz klişesiyle yazıyı noktalıyorken, (olası) diğer yazılarda doğrudan model detaylarına, parametrelerle ilişkin tanımlara girilmeyeceğini, daha çok kalite ve çalışan yaklaşımları açısından farklı bir üslupla konunun ele alınacağını (yukarıda bilimum örnekleri var 🙂 ) ifade ediyorum. Bundan sonrası, giriş mahiyetindeki bu yazıda ifade edilen belli başlı sorunların detaylandırılmasıyla ilgili olacaktır.
while (lifeRepository.GetDailyToken())
{
process.Filter(whatIsuseful)
.Read(availableSources)
.Code(toUnderstand)
.Test(ifThatWorks)
.Share(withOthers)
.Write(ifPossible);
.Publish(someDayAtSomeMedium);
}
