Pazar, Ağustos 20, 2006

Yazılımda Modülarite Nedir ?

Modülarite ile ilgili bir kullanım yanlışlığı olduğunu düşünüyorum. Pazarlama stratejilerinin getirdiği bir yanlışlık olabilir, yazılım sektöründe olan aşağı yukarı her firma/kişi yazılımlarının modüler yapısından bahsediyor aslında, gerçekte bir modülarite olmadığı gözlense dahi, belki spec sheetlerde güzel durduğu, belki müşterilerin kafasında güzel bir yere sahip olduğu için, yazılımda modülarite popüler bir deyim olarak kullanılıyor.

Mobilya sektöründe de çok kullanılıyor bu terim, kuru bir tanım yerine oradan bir örnek vermek isterim,

modüler mobilya, çeşitli parçaların biraraya getirilerek yeni modüllerin oluşturulabileceği bir yapıdır. Hem bir koltuk masa ve dolabın bir araya getirilerek takım haline gelebilmesi, ki bu biraraya gelme müşteri seçimine göre olabilir, hemde çeşitli parçaların hazırda bulunarak ihtiyaca göre mobilyanın şekillenebilmesi şeklinde ifade ediliyor.

İhtiyacınız olan ölçülere göre bir mobilyanın değişik parçalardan bir araya gelmesi gibi. Aslında yazılım için bu ikinci işlev daha çok reusability'i canlandırıyor gözümüzde, bizim için modülarite ilki gibi biraz. Birbirleri ile beraber durduğu zaman işlevini yerine getirebilecek parçalar. İhtiyaç duyulduğunda beraber çalışması sağlanabilecek. İstenildiğinde ayna kapılı olabilecek bir dolap belki ihtiyacımız olan.

Bir yazılım içerisinde modülarite olması, kanaatimce, öncelikle o yazılımın değişik modüllerinin birbiri ile ilişkisinin düzenlenmesi esnasında alıncak kararlar sonrasında, öncelikle her bir modülün kendi işlevini yürüterek diğer modülleri minimum etkilemesi, mbu modüllerin olmaması durumunda yazılımın genel yapısına zarar vermeden sadece belirli özelliklerinin daha az olması, biraz da reusability e girersek, değişik yapılarda da kullanılabilmesi demektir.

Yani, bir yazılım içerisinde muhsaebe modülünün olması, o yazılımın aslında muhasebe modülü olmadan çalışabilmesi gerekliliği, olduğu zaman muhasebe ile ilgili özelliklerin ve belki başka modüllerin üzerine muhasebenin getirebileceği katma değerlerdir.

Ancak, modüler yazılım, modüllerin hepsinin hazır olup, sadece bazı lisanslandırma değerleri için bu özelliklerin gösteriminin saklanması değildir. Bu işlem, genelde, yazılımın aslında o modül olmadan çalışamayacağını gösterir. Özellikle veritabanı bazlı tasarımlarda bu gözlenir, kullanıcının ihtiyacı olmadığı modüllerin bazı bilgileri kullandığı modüllerin veritabanı yapısı içerisinde saklanmaktadır.

Modüler yapı, bir plug-in gibi çalışmalı, hatta ideal olarak, runtime da dahi değiştirilebilen bir yapı olmalıdır. Bir iskelet etrafında yerleştirilecek modüller, eğer iskelet düzgün tasarlanmış ise, iskeletin genelini ilgilendirmez. Sadece kendi alanını ilgilendirir. Eğer modülün olmaması, ki sadece önyüzünün değil, varlığının da veya düşüncesinin de olmaması durumunda bu iskelet ayakta durabiliyorsa ve bu statuye yazılım çevirilebiliyorsa, modüler yapıya ulaşılmış demektir.

Bu yapı sayesinde, farklı modüller üzerinde diğerlerini etkilemeden çalışmak mümkün olur. Omurilik üzerine oturan kaburgalar gibi, olmadıklaır zaman işlevsellik eksik olsa da, omurilik ortadadır.

Bu yaklaşım, aynı anda farklı modüllerde geliştirilme işleminin diğerlerini etkilememesi gibi önemli bir özelliği sağlarken, aynı zamanda, reusabilitynin de kapılarını açmaktadır, bu modüller bahsedilen bir özelliğe sahipse, başka omurgalar ve başka kaburgalar ile beraber de kullanılabilir.

Burada modüllere karar verebilmek gerekir. Bir loglama modülü de olabilir bu, yazılıma loglama özelliği ekler, ki nispeten business modüllerine göre modülaritesinin sağlanması daha kolaydır, daha önce bahsedildiği gibi bir muhasebe modülü de olabilir.

Tabii ki, bu modüllerin kendi içerisinde bir bütünlük arzetmesi, kendine göre bir mimarisi olup sonu ve başlangıcının net olması, biraraya gelmiş modüllerin kod karmaşasına dönüşmemesi gibi konular modülün kendi içerisindeki davranışlarını belirleyecektir.

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.

Pazartesi, Ağustos 14, 2006

Java vs. Dotnet

Yeni bir uygulama başlangıcında, dil seçiminin yapılma gereksinimi sık sık bu soruyu karşımıza getirir, Java mı Dotnet mi ?

Özellikle üzerine bir yapı kuracak kurumlar için bu soru çok önemli bir sorudur. Kurumlar bu seçime göre eleman alacak, yatırım yapacak, belki eğitim masraflarına girecek ve nihayetinde uzun süren bir çalışma sonucu bir ürün ortaya çıkaracaklardır.

Aslında çoğu konuda olduğu gibi burada tek bir cevap yerine, duruma göre bir karar verilmesi gerekliliği mevcuttur.

Her şeyden önce, bu tür bir karar, kurumun tamamını etkilemelidir. Eğer kurumun bir kısmı başka bir dil/platform başka bir kısmı başka bir dil/platform kullanıyor ise, bu noktalar arasında geçiş çok sancılı olur. Eğer bu gruplar arasında organik hiçbir bağ yok ise ve olması da düşünülmüyor ise, ne kullanıldığı çok önemli olmamakla beraber, yazılım geliştirme yapılan bir şirket içerisinde birbirinden bağımsız böyle grupların olmasının verimliliği nasıl etkileyeceği de gözden kaçırılmaması gereken bir konudur.

Asıl konunun biraz dışına taşıyor olsam dahi bunu biraz irdelemek isterim. Üretim süreçlerinde, ki yazılım geliştirme de bir üretim sürecidir, fabrikalardaki üretim sistemlerinde kullanılabilecek kavramların faydalı olabileceğini düşünüyorum.

Yazılımdaki gibi, fabrikalarda gelen işler çeşitlilik arz eder. Metal üretimi yapan fabrikaları örnek alırsak, aşağı yukarı her parça ısıl işlem, metal işleme, birleştirme adımlarından geçer.

Her parça için bu işlemler aynı yerde yapılır. Parçanın bir dişli olması veya başka bir malzeme olmasından bağımsız olarak, ısıl işlem hep aynı yerde aynı ustalar, aynı fırınlar tarafından yapılır. Her parça üreten ekip ayrı bu işi yapmaz. Vida üretilecek ise bunu tek bir yer yapar, ayrı birimler kendi vidalarını üretmez. Bunun sebebi maliyet düşürmektir, eğer her birim her işi yapmaya kalkar ise üretim süresi, kalitesi ve maliyeti negatif bir durum alır. Birbirinden bağımsız bir üretim biçimi, kaynakların etkin kullanılamaması, uzmanlaşmayı engelleme gibi konulara sebep olur.

Bu yapının çalışabilmesi için, akışların düzgün planlanmış olması, yapının parçaya bağımlı olmaması, mevcut bir parçanın bir yerde kullanılması ihtiyacı durumunda mevcut üretimde böyle bir parça var ise kullanılması, eğer yok ise ve daha sonra da başka işlerde kullanılacak bir parça ise bu işlere de cevap verebilmesi gereksinimleri vardır.

Yazılım için de aynı mantık kurulabilir. Birlikte çalışacak birimlerin koordine olarak çalışması, uzmanlaşmanın saplanabilmesi, takım oyunu, tekrar kullanılabilir parçalar gibi düşünebiliriz.

Bu hususlar dikkate alınırsa, bir organizasyonda birbirine bağlı organik yapıların ve bu yapıları birbirine bağlayacak, çimento görevi görecek bazı yapıların da olması gerektiği kanaatindeyim, bu da başka bir makale konusu.

Gelmek istediğim nokta, kurumda yapılan seçim tüm kurumu etkileyecektir, bu yüzden dikkatli bir seçim yapılması gerekir, sonradan geri dönüşü pek mümkün olmayabilir.

Alternatif olarak, farklı diller ve ortamlar kullanan projeler için, araya web service konularak haberleşmenin sağlanabileceğidir, bir service oriented yapı için yapının içerisinde farklı diller barındırmasının çok sakıncası yoktur. Genede, etkin kaynak kullanımı tek dil kullanımını gerektirir.

İş Gücü Maliyeti

Öncelikle, Java ve Dotnet için eleman bulabilme ve bulunan elemanın maaş skalası konusunu inceleyebiliriz.

Internette ufak bir araştırma sonrasında, dotnet ile ilgili çok sayıda kaynak olduğu fark edilen bir şeydir. Biraz dikkatli gözlerin daha çok fark edeceği şey, bu kaynakların genelde beginner – intermediate seviyede olduğudur. Yani dotnet’ e başlamak ve istenilecek şeyleri yapmak için çok fazla kaynak var.

Microsoft, kanaatimce, dotnet için hedef kitle olarak, önceki Microsoft yazılımcılarını (Vb) hedeflemek kadar, beginner – intermediate seviye yazılımcıları hedef almıştır. Buradaki seviyeden kasıt, çok işlem yapan veya kritik sistemlerde kullanılabilen bir yazılım değildir. Seviye, yazılım geliştirme için genel geçer konseptlerle ilgili bir seviyedir.

Yazılım yönetimi, tekrar kullanılabilirlik, nesneye yönelik yazılım (OOP), yazılım testleri, design patterns gibi konseptlerin referans verildiği dotnet makalelerinin sayısı artıyor olsa da, xmlden datayı nasıl okurum şeklindeki makalelerin sayısı ile kıyasalanamaz dahi.

Microsofttaki makaleler de aynı şekildedir, bir textboxı nasıl validate edeceğiniz ile ilgili birsürü kaynak bulunurken, bu bahsedilen daha gelişmiş seviyedeki konular hakkında bilgiye rastlamak çok zordur, hatta dotnette yazılım yapan bir kişinin çoğunlukla bu kavramlardan haberi bile yoktur. Ayrıca, milyonlarca sayfalık içerik arasından, bu tür kavramlarla ilgili dokümana rastlamak da çok zor oluyor.

Geleceğim nokta, Dotnet teki beginner ve intermediate desteğinin pozitif ve negatif etkileri olarak, dotnette yazılım yapan yazılımcı bulmak kolaydır, çünkü öğrenmiş yazılımcı sayısı çok fazla, öğrenme süreci nispeten kısadır, zira beginner dokümanlara rahatça ulaşabilen biraz hevesli kişiler dotnet kullanabilir. Ancak, bu kişilerin büyük bir çoğunluğu daha ileri seviye konulara giremez, hem ihtiyaç duymaz, hemde çoğunluk bu tür konuların farkında değildir.

Bu bilgi, beraber çalıştığım, çıktığından beri dotnetle uğraşan birçok yazılımcının fikirlerini öğrendikten sonra ortaya çıktı, dotnet yazılımcılarının ekseriyeti prosedürel programlamanın uç noktalarını zorlasa dahi, daha gelişmiş konulara girme ihtiyacı hissetmemektedir.

Java’yı ele alırsak, java’nın dokümanlarını aynı şekilde incelediğinizde, karşınıza çıkabilecek yazıların büyük bir kısmının advanced konular olduğunu fark edeceksiniz . Özellikle daha önce kullanılan dillerden bir takım bilgilerin buraya aktığını, c++, smalltalk gibi eski dillerden edinilmiş tecrübelerin Java ‘da kullanılmakta olduğu fark edilecektir. Beginner seviye dokümanlar olduğu gibi, intermediate ve çok sayıda advanced dokümanlarda vardır. İş gücü olarak, Javada üst seviye yazılımcı bulmak daha kolaydır. Ancak Java da beginner seviyede kod yazabilecek kişi sayısı nispeten daha az, çünkü genelde java için başlangıç adımı dotnete kıyasla daha zor bir adımdır.

Mevcut uygulamalar için, dotnetin kullanımı saece dotnet framework ile sınırlı kalsa da, Javayı çıplak kullanana rastlamak çok zor, Java genelde bir framework ile kullanılır, Swing, Struts, Spring, Tapestry, Jsf,hibernate ve bunun gibi frameworkler, Javaya asıl değerini katan frameworklerdir, ancak bunların dezavantajı, başlama seviyesindeki bir kişinin bunların kullanılacağı projeler için bu frameworkleri öğrenme sıkıntısıdır, bunların dokümanları da kendilerine hastır, genelde open source projeler olarak yürütülen çalışmaların dökümanlarının içerisinden çıkmak için de bazı üst seviye bilgilere ihtiyaç duyulur. Ayrıca, ortada olan bir framework karmaşasından dolayı seçim için dahi ileri seviye bilgiye ihtiaç vardır. Dotnet için kullanılacak framework en fazla rdbms (relational database management system) ile ilişkiyi sağlayan bir frameworktür, öğrenme süreci çok daha kolaydır.

Netice itibari ile, çalışacak eleman açısından, dotnet için hem eleman bulmak kolay, hemde ucuzdur, yeni bir eleman eğitme maliyeti de düşüktür. Java için, eleman sıkıntısı, maaş seviyesinin daha yüksek olması, çalışan beklentilerinin daha yüksek olması, eğitim maliyeti gibi konular sözkonusudur.

Yazılım Geliştirme Maliyeti – Süresi

Orta veya büyük çapta bir yazılım için, yazılımın altyapısının geliştirilmesi, ortak noktaların çıkarılması, tekrar kullanılabilirlik, debug, yazılım testi, veritabanı değiştirme imkanı – veritabanı bağımsızlığı, farklı önyüzlerde kullanım imkanı, modüler geliştirme imkanı gibi konular sözkonusu iken, küçük çaplı yazılım projelerinde bu tür özelliklere ihtiyaç olmayabilir. (Burada küçük çaplıdan kasıt, bir kere yapılacak ve minimum değişiklik ile o şekilde kullanılacak bir yazılımdır. Eğer aynı tür bir sürü küçük çaplı iş yapılıyorsa, bunları bileştirip, iş yükünü azaltacak bir yapının kurulması ve bu yapıya artık orta- büyük çaplı bir yapı gibi gözlemlemek doğru olacaktır.)

Küçük çaplı projeler için Java kullanmak, eğer elde kullanılabilecek mevcut modüller – objeler yok ise, fuzuli masraf olabilir. Yapılacak çalışmalar yapılırsa gereksiz yere fazla kod yazılmış olabilir, bunlar kullanılmadan, düşük seviye bir yazılımcının yapabileceği bir işi üst seviye bir yazılımcı yapıyor ise, hem eleman maliyeti hemde çalışanın iş tatmini açısından sıkıntılar doğurabilir. Dotnet, böyle bir proje için daha uygundur.

Orta – Büyük çaplı projeler için (Orta ve büyük çaplı proje nedir, bu konuda da bir karar varmış olmak gerekir, sadece satır sayısı veya ekran sayısı bunun için ölçüt olmayabilir. Burada tecrübe karar verirken önemli bir etkendir.) daha gelişmiş yapılara ihtiyaç duyulacağından, Java ve üst düzey yazılım daha uygun gözükmektedir. Java için bir veya birden çok frameworkün bu yapı için kullanılması projenin daha az maliyetle bitirilebilmesi için çok önemli bir husustur.

Frameworkler

Frameworkler, yazılım işini çok hızlandırabilir.

Framework’ü tanımlamak istersek, bazı ihtiyaç duyulan özelliklerin bir yapı tarafından sağlanması, doğru yazılım geliştirme prensiplerine yazılımcıları zorlayabilecek, bazı şeyler için hayatı kolaylaştırıp süreyi kısaltabilecek bir yapı olarak tanımlayabiliriz.

Dotnetin kendi içerisindeki frameworkler (Windows forms, asp.net vb) dışında, dotnet için yazılmış çok fazla framework yoktur. Genel olarak, kullanılan frameworkler daha önceden bahsedildiği gibi rdbms ilişkisini sağlayan frameworklerdir. Daha ciddi yapılar çoğunlukla, Java da kullanılan frameworklerin dotnete çevirilmiş şeklidir. Örnek olarak, Maverick.net, Spring.net, nhibernate vb. java frameworklerinin dotnette kullanmak isteyenler tarafından dotnete çevirilmiş versiyonlarıdır. Burada dezavantaj, dokümantasyonun java’da daha düzgün olması, dotnet versiyonlarının Java versiyonlarını geriden takip etmesidir. Ancak dotnet ile uğraşan yazılımcıların çoğu bu frameworklerden bihaberdir, Microsoft da kendi yazdığı frameworkler dışındakiler yokmuş gibi davranmaktadır.

Java için birçok framework mevcuttur, java yazılımcıları en az 1-2 sini kullanmıştır.

Frameworklerin seçimi çok zor bir konudur, tüm yazılım kararlarını etkiler. İyi araştırıp düşünülmesi gerekir. Java framework Örnekleri,

- Web için, Struts, Tapestry, Java Server Faces

- Client Application için Swing

- Kod üretme için Xdoclet

- Data mapping için hibernate

- Kural implementasyonu için Drools

- Flash üretebilmek için openlazslo

- Inversion of container için Spring

gibi frameworklerdir. Çok çeşitli konular için Java için framework’ ler mevcuttur. Ayrıca bunların çoğunluğu için yazılım testleri framework’ leri ve ideler yazılmış durumdadır. Dotnet için bu destek pek mevcut değildir.

Yazılım Geliştirme Ortamları – Ideler

Diğer hususlardaki genel görünüş burada da mevcuttur. Dotnet için hazır paket olarak sunulan Visual Studio eğer farklı bir ihtiyaç duyulmaz ise çok verimli ve güzel bir tooldur. Yalnız şunu belirtmekte fayda var, bazı şeyler beginner kullanıcıya yönelik olarak optimize edilmiştir, html de default fixed koordinatlar vermesi, eventleri otomatik olarak bağlaması gibi. Bu seviyelere uygun olarak kullanımında, hızlı yazılım geliştirme imkanı verir.

Java için birçok editor vardır, bunların arasından Eclipse ilk bakışta karşımıza çıkacak olan editordur. Çok farklı ihtyiaçlara cevap verebilir, çok değişik şekillerde ihtiyaca göre düzenlenebilir, ancak öğrenilmesi zaman alabilir ve yeni özelliklerinin eklenmesi bilgi ve araştırma gereken bir husus olabilir.

Gerekli ayarlamalar ve düzenlemeler yapılır ise, Eclipse’in Visual Studiodan daha avantajlı olduğu kanaatindeyim. Visual Studio 2005 sürümü ile Eclipse’e yaklaşmaya başladıysa da, open source olan Eclipse topluluğu, birbirinden bağımsız değişik modüller üretilen binlerce yazılımcı tarafından sürekli yeni bir şeylerin yapıldığı bir platform ve Visual Studio’nun her gün yenilenen Eclipse plug-in’leriyle başa çıkamayacağı görüşündeyim.

Performans

Performans düşünüldüğünde, genel olarak izlenim, Javanın dotnete göre daha yavaş olduğudur. Aslında mekanizma olarak, ikisi de derleme esnasında makine diline değil, orta seviye bir dile dönüşüm yapıp çalışma zamanında makine diline çevrim yapar. Yapı olarak fazla fark yoktur. İkisinin de bir makine üzerinde çalışması için bir yüklemeye ihtiyacı olur (dotnetin istediği yükleme miktarı 100mb civarı iken java 5 mb civarında). Bu durumda, aynı işlemi yapan aynı yapıya oturtulmuş Java ve Dotnet versiyonundan hangisinin daha hızlı olduğu tartışılabilecek bir konu iken, genel görüş Dotnetin daha hızlı olacağıdır.

Şu da unutulmamalıdır ki, performans konusunda genelde hak ettiğinden daha fazla önem verilmektedir. Performans ile ilgili makalem için tıklayınız.

Sonuç

Sonuç olarak, yazılım testi, nesneye dayalı programlama, birbirinden ayrık birleştirilebilen yapılar, tasarım kalıpları, kaliteli yazılım üretilecek, debug süresinin önemli olduğu, değişiklik maliyetinin sıkıntı yaratabileceği durumlarda, kısacası orta-büyük ölçekli projelerde Java’nın bir framework’le beraber kullanılmasının daha doğru olduğu kanaatindeyim. Küçük projeler için ise dotnet kullanılabilir, ancak kurum içerisinde mevcut tekrar kullanılabilir yapıların da bunun üzerinde etkisi olabilir.

Ancak, buradan yanlış anlaşılma sonucu çıkarılabilecek bir sonuç ile ilgili bir uyarı yapmak isterim, Java ‘da yazılan kod ne olursa olsun Dotnet’ten üstündür gibi bir yaklaşım doğru değildir. Yanlış yazılım geliştirme yaklaşımlarının uygulandığı bir proje, hangi dil olursa olsun, maliyeti yüksek olacaktır.