SQL Server 2000 için, enterprise manager kullanımında, bağlanılan server üzerinde çok sayıda veritabanı var ise (benim sorunla karşılaştığım rakam 80 tane idi) enterprise managerin veritabanlarını listeleme süresi çok uzayabilir veya hiç listelemeyebilir. (Karşılaştığım durum 3,5 saatti)
Microsoft SQL Serverin enterprise manager ile ilgili bir bug’ı mevcuttur. Bu bug, veritabanı listesinin açılmasını engellemekte veya çok geciktirmektedir.
Bugin çözümü ile ilgili Microsoft dokümanı :
http://support.microsoft.com/kb/282416/EN-US/
Durumun çözümü için serverin olduğu makina ve bağlanan client makinalarda service packlerin yüklenmesi gerekmektedir.
Ancak dikkat edilmesi gereken husus server versiyonunun personal edition değil standard veya enterprise edition olmasıdır. Eğer personal edition yüklü ise service pack işe yaramayacaktır.
Bir serverin üzerinde service pack in yüklü olup olmadığının anlaşılması ve edition bilgisi
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
Şeklinde alınabilir.
Sonuç olarak, öncelikle server ve client editionları kontrol edilip emin olunur, sonra service pack yüklenir ise sorun çözülür.
Cuma, Kasım 10, 2006
Salı, Ekim 31, 2006
Extreme Programming İncelemesi - Avantaj ve Dezavantajları
Extreme programming'in çoğu özelliği cazip gelse de, genel olarak bazı şeyler her zaman havada kalmıştı.
Teorik bilgiler sürekli olarak gerçekte olmayan bir proje ile ilgili idi ve başlarda biraz ütopik geldiğini itiraf etmeliyim.
Özellikle pair programming'in yönetici ve firma sahiplerini ürküttüğü bir gerçek, tek işi yapması için iki kişiye maaş ödemek ülkemiz koşulları için fazla iddialı gözüken bir uygulama.
1. Test Test ile ilgili genel makale için tıklayınız.
Test konusunda yöneticiler açısından çok katı bir yaklaşım bulunmakta, eğer iş gereksinimleri arasında testler yok ise veya hayati önem taşıyan bazı embedded sistemler sözkonusu değil ise, uygulayan kuruluş sayısı yok denecek kadar az.
Temel sebep, testin aslında gereksiz olduğunun düşünülmesidir. Sonuçta, yazılımsal testler, unit test vs., yazılımı direkt etkilemeyen şeyler arasında, bazı görüşler testlerin fazla idealist ve akademi yaklaşımı olduğunu savunmaktadır. Bu konuyu yöneticilere kabul ettirmek çok zor.
Extreme programming içerisindeki test yaklaşımı ise, genel olarak, sistemin testlerinin tümünün aynı yerde olması şeklinde. Yani, unit test, integration test, acceptance test gibi değişik testler değil, sadece bir tane test var, o da sistemi komple test ediyor.
Bence bu yaklaşımın avantajları ve dezavantajları var, testlerin ayrı olmaması, sistemin tamamının test edilebilirliğini artırıyor, ayrıca, bu şekilde test yazmak, ayrı ayrı testler yazmaktansa nispeten daha kolay ve daha az zaman alan bir iş.
Dezavantajlarına gelince, extreme programming veya agile metodolojilerin tümü gibi, testler, sadece üzerinde çalışılan sistem için geçerli. Yani sistemin bir parçasını alıp başka bir uygulamada kullanmanız durumunda - ki tamamiyle agile gidiyorsanız bu ne kadar olası o da ayrı bir tartışma konusu - testler eski sistemle beraber atılmak zorunda kalınıyor. Bu da özellikle bu durum için sakınca teşkil eder, zira testlere en çok ihtiyaç duyacağınız zaman refactoring zamanı, yani yazılımın belli kısımlarını alıp yeni bir sistemle beraber çalışması için değiştirmek istiyorsanız, testler size hangi değişiklikte nereyi bozduğunuzu işaret ettiğinden, değişiklik çok daha hızlı ve hatasız yapılabilir.
Extreme ile gidiyorsanız, eski testleriniz tamamen işe yaramaz durumdadır.
2. Test Driven Development
Agile'ın yaygın uygulamalarından birisi, test driven developmenttir. Yani, önce yazılım testleri yazılır. Daha sonra bu testlere uyacak olan kodu yazarsınız. Bu testler, büyük çoğunlukla yazılımın gereksinimlerinden oluşur, ayrıca boundary condition gibi durumlar da test edilir. Testler, sistemin çalıştığı zaman karşılaması gerektiği özelliklerin çerçevesini çizmiş olur. Daha sonra, bu testleri geçecek uygulama kodu yazılmaya başlanır. Class tanımlamaları dahi, önce bir miktar test yazıldıktan sonra yapılır.
Önce test yaklaşımından kasıt, testlerin tamamı bittikten sonra kodlamaya geçiş değildir, ki zaten agile practicelerde bir şeyin tamamını implement etmek gibi bir durum olamaz. Burada önemli olan nokta, önce bir miktarda olsa test kodu yazıp sonra o test kodunu geçecek kodu oluşturmak sonra tekrar test yazmaktır.
Test driven development ile yazılım geliştirmeyi biraz denedikten sonra hakikaten çok zevkli bir yöntem olduğunu hissettiğimi söylemem gerekir.
Bu yaklaşım her zaman kafamda bir takım sorular bıraktı. Öncelikle, mimari ile ilgili bir takım endişelerim vardı, test driven development yaparken nasıl mimari kurulabilir ? Buna agile takip edenlerin cevabı, refactoring esnasında olacaktır. Kod yazıldıktan sonra, kod yazma süreci içerisinde, kısa aralıklara, süreç içerisinde olan refactoring yapılması extreme in uygulamalarından bir tanesidir. Bu seanslar içerisinde kodun kendi kendisine şekilleneceği ve sistemin bir mimariye sahip olacağı şeklinde bir açıklamadır. Bunun sistemin ufak kısımları için olası olduğunu, ancak büyük çaplı değişiklikler, yani sistemin tamamını etkileyecek değişikliklerin bu yolla yapılamayacağı gibi bir gözlemim var.
Ayrı seanslar olarak yapılan mimari çalışmalar, unified processde olduğu gibi, kodu daha derli toplu tutarak merkezi bir kontrol sağlamakla beraber, software architect türü kişilerin bu işi yapmasına olanak sağlıyor. Extreme için koç roluü dışında tüm roller yazılımcı rolüdür, dolayısı ile bir kişinin diğerleri üzerinde bilgi üstünlüğü veya sistemi değiştirme yetkisinin olması pek yaygın bir anlayış değildir.
Başka bir durumda, test driven gidildiği zaman, extremein çoğu prensibinde karşılaşılan reuse sıkıntısıdır. Mevcutta hazır bir kod kütüphaneniz var ise test driven ile bunu hayata geçirmeniz pek mümkün değildir, çünkü her projede kod o anki ihtiyaçlara göre tekrar yazıldığından, hazır componentların implementasyonu düşünülmez.
Ayrıca, agile mantığı içerisinde olan o anda ihtiyaç olmayan özellikleri yazılıma eklememe mantığı ile gidildiği için sadece o kısımın sorunlarını çözecek olan bir kod parçası yazılacağından bu şekilde yazılan kodun tekrar kullanılabilme olasılığının çok az olmasının yanısıra, böyle üretilen uygulamaların, üretimi isteyen kurum dışında başlka kurumda implementasyonu da çok zordur, çünkü direk o kurum ihtiyaçlarına göre dikilmiş bir elbisedir.
3. Pair Programming
Pair programming, kavram olarak, iki yazılımcının bir bilgisayar karşına geçip, sırayla klavyeyi almaları ve kod yazmaları şeklindedir. Bu çiftteki kişilerin ikisi birden aynı anda kod yazamaz, yazmamalıdır. Birisi yazarken diğeri onu seyretmelidir. Tabii bu klavye değiştirme aralığı çok uzun bir aralık olmamalı, mesela 15er dakika ara ile yer değiştirilmelidir.
Uygulama esnasında, bir pair çalışmasında, bir kişinin test yazıp diğer kişinin kod ile bu testi geçtiği, daha sonra diğer kişinin başka bir test yazıp kod yazan kişinin tekrar onu geçmeye çalıştığı, daha sonra yerlerini değiştirdikleri bir uygulama gördüm. 3 er dakika ara ile klavye değiştiriyorlardı, ve aradaki tatlı rekabet gerçekten korkunç bir iş tatmini sağlıyordu.
Tek bir yazılımcının performansının pair performansı yanında 1/4 oranında olduğu kanaatindeyim, henüz bunu destekleyecek deneysel verilerim olmasa da, yazılım yaptığım süre boyunca, yanımda bir arkadaşımla beraber yaptığım herhangi bir çalışma esnasında, farkettim ki, daha kolay düşünebiliyor ve daha az kilitlenmeler yaşıyorum. Tek başıma kolayca çözemediğim bazı noktalarda çok hızlı sonuca gitmem mümkün oldu.
Kod yazma esnasında yazılımcı kendisini o andaki koda kaptırır ve sistemin tamamını düşünmeye çalıştığı zaman, biraz büyük yazılımlar için, kilitlenme noktasına gelir. Extreme deki uygulama, bir kişinin sistemin o anki durumuna odaklanırken diğerinin aynı zamanda sistemin tümünü de düşünüyor olmasıdır.
Pair programming esnasında, sürekli olarak aynı pairlerle çalışılmaz, eş değiştirme olayı sürekli devam eder. Yani iyi anlaşan iki kişinin sürekli bir arada olma ihtimali yoktur, ekip içerisinde sürekli bir pair sirkülasyonu vardır. Bu sayede, bir pair şu kodu ben yazdım diye bir iddiada bulunmaz, kod tüm ekibindir ve Extremein prensiplerinden biri olan kod sahipliğinin olmaması durumunu bu şekilde sağlanır.
Eş değiştirme esnasında, herkes sistemin tamamını öğrenir ve hiçbir bilgi ekipte belirli kişilerde kalmaz.
Bu durumun bir dezavantajı, kimsenin özelleşemeyecek olmasıdır. Persistence konusunda özelleşmiş kişiler veya prezentasyon konusunda özelleşmiş kişilerin getirebileceği hız ve avantajlardan mahrum kalınmış olur.
Pair programming in başka bir avantajı, proje esnasında hızlı bir eğitim sağlamasıdır. Ekibe dahil olan acemi yazılımcı, ustaların arasında çalışarak, beraber pair yapıldığı esnada, eğitimde dahi öğrenilemeyecek bazı bilgiler edinir. Çok kısa bir sürede acemi elemanlar iş yapabilecek düzeye ulaşır.
Aynı şekilde projeye yeni katılmış elemanlarda bir süre dolaştıktan sonra kod bilgisine sahip olmaya başlar. Kod sahipliği olmaması ile beraber bu özellik, extremei riskleri minimuma indirme açısından avantajlı yapar, zira en büyük sorunlardan birisi, bir projenin ortasında bazı elemanların ayrılması ile onların yapıtğı tarafın öğrenme sürecine girilme gereksinimi, elemanların ayrılmaması için astronomik maaşlar veya tavizler, en kötüsü projenin tamamen iptali veya kodun baştan yazılması gibi riskler ortadan kaldırılmış olur.
Ekip sürekli sirkülasyon halinde çalıştığı için, daha iyi bir kaynaşma mümkündür. Ekipin bağları daha sıkılaşır. Bu da gerçek ekip çalışmasına sebep olabilir. Tabii bu ekibin içerisine dahil olabilecek ve yazılım sektöründe çok sık görülen 007 tipinde sadece yalnız çalışabilen insanların olması ekip bütünlüğünü ve pair programmingi olanaksızda kılabilir. Çalışan seçiminde bu çok ciddi gözönüne alınması gereken bir faktördür.
Pair programming extreme de uygulandığı şekliyle, özelleşmeyi desteklememesi ile fazla iddialı gelse de, genelde başarılı olarak gördüğüm bir uygulama. Yeter ki yönetimin desteği alınabilsin.
4. Müşteri İlişkileri
Extremein müşteri yaklaşımı kesinlikle en müşkülpesent müşteri ilişkileri departmanını dahi memnun edecek şekildedir, eski deyişle müşteri her zaman haklıdır yaklaşımı mevcuttur. Her şeyden önce, tüm süreç aslında müşteri tarafından yönlendirilir. Müşteri, yazılım ekibinin içerisinde çok uzun sürelerle yer almalı, belirli mesaisini buraya ayırıp sistemin gidişatını kontrol etmelidir. Bu sayede, yazılım projelerinde büyük sıklıkla oluşan müşteri istekleri ve yazılım yetenekleri dengesizliği ortadan kalkmış olacak, çünkü istenmeyen gibi olan bir kısım var ise anında müdahele edilme şans doğacaktır.
Bir prensipte, kodun sürekli derlenebilir ve uygulamanın sürekli çalışır halde olması olduğundan dolayı, müşteri her istediği an uygulamanın son halini çalıştırıp görebilecek, sonrasında düzelttiği yanlış anlaşılmalar veya kendi fikrindeki değişiklikleri implement ettirebilecek, aynı zamanda yazılım yaparken yazılımcının farkettiği bazı şeyleri dinleyerek sistemde buna göre değişiklik isteyebilecektir.
Burada karşılıklı güven esastır, iki tarafta birbirini kandırmaya veya suistimal etmeye kalkmamalıdır.
Burada en önemli soru, ödemenin nasıl yapılacağı ve iş yükünün nasıl kaldırılabileceğidir. Buna cevap da planlama safhasından gelir. Bir özellik eklenmesi istendiğinde, sürecin en başından itibaren, bu özelliğin tahmini süresi ortaya çıkarılır ve iterasyon denilen uygulama versiyon bitişine kadar ekibin ne kadar sürelik iş yapacağı belirlenir .
Ödeme, süreye bağlı olarak olur. Müşteri istediği özellikleri belirtir ve ekip bunun ne kadar sürede yapılabileceğini iletir. Yazılım ilerledikçe müşteri istediği anda süreci kesip bu bana yeterli diyebilir veya yeni özellik isteyebilir. Çalışılan süre kadar ödeme yapılır. Tabii bu durum, ihale gibi işlerde bu yöntemin kullanımını imkansız kılıyor, ayrıca karşıdaki müşterinin iyi niyetini sağlamak da işi yapan firmanın görevidir, öncelikle kendisine güvendirmesi gerekir.
İşi yaptıranın gerçek bir müşteri olmaması durumunda, paket program vs gibi yazılımlarda, müşteri olarak birisi seçilir, bu satış departmanından birisi olabilir, müşteri gibi davranarak onun yerine geçer.
Bu yaklaşımı doğru buluyorum, zira artık devir yazılım sahibinin istediğini yaptığı devir değil, öyle bir devir vardı, yazılımcının az ve müşterilerin temel ihtiyaçlarının dahi karşılanamadığı bir devir, ancak artık rekabet çok ve müşterinin kaçması çok kolaylaştı.
Devam edeceğimi umuyorum, tembellikte yapabilirim :)
Teorik bilgiler sürekli olarak gerçekte olmayan bir proje ile ilgili idi ve başlarda biraz ütopik geldiğini itiraf etmeliyim.
Özellikle pair programming'in yönetici ve firma sahiplerini ürküttüğü bir gerçek, tek işi yapması için iki kişiye maaş ödemek ülkemiz koşulları için fazla iddialı gözüken bir uygulama.
1. Test Test ile ilgili genel makale için tıklayınız.
Test konusunda yöneticiler açısından çok katı bir yaklaşım bulunmakta, eğer iş gereksinimleri arasında testler yok ise veya hayati önem taşıyan bazı embedded sistemler sözkonusu değil ise, uygulayan kuruluş sayısı yok denecek kadar az.
Temel sebep, testin aslında gereksiz olduğunun düşünülmesidir. Sonuçta, yazılımsal testler, unit test vs., yazılımı direkt etkilemeyen şeyler arasında, bazı görüşler testlerin fazla idealist ve akademi yaklaşımı olduğunu savunmaktadır. Bu konuyu yöneticilere kabul ettirmek çok zor.
Extreme programming içerisindeki test yaklaşımı ise, genel olarak, sistemin testlerinin tümünün aynı yerde olması şeklinde. Yani, unit test, integration test, acceptance test gibi değişik testler değil, sadece bir tane test var, o da sistemi komple test ediyor.
Bence bu yaklaşımın avantajları ve dezavantajları var, testlerin ayrı olmaması, sistemin tamamının test edilebilirliğini artırıyor, ayrıca, bu şekilde test yazmak, ayrı ayrı testler yazmaktansa nispeten daha kolay ve daha az zaman alan bir iş.
Dezavantajlarına gelince, extreme programming veya agile metodolojilerin tümü gibi, testler, sadece üzerinde çalışılan sistem için geçerli. Yani sistemin bir parçasını alıp başka bir uygulamada kullanmanız durumunda - ki tamamiyle agile gidiyorsanız bu ne kadar olası o da ayrı bir tartışma konusu - testler eski sistemle beraber atılmak zorunda kalınıyor. Bu da özellikle bu durum için sakınca teşkil eder, zira testlere en çok ihtiyaç duyacağınız zaman refactoring zamanı, yani yazılımın belli kısımlarını alıp yeni bir sistemle beraber çalışması için değiştirmek istiyorsanız, testler size hangi değişiklikte nereyi bozduğunuzu işaret ettiğinden, değişiklik çok daha hızlı ve hatasız yapılabilir.
Extreme ile gidiyorsanız, eski testleriniz tamamen işe yaramaz durumdadır.
2. Test Driven Development
Agile'ın yaygın uygulamalarından birisi, test driven developmenttir. Yani, önce yazılım testleri yazılır. Daha sonra bu testlere uyacak olan kodu yazarsınız. Bu testler, büyük çoğunlukla yazılımın gereksinimlerinden oluşur, ayrıca boundary condition gibi durumlar da test edilir. Testler, sistemin çalıştığı zaman karşılaması gerektiği özelliklerin çerçevesini çizmiş olur. Daha sonra, bu testleri geçecek uygulama kodu yazılmaya başlanır. Class tanımlamaları dahi, önce bir miktar test yazıldıktan sonra yapılır.
Önce test yaklaşımından kasıt, testlerin tamamı bittikten sonra kodlamaya geçiş değildir, ki zaten agile practicelerde bir şeyin tamamını implement etmek gibi bir durum olamaz. Burada önemli olan nokta, önce bir miktarda olsa test kodu yazıp sonra o test kodunu geçecek kodu oluşturmak sonra tekrar test yazmaktır.
Test driven development ile yazılım geliştirmeyi biraz denedikten sonra hakikaten çok zevkli bir yöntem olduğunu hissettiğimi söylemem gerekir.
Bu yaklaşım her zaman kafamda bir takım sorular bıraktı. Öncelikle, mimari ile ilgili bir takım endişelerim vardı, test driven development yaparken nasıl mimari kurulabilir ? Buna agile takip edenlerin cevabı, refactoring esnasında olacaktır. Kod yazıldıktan sonra, kod yazma süreci içerisinde, kısa aralıklara, süreç içerisinde olan refactoring yapılması extreme in uygulamalarından bir tanesidir. Bu seanslar içerisinde kodun kendi kendisine şekilleneceği ve sistemin bir mimariye sahip olacağı şeklinde bir açıklamadır. Bunun sistemin ufak kısımları için olası olduğunu, ancak büyük çaplı değişiklikler, yani sistemin tamamını etkileyecek değişikliklerin bu yolla yapılamayacağı gibi bir gözlemim var.
Ayrı seanslar olarak yapılan mimari çalışmalar, unified processde olduğu gibi, kodu daha derli toplu tutarak merkezi bir kontrol sağlamakla beraber, software architect türü kişilerin bu işi yapmasına olanak sağlıyor. Extreme için koç roluü dışında tüm roller yazılımcı rolüdür, dolayısı ile bir kişinin diğerleri üzerinde bilgi üstünlüğü veya sistemi değiştirme yetkisinin olması pek yaygın bir anlayış değildir.
Başka bir durumda, test driven gidildiği zaman, extremein çoğu prensibinde karşılaşılan reuse sıkıntısıdır. Mevcutta hazır bir kod kütüphaneniz var ise test driven ile bunu hayata geçirmeniz pek mümkün değildir, çünkü her projede kod o anki ihtiyaçlara göre tekrar yazıldığından, hazır componentların implementasyonu düşünülmez.
Ayrıca, agile mantığı içerisinde olan o anda ihtiyaç olmayan özellikleri yazılıma eklememe mantığı ile gidildiği için sadece o kısımın sorunlarını çözecek olan bir kod parçası yazılacağından bu şekilde yazılan kodun tekrar kullanılabilme olasılığının çok az olmasının yanısıra, böyle üretilen uygulamaların, üretimi isteyen kurum dışında başlka kurumda implementasyonu da çok zordur, çünkü direk o kurum ihtiyaçlarına göre dikilmiş bir elbisedir.
3. Pair Programming
Pair programming, kavram olarak, iki yazılımcının bir bilgisayar karşına geçip, sırayla klavyeyi almaları ve kod yazmaları şeklindedir. Bu çiftteki kişilerin ikisi birden aynı anda kod yazamaz, yazmamalıdır. Birisi yazarken diğeri onu seyretmelidir. Tabii bu klavye değiştirme aralığı çok uzun bir aralık olmamalı, mesela 15er dakika ara ile yer değiştirilmelidir.
Uygulama esnasında, bir pair çalışmasında, bir kişinin test yazıp diğer kişinin kod ile bu testi geçtiği, daha sonra diğer kişinin başka bir test yazıp kod yazan kişinin tekrar onu geçmeye çalıştığı, daha sonra yerlerini değiştirdikleri bir uygulama gördüm. 3 er dakika ara ile klavye değiştiriyorlardı, ve aradaki tatlı rekabet gerçekten korkunç bir iş tatmini sağlıyordu.
Tek bir yazılımcının performansının pair performansı yanında 1/4 oranında olduğu kanaatindeyim, henüz bunu destekleyecek deneysel verilerim olmasa da, yazılım yaptığım süre boyunca, yanımda bir arkadaşımla beraber yaptığım herhangi bir çalışma esnasında, farkettim ki, daha kolay düşünebiliyor ve daha az kilitlenmeler yaşıyorum. Tek başıma kolayca çözemediğim bazı noktalarda çok hızlı sonuca gitmem mümkün oldu.
Kod yazma esnasında yazılımcı kendisini o andaki koda kaptırır ve sistemin tamamını düşünmeye çalıştığı zaman, biraz büyük yazılımlar için, kilitlenme noktasına gelir. Extreme deki uygulama, bir kişinin sistemin o anki durumuna odaklanırken diğerinin aynı zamanda sistemin tümünü de düşünüyor olmasıdır.
Pair programming esnasında, sürekli olarak aynı pairlerle çalışılmaz, eş değiştirme olayı sürekli devam eder. Yani iyi anlaşan iki kişinin sürekli bir arada olma ihtimali yoktur, ekip içerisinde sürekli bir pair sirkülasyonu vardır. Bu sayede, bir pair şu kodu ben yazdım diye bir iddiada bulunmaz, kod tüm ekibindir ve Extremein prensiplerinden biri olan kod sahipliğinin olmaması durumunu bu şekilde sağlanır.
Eş değiştirme esnasında, herkes sistemin tamamını öğrenir ve hiçbir bilgi ekipte belirli kişilerde kalmaz.
Bu durumun bir dezavantajı, kimsenin özelleşemeyecek olmasıdır. Persistence konusunda özelleşmiş kişiler veya prezentasyon konusunda özelleşmiş kişilerin getirebileceği hız ve avantajlardan mahrum kalınmış olur.
Pair programming in başka bir avantajı, proje esnasında hızlı bir eğitim sağlamasıdır. Ekibe dahil olan acemi yazılımcı, ustaların arasında çalışarak, beraber pair yapıldığı esnada, eğitimde dahi öğrenilemeyecek bazı bilgiler edinir. Çok kısa bir sürede acemi elemanlar iş yapabilecek düzeye ulaşır.
Aynı şekilde projeye yeni katılmış elemanlarda bir süre dolaştıktan sonra kod bilgisine sahip olmaya başlar. Kod sahipliği olmaması ile beraber bu özellik, extremei riskleri minimuma indirme açısından avantajlı yapar, zira en büyük sorunlardan birisi, bir projenin ortasında bazı elemanların ayrılması ile onların yapıtğı tarafın öğrenme sürecine girilme gereksinimi, elemanların ayrılmaması için astronomik maaşlar veya tavizler, en kötüsü projenin tamamen iptali veya kodun baştan yazılması gibi riskler ortadan kaldırılmış olur.
Ekip sürekli sirkülasyon halinde çalıştığı için, daha iyi bir kaynaşma mümkündür. Ekipin bağları daha sıkılaşır. Bu da gerçek ekip çalışmasına sebep olabilir. Tabii bu ekibin içerisine dahil olabilecek ve yazılım sektöründe çok sık görülen 007 tipinde sadece yalnız çalışabilen insanların olması ekip bütünlüğünü ve pair programmingi olanaksızda kılabilir. Çalışan seçiminde bu çok ciddi gözönüne alınması gereken bir faktördür.
Pair programming extreme de uygulandığı şekliyle, özelleşmeyi desteklememesi ile fazla iddialı gelse de, genelde başarılı olarak gördüğüm bir uygulama. Yeter ki yönetimin desteği alınabilsin.
4. Müşteri İlişkileri
Extremein müşteri yaklaşımı kesinlikle en müşkülpesent müşteri ilişkileri departmanını dahi memnun edecek şekildedir, eski deyişle müşteri her zaman haklıdır yaklaşımı mevcuttur. Her şeyden önce, tüm süreç aslında müşteri tarafından yönlendirilir. Müşteri, yazılım ekibinin içerisinde çok uzun sürelerle yer almalı, belirli mesaisini buraya ayırıp sistemin gidişatını kontrol etmelidir. Bu sayede, yazılım projelerinde büyük sıklıkla oluşan müşteri istekleri ve yazılım yetenekleri dengesizliği ortadan kalkmış olacak, çünkü istenmeyen gibi olan bir kısım var ise anında müdahele edilme şans doğacaktır.
Bir prensipte, kodun sürekli derlenebilir ve uygulamanın sürekli çalışır halde olması olduğundan dolayı, müşteri her istediği an uygulamanın son halini çalıştırıp görebilecek, sonrasında düzelttiği yanlış anlaşılmalar veya kendi fikrindeki değişiklikleri implement ettirebilecek, aynı zamanda yazılım yaparken yazılımcının farkettiği bazı şeyleri dinleyerek sistemde buna göre değişiklik isteyebilecektir.
Burada karşılıklı güven esastır, iki tarafta birbirini kandırmaya veya suistimal etmeye kalkmamalıdır.
Burada en önemli soru, ödemenin nasıl yapılacağı ve iş yükünün nasıl kaldırılabileceğidir. Buna cevap da planlama safhasından gelir. Bir özellik eklenmesi istendiğinde, sürecin en başından itibaren, bu özelliğin tahmini süresi ortaya çıkarılır ve iterasyon denilen uygulama versiyon bitişine kadar ekibin ne kadar sürelik iş yapacağı belirlenir .
Aslında bu konu biraz detaylı, çünkü her ekip aynı sürede işi yapamayacağı gibi, genelde yapılan işler birbirlerine de benzemez, o yüzden yazılımda en sıkıntılı şeylerden biri süre tespitidir. Extreme in bu konudaki çözümü, özelliklere süre değil puan vermek ve ilk safhalarda tespit edilen ne kadar sürede ne kadar puanlık iş yapıldığını tespit ettikten sonra belirli süreler için puan miktarında göre yapılacak işleri kararlaştırmaktır. Puanlama yazılım ekibi tarafından yapılsa da, o süre için yapılacak işlerin seçimi müşteri tarafından yapılır.
Ödeme, süreye bağlı olarak olur. Müşteri istediği özellikleri belirtir ve ekip bunun ne kadar sürede yapılabileceğini iletir. Yazılım ilerledikçe müşteri istediği anda süreci kesip bu bana yeterli diyebilir veya yeni özellik isteyebilir. Çalışılan süre kadar ödeme yapılır. Tabii bu durum, ihale gibi işlerde bu yöntemin kullanımını imkansız kılıyor, ayrıca karşıdaki müşterinin iyi niyetini sağlamak da işi yapan firmanın görevidir, öncelikle kendisine güvendirmesi gerekir.
İşi yaptıranın gerçek bir müşteri olmaması durumunda, paket program vs gibi yazılımlarda, müşteri olarak birisi seçilir, bu satış departmanından birisi olabilir, müşteri gibi davranarak onun yerine geçer.
Bu yaklaşımı doğru buluyorum, zira artık devir yazılım sahibinin istediğini yaptığı devir değil, öyle bir devir vardı, yazılımcının az ve müşterilerin temel ihtiyaçlarının dahi karşılanamadığı bir devir, ancak artık rekabet çok ve müşterinin kaçması çok kolaylaştı.
Devam edeceğimi umuyorum, tembellikte yapabilirim :)
Pazartesi, Ekim 02, 2006
Yazılım Sektörü ve İnsan Kaynakları
Diğer üretim sektörlerine bakacak olursak, maliyet düşürme ve hızlı iş yapabilme, akıllı bir yatırımcının ön şart olmasıyla beraber, yatırım miktarındadır. Bu yatırımın çok büyük bir kısmı, üretimde kullanılan sistemlerin alınması, tezgahların makinaların yani otomasyonun kullanımı ile doğru orantılıdır.
Sanayileşme ile beraber gelen bu yaklaşım, işçilerin azaltılması ile üretim maliyetinin düşürülüp hızlı ve ucuz iş yapabilme sonrasında rekabet gücü getirir. (Her ne kadar Çin'de tersi olsa da, bir süre sonra orada da işçi maaşlarının maliyeti artırıcı bir faktör olacağı kanaatindeyim.)
Böyle bir kuruluş sonrasında, artık işletmecinin ihtiyaç duyduğu kaynak bu makinaları düzgün çalıştıracak elemanlardır. Makinalar düzgün çalıştığı takdirde üretim devam eder.
Yazılım sektörü için, her ne kadar ofis yerleşimi, kullanılan yardımcı yazılımlar, bilgisayarlar vb etkili ise de, diğer sektörlerle kıyaslanamaz dahi. Belki yazılım diğer sektörlere göre emekleme aşamasında olduğundandır, sonuçta diğer üretim dalları yüzyıllardan beri gelen bir birikimin sonucundaki bilgileri kullanmaktadır. Yakın gelecekte de bunun değişeceği gözükmediği için, insan kaynaklarına ve iletişime biraz daha önem verip eğilmeliyiz düşüncesindeyim.
Bu konuyu iki kısımda incelemek istiyorum. Birinci kısımda, kişi farklılıklarının performansta sağlayacağı etkiler, ikinci kısımda ise ekip çalışması ve iletişimin önemine değinmeye çalışacağım.
Birinci Bölüm - Yazılımcı Performansı
Yazılım süreçleri, zamanlama ve çalışanlar ile ilgili konuların ele alındığı Mythical Man Month isimli kitapta, yazılımcılar arasındaki farka değinir.
Elde edilen verilerden, deneyimli ve başarılı bir yazılımcının diğerine oranla 20 kat hızlı iş ortaya çıkarabildiği gözlenmiştir.
20 ye 1 korkunç bir rakam aslında, başka hiçbir üretim sektöründe karşılaşılamayacak bir rakam belki de. Bir fabrika için 1 işçinin 20 işçinin çıkardığı işi çıkarabildiği düşünülebilir mi ?
Bunu sektörde olan herkes gözlemlemiştir, iş kişiye çok bağımlıdır. Bu iki sorun ortaya çıkarır, birincisi bu kişinin ayrılması durumunda bilginin kurumda kalma zorluğu, ikincisi bu tür kişilerin az bulunur ve yüksek maaş talep eder kişiler olmasından dolayı diğer çalışanlar üzerinde oluşturacağı huzursuzluk ve işlerin bu kişiye çok bağımlı olması. Bu konulardan bahsetmeyeceğim.
Durum bu şekilde ise, 20 kişilik olmasa bile 5 kişilik iş yapacak bir kişinin 5 kişilik maaş alması da makul gözükmektedir.
Asıl sorun, bu kişilerin nasıl bulunup nasıl işe alınacağıdır. Teknik bilgisi üstün olan kişilerin mülakatlarda çok başarılı olduğu söylenemez, bunun yanısıra insan ilişkileri kuvvetli olan kişilerin bir kısmının da teknik açıdan daha zayıf olabileceği ortadadır.
Ekip Çalışması
Yazılım için şu anda ve yakın gelecekte iş yapacak olan insandır ve daha çok iş yapmak isteyen daha fazla insana başvuracaktır. İnsan faktörü vazgeçilmez olarak gözükmektedir. Ancak, sektörün çoğunluğu ki en başta çalışanlar, işin aslında kod ile veya bilgisayar ile olduğunu düşünmektedir. Bu yaklaşımın doğru yanları olsa da, gözardı edilen en önemli nokta, iletişim ve insan kaynalarının diğer sektörlere göre çok daha önemli olduğudur.
Tabii tek kişilik projeler ile çalışan bir şirketten bahsedecek olursak bu geçerli olmaz, ancak iki kişi bir projeye girdiği andan itibaren bu yapılandırma önem kazanır. Teknik bilgisi çok yüksek olan ancak karşısına derdini anlatamayan veya geçinilemez kişilerin çok olduğu sektörümüzde, tek adamlar çok fazladır, sektördeki herkes bunu yaşamıştır.
Projelerdeki en büyük sıkıntılar iletişim sorunlarından kaynaklanmaktadır, zira bir ekip olarak çalışmasını bilmeyen alışanlar ve ekip olarak çalışılmasının önemini bilmeyen yöneticilerin olduğu sektörde bu konu gözardı edilmektedir.
Teknik temelli kişilerin çoğunluğunda bu tür konuları gözardı etme, iletişimin önemine inanmama veya böyle bir kavram olduğunu bilmeme gibi bir sorun mevcuttur. Eğitimde bunlara değinilmemesi sorunun bir bacağı olabilir.
Nasıl bir iş makinası kürekli ama çok güçlü bir adamın yapacağı işin yüzlerce katı fazla işi daha kolay yapabilirse, ekipler ve iş dağılımı ile aynı şekilde hızlı iş yapılabilir. Yaşanan sıkıntının ilki, özellikle yetkin kişilerin ekip içerisinde çalışmada sıkıntı çektikleri, daha az bilgili olan kişilerden sürekli biat ve itaat istedikleri gözlemlediğim şeylerden birisi, ki geçmişte bu şekilde davrandığım zamanlar çok oldu, sonrasında ekibe zarar verme ve işi ya tek başına yüklenme veya ekibin tamamıyla iş yapamaz hale gelmesi gibi durumlarla karşılaşılır.
Bunu engellemek için ekip çalışması eğitimleri bir araç olabilir, en büyük sorun önce mantığın değişmesi, bir tek adam'ın hiçbir zaman daha az yeteneklerde de olsa birçok adamı yenemeyeceğini kavramak, daha sonra iletişim ile ilgili bir takım bilgilerin alınması sayesinde tek adam olmaktan vazgeçmeye gönüllü ancak başaramayan kişilerin hangi yollarla bunu yapabileceğinin kendilerine gösterilmesidir.
Ancak bu tür disiplinlerden sonra bir ekip olunabilir. Bunlar bittabi bütün sektörlerin konularıdır, ancak yukarıda da belirttiğim gibi, yazılım sektörü en çok insana bağlı sektörlerden biri olduğu için bizim açımızdan elzem konulardır.
Sonuç
Burada belirttiklerim bu konulara ancak bir giriş olabilir, ayrıca detaylı bir çalışma gerektiren bir konudur. Gözardı edildiği müddetçe optimum performans hiçbir zaman yakalanamayacaktır.
İnsan kaynakları ve iletişim yazılım için elzemdir ve bu konu ile ilgili bilgisi olan kişilere ihtiyaç vardır, ancak teknik bilgisi olmayan kişiler özellikle eleman seçimi sırasında manipülasyona açık olduklarından bu bilgiye de sahip olunması çok önemlidir.
Yazılım ekipleri eğitilirken sadece teknik eğitimler verilmesi çok yanlıştır, teknik bilgi yol gösterildiği zaman kitaplardan da alınır, ancak beşeri bilgiler kitaplardan kolay anlaşılacak ve kişinin hayatı boyunca kazandığı yetileri değiştirecek kadar kuvvetli etki yapamaz.
Kurum her kademesinde iletişimi desteklemeli ve herşeyden önce çalışanlarının rahatını ve üretebilirlik performansını gözlemeli, performans düşüşlerini ve moral bozuklularını, aynı zamanda anlaşmazlık ve takım içi çatışmaları çok yakından takip etmelidir. Yöneticilerin asli görevleri arasında diğer sektörlerden daha fazla ihtimam gösterecek şekilde bulunmalı ve yöneticilier bu konuda yetkin kişiler olmalıdır.
Sıkıntı gözlemlendiği anda gözardı edilmeyerek müdahele edilmelidir. Böylece, çalışanların bakımı rutin yapılan ve performansı hep aynı seviyede çalışan üretim tesisleri gibi olmaları sağlanabilir.
Sanayileşme ile beraber gelen bu yaklaşım, işçilerin azaltılması ile üretim maliyetinin düşürülüp hızlı ve ucuz iş yapabilme sonrasında rekabet gücü getirir. (Her ne kadar Çin'de tersi olsa da, bir süre sonra orada da işçi maaşlarının maliyeti artırıcı bir faktör olacağı kanaatindeyim.)
Böyle bir kuruluş sonrasında, artık işletmecinin ihtiyaç duyduğu kaynak bu makinaları düzgün çalıştıracak elemanlardır. Makinalar düzgün çalıştığı takdirde üretim devam eder.
Yazılım sektörü için, her ne kadar ofis yerleşimi, kullanılan yardımcı yazılımlar, bilgisayarlar vb etkili ise de, diğer sektörlerle kıyaslanamaz dahi. Belki yazılım diğer sektörlere göre emekleme aşamasında olduğundandır, sonuçta diğer üretim dalları yüzyıllardan beri gelen bir birikimin sonucundaki bilgileri kullanmaktadır. Yakın gelecekte de bunun değişeceği gözükmediği için, insan kaynaklarına ve iletişime biraz daha önem verip eğilmeliyiz düşüncesindeyim.
Bu konuyu iki kısımda incelemek istiyorum. Birinci kısımda, kişi farklılıklarının performansta sağlayacağı etkiler, ikinci kısımda ise ekip çalışması ve iletişimin önemine değinmeye çalışacağım.
Birinci Bölüm - Yazılımcı Performansı
Yazılım süreçleri, zamanlama ve çalışanlar ile ilgili konuların ele alındığı Mythical Man Month isimli kitapta, yazılımcılar arasındaki farka değinir.
Elde edilen verilerden, deneyimli ve başarılı bir yazılımcının diğerine oranla 20 kat hızlı iş ortaya çıkarabildiği gözlenmiştir.
20 ye 1 korkunç bir rakam aslında, başka hiçbir üretim sektöründe karşılaşılamayacak bir rakam belki de. Bir fabrika için 1 işçinin 20 işçinin çıkardığı işi çıkarabildiği düşünülebilir mi ?
Bunu sektörde olan herkes gözlemlemiştir, iş kişiye çok bağımlıdır. Bu iki sorun ortaya çıkarır, birincisi bu kişinin ayrılması durumunda bilginin kurumda kalma zorluğu, ikincisi bu tür kişilerin az bulunur ve yüksek maaş talep eder kişiler olmasından dolayı diğer çalışanlar üzerinde oluşturacağı huzursuzluk ve işlerin bu kişiye çok bağımlı olması. Bu konulardan bahsetmeyeceğim.
Durum bu şekilde ise, 20 kişilik olmasa bile 5 kişilik iş yapacak bir kişinin 5 kişilik maaş alması da makul gözükmektedir.
Asıl sorun, bu kişilerin nasıl bulunup nasıl işe alınacağıdır. Teknik bilgisi üstün olan kişilerin mülakatlarda çok başarılı olduğu söylenemez, bunun yanısıra insan ilişkileri kuvvetli olan kişilerin bir kısmının da teknik açıdan daha zayıf olabileceği ortadadır.
Ekip Çalışması
Yazılım için şu anda ve yakın gelecekte iş yapacak olan insandır ve daha çok iş yapmak isteyen daha fazla insana başvuracaktır. İnsan faktörü vazgeçilmez olarak gözükmektedir. Ancak, sektörün çoğunluğu ki en başta çalışanlar, işin aslında kod ile veya bilgisayar ile olduğunu düşünmektedir. Bu yaklaşımın doğru yanları olsa da, gözardı edilen en önemli nokta, iletişim ve insan kaynalarının diğer sektörlere göre çok daha önemli olduğudur.
Tabii tek kişilik projeler ile çalışan bir şirketten bahsedecek olursak bu geçerli olmaz, ancak iki kişi bir projeye girdiği andan itibaren bu yapılandırma önem kazanır. Teknik bilgisi çok yüksek olan ancak karşısına derdini anlatamayan veya geçinilemez kişilerin çok olduğu sektörümüzde, tek adamlar çok fazladır, sektördeki herkes bunu yaşamıştır.
Projelerdeki en büyük sıkıntılar iletişim sorunlarından kaynaklanmaktadır, zira bir ekip olarak çalışmasını bilmeyen alışanlar ve ekip olarak çalışılmasının önemini bilmeyen yöneticilerin olduğu sektörde bu konu gözardı edilmektedir.
Teknik temelli kişilerin çoğunluğunda bu tür konuları gözardı etme, iletişimin önemine inanmama veya böyle bir kavram olduğunu bilmeme gibi bir sorun mevcuttur. Eğitimde bunlara değinilmemesi sorunun bir bacağı olabilir.
Nasıl bir iş makinası kürekli ama çok güçlü bir adamın yapacağı işin yüzlerce katı fazla işi daha kolay yapabilirse, ekipler ve iş dağılımı ile aynı şekilde hızlı iş yapılabilir. Yaşanan sıkıntının ilki, özellikle yetkin kişilerin ekip içerisinde çalışmada sıkıntı çektikleri, daha az bilgili olan kişilerden sürekli biat ve itaat istedikleri gözlemlediğim şeylerden birisi, ki geçmişte bu şekilde davrandığım zamanlar çok oldu, sonrasında ekibe zarar verme ve işi ya tek başına yüklenme veya ekibin tamamıyla iş yapamaz hale gelmesi gibi durumlarla karşılaşılır.
Bunu engellemek için ekip çalışması eğitimleri bir araç olabilir, en büyük sorun önce mantığın değişmesi, bir tek adam'ın hiçbir zaman daha az yeteneklerde de olsa birçok adamı yenemeyeceğini kavramak, daha sonra iletişim ile ilgili bir takım bilgilerin alınması sayesinde tek adam olmaktan vazgeçmeye gönüllü ancak başaramayan kişilerin hangi yollarla bunu yapabileceğinin kendilerine gösterilmesidir.
Ancak bu tür disiplinlerden sonra bir ekip olunabilir. Bunlar bittabi bütün sektörlerin konularıdır, ancak yukarıda da belirttiğim gibi, yazılım sektörü en çok insana bağlı sektörlerden biri olduğu için bizim açımızdan elzem konulardır.
Sonuç
Burada belirttiklerim bu konulara ancak bir giriş olabilir, ayrıca detaylı bir çalışma gerektiren bir konudur. Gözardı edildiği müddetçe optimum performans hiçbir zaman yakalanamayacaktır.
İnsan kaynakları ve iletişim yazılım için elzemdir ve bu konu ile ilgili bilgisi olan kişilere ihtiyaç vardır, ancak teknik bilgisi olmayan kişiler özellikle eleman seçimi sırasında manipülasyona açık olduklarından bu bilgiye de sahip olunması çok önemlidir.
Yazılım ekipleri eğitilirken sadece teknik eğitimler verilmesi çok yanlıştır, teknik bilgi yol gösterildiği zaman kitaplardan da alınır, ancak beşeri bilgiler kitaplardan kolay anlaşılacak ve kişinin hayatı boyunca kazandığı yetileri değiştirecek kadar kuvvetli etki yapamaz.
Kurum her kademesinde iletişimi desteklemeli ve herşeyden önce çalışanlarının rahatını ve üretebilirlik performansını gözlemeli, performans düşüşlerini ve moral bozuklularını, aynı zamanda anlaşmazlık ve takım içi çatışmaları çok yakından takip etmelidir. Yöneticilerin asli görevleri arasında diğer sektörlerden daha fazla ihtimam gösterecek şekilde bulunmalı ve yöneticilier bu konuda yetkin kişiler olmalıdır.
Sıkıntı gözlemlendiği anda gözardı edilmeyerek müdahele edilmelidir. Böylece, çalışanların bakımı rutin yapılan ve performansı hep aynı seviyede çalışan üretim tesisleri gibi olmaları sağlanabilir.
Cumartesi, Eylül 23, 2006
Nesneye Yönelik (Object Oriented) Yazılıma Geçiş
Nesneye yönelik yazılım ile ilk karşılaştığım zaman, çoğu kişinin tepkisine benzer olarak, ilginç gelmişti ancak bunun nasıl işime yerayacağı veya beni nasıl hızlandıracağı hakkında bilgi sahibi olamamıştım.
Ortada bir takım nesnelerin olması, iletişimi bunların kurması ve bu nesnelerin gerçek dünya benzeri davranışlar sergileyebilmeleri gerçekten ilginçti, ama vadedilen şeyler çok fazlaydı, bunlarda nesnelerin nasıl yardımcı olacağını veya nasıl başaracağını anlayamıyordum, sadece class tanımlayarak nasıl üstesinden gelinebilecekti ?
Üstelik, bu vaatlerin çoğunu ben zaten prosedürel programlama kullanarak, fonksiyonlar ile yaptığımı düşünüyordum, yeterince iyi tasarlanmış bir altyapıda nesneler beni prosedürel kodda yazdığımın nasıl daha ilerisine götürebilecekti ?
Bununla ilgili birkaç deneme yaptım, denemelerimin sonucunda ilginç kodlar ortaya çıkmıştı ancak bu kod mucize bir kod değildi, bunları prosedürel de yapabilirdim. Üstelik, veritabanı mimarisine alıştıktan sonra, bunların nesnelere uyarlanması sonucunda ortaya çıkabilecek yapılar etkili ve kullanışlı da gözükmüyordu.
Tekrar kullanılabilirlik, kolay değişiklik yapma, yazılım hızı, kolay değişiklik gibi vaatlerin karşılığını prosedürel yazılım kadar dahi alamıyordum ki.
Daha sonra nesneye yönelik yazılım ile ilgili bildiğim ufak tefek şeyleri bir rafa kaldırdım ve veritabanı üzerinden prosedürel gitmeye devam ettim.
Ancak, sürekli olarak beni rahatsız eden birşey vardı. Bunlardan birincisi, her yazdığım yazılım sonrasında, bu yazılıma bir takım özellikler ekledikçe, yazılımın şişip kontrolden çıktığını farkettim. Ne kadar çok özellik isteği gelir ve ben kod üzerinde ne kadar çok çalışırsam, o kadar yeni değişiklik veya ekleme süresi artıyor, bir yerlere müdahele ettikçe o kadar çok yer bozulmaya başlıyor, değişiklik yaparken sürekli aynı yerlerdeki aynı bugları temizlemekten kendi kuyruğumu takip ediyor gibi hissediyordum.
Ayrıca, veritabanı mimarisini çıkarıp sonradan kodlamaya geçtiğim zamanlarda tüm hissettiğim şey aynı şeyi tekrar tekrar yaptığımdı. Bazı kodlar birleştilip bir dizi fonksiyon ile beraber çalıştırılabiliyordu, ancak çoğu şeyi tekrar tekrar ufak değişikliklerle yazmak zorunda kalıyordum. Üstelik, her yaptığım yazılım, bir önceki yaptığım yazılımdaki bazı kısımlara çok benziyor, nadir olarak copy paste ile oradan bir takım kodları alıyor ancak çoğunlukla daha önce yapıtğım işi çok beğenmediğim için tekrar baştan yazıyordum.
Bunu yapmanın daha kolay bir yöntemi vardı ancak neydi ?
Tekrar kullanılabilirlik çok önemliydi. Her uygulamanın sabit ihtiyaç duyduğu şeyleri tekrar kullanılabilir yapmalıydım. Ancak ne yaparsam yapayım, bir sonraki uygulamada birtakım ekstra özelliklere ihtiyacım oluyor ve daha önce yazdığım kodu anlayıp içerisinden çıkamıyordum.
Bunun üzerinde düşünürken, bir projede, aklıma bu kodların dinamik olarak üretilebileceği geldi. Aslında, çoğu uygulama select insert update delete içeren şeylerdi, bunların veritabanı ilişkileri ve ekranlarını üretebilirsem, bu yapıyı standart bir hale getirebilirsem, hem tekrar kullanılabilirlik benim kod üretme sistemim tarafından sağlanmış olacak, hemde ufak değişiklikler yüzünden duplicate kod tutmamış olacaktım.
Bir süre üzerinde çalıştıktan sonra veritabanına bazı satırların girilmesi sonrasında ekranından sql kodlarına kadar kodu üretecek bir yapı kurmayı başardım. Bu yapı, veritabanından belirli bir tabloyu okuyor, o tablodaki alanlara göre yeni tablolar oluşturuyor, sql cümleleri ve ekranlar oluşturuyor, daha sonra bunları sistemin kullanacağı dosyalar içerisine yazıyordu. Değişiklik tekrar compile gerektiriyordu ancak gene de işler çok hızlı yürüyordu. Daha sonra runtimeda bu yeni kısımları implement edecek bir sistem geliştirdim ve dha da memnun kaldım.
Ancak sorunum hala çözülmemişti, sistemin belirli kısımları için bunları uygulayabilsem de açıkta kalan birçok nokta oluyordu. Bu sistem tarafından üretilemeyen kısımları gene her proje için ayrı ayrı yazmak zorunda kalıyor, saatlerce debug ile uğraşıyordum.
Daha da araştırdım ve nesneye yönelik programlama gene karşıma çıktı. Daha önce başarısız bir denemem olmuştu ancak bazı noktaların bende eksik olduğunu farketmiştim, acaba şimdi bir cevap alabilecekmiydim ? Başka şeyler aradım ancak sürekli olarak nesneye yönelik yazılım karşıma çıkıyordu.
İlk anladığım şey, benim nesneye yönelik yazılım yanlış ve eksik anladığımdı. Ciddi yapıları araştırdığım zaman, anlayamadığım nesneye yönelik kodlar ve girift ilişkiler vardı ki bunlara neden ihtyiaç duyulduğu veya niye yapıldığı hakkında en ufak bir fikrim yoktu. Kodları anlamaya çalışıp biraz daha araştırma yapınca, tasarım kalıpları (design patterns) ile karşılaştım, vaat ettikleri çok ilginçti, ancak anlayamıyordum, uml diyagramları biraz kafamı karıştırıyordu ve kod örneklerini kısmen anlasam da bana çok yabancı idi. Daha sonra karşıma mda (model driven architecture) çıktı. Bunları anlamam için uml bilmem gerekiyordu.
Umli araştırıp öğrendikten sonra, okuduğum şeyler beni heyecanlandırmaya başlamıştı. Değişik yerlerdeki makalelere giriyor ve çok akıllıca tasarlanmış nesneye yönelik yapılarla karşılaşıyordum. Ciddi yapıların hiçbirisinden uml eksik değildi ve onu öğrenmem sonrasında bir mana ifade etmeye başlamıştı.
Objelerin sakladığı sırların bazılarını öğrendim.
1. Nesne tabanlı yazılım anlattığını iddia eden çoğu kitap laf kalabalığı ve syntax bilgisi veriyor idi, özellikle dil öğreten kitaplar (C#,C++,Java vb.)
Bu tür kitaplar dilin öğrenilmesinde faydalı olabilir, ancak nesneye yönelik tasarım bilgisi aslında dilden bağımsız birşeydir, bir kere öğrenildiği zaman tüm nesneye yönelik dillerde kullanılabilir, ve bu bilgi dil bağımlı kaynaklarda çok zor bulunur.
1.a Uygulamanın türü önemli değildi, Web Application ile Client application veya Embedded bir nesneler kullanıldığında hep aynı şeydi
Tabii ki yazılımcı kendi alanını bilmeli ve Web bilmeyen birisinin web application yazarken çektii sıkıntıları göz ardı etmemelidir, ancak, asıl işi nesneler yapacak ise, bunlar uygulamanın nerede çalıştığı ile ilgilenmeyecek kısımların çoğunlukta olduğu bir gruptur. Yani asıl mimari kurulurken nerede çalışacağından soyutlayıp ne yapması gerektiğine odaklanırsak, hem eldeki problem daha kolay çözülüyor, hemde kod tekrar kullanılabilir oluyordu. Ayrıca, görev bölümü de çok kolay ortaya çıkıyordu, bir kişi sadece işi yapacak objeleri tasarlar ve yazarken diğer bir kişi bunlara ihtiyaç duymadan önyüzleri hazırlayabiliyordu.
1.b Microsoft Kaynaklarından bu bilgilere ulaşmak çok zordu, stratejileri hızlı kod yazan ucuz işgücü oluşturmaya yönelikti
Microsoft ile ilgili kaynakları araştırdığım müddetçe bu tür bir bilgiye ulaşmak çok eziyetli oluyor, bu bilgi belki de kasıtlı olarak saklanıyordu, dotnet frameworkün asıl yapısını anlamak için bulunan kaynaklar çok sınırlı idi.
2. Nesnelerle düşünmek için özgür olunmalıydı, veritabanına bağımlı bir yapı özgür olamazdı
Daha önce yaptığım gibi veritabanından hareket ettiğim durumlarda, mimariyi veritabanına göre tasarladığım durumlarda, hem veritabanındaki değişikliklere korkunç savunmasız kalıyordum hemde objeleri istediğim gibi kullanmaıyor ve tablolara kolonlara bağımlı bir kod yazmak zorunda oluyordum. Ancak anladığım bir şey var ki, benim için en değerli bilgilerden birisi, objelerle çalışınca, veritabanı, objelerin saklanılmasını istediğim kısmı saklamak için kullanılacaktı. Yani veritabanının sistemi yönetmek veya en değerli parçası olmak işlevi yoktu, sadece bir takım bilgileri bir yerde tutup bilgisayar kapandığında kaybolmamasını sağlayacak, tekrar istediğimde geri alabileceğim bir yapı için geçerli idi. O zaman nesneleri veritabanı ile sınırlandırmak, aslında bir uygulamanın o uygulama içerisindeki loglama sistemine bağlı olması kadar saçmaydı. Nesneleri istediğim gibi yazabilmeliydim, işi yapacak olan onlardı, veritabanı değil, sadece yapılan işin sonucunda ortaya çıkan şeyi kaydetmem gerekiyordu. (Tabii burada yapılan işten kasıt sistemin belirli kısımlarının ayrı ayrı yaptığı işlerdir, yoksa bütün nesneler her işini bitirir, uygulamanın çalışması biter sonra veritabanı erişimi sağlanıp objeler veritabanına yazılır gibi bir iddiam olamaz, özellikle web uygulamaları için.)
3. Yazılımın mimarisi aslında nesnelerin mimarisinden yola çıkılarak yapılmalı idi.
(2) de belirttiğim gibi, yazılım veritabanı mimarisinden bağımsız olmalıydı. Ayrıca, gösterimden de bağımsız olmalı idi. Ancak o zaman nesneler yazılımın belkemiği olabilir ve ancak o zaman nesneye yönelik yazılımın gerçek meyvelerini alabilirdim. Bu durumda, yazılımın belkemiği nesnelerdi, yazılım tasarımı da nesnelere göre yapılmalı idi. Ancak, nesne derken, asıl işi yapacak nesnelerden bahsediyorum. Bir uygulamanın menüsüde nesne yapısında olabilir. Ama uygulamanın aslında ne iş yaptığı önemlidir. Bir elektronik pazaryeri uygulamasında mimarinin asıl üzerine dayanacağı yerler veritabanı tablosunu temsil eden nesne, menüyü temsil eden nesne, sessionu temsil eden nesne değil, satılacak ürünleri temsil eden nesneler, açıkartırmayı temsil edecek nesneler vb. olmalıydı.
4. Nesneye yönelik olduğun iddia eden çoğu yazılım aslında nesneye yönelik değildi
Özellikle Türkiye için, yazılımın içerisinde bir nesne kullanıldığı anda o yazılım nesneye yönelik kabul ediliyordu, bu saçmaydı. Genelde veritabanına bağlı mimari kullanan firmalar, daha sonra yazılımlarının veritbanı bağlantısı kısmını nesneler yaptığı için yazılımlarına nesneye yönelik yazılım adını taktıklarını farkettim.
5. Nesnelerin birbirlerini etkilemeden değiştirilebilir ve çalışabilir yapılar olmasını sağlamak için çok dikkat gerekliydi.
Hatalarımdan birisidir bu, çoğu kişinin de aynı yanlışa düştüğünü farkettim. Nesnelerin avantajları, kendilerini bir diğerinden gizleyebildiği sürece maksimuma çıkıyordu. Daha önce nesneye yönelik yazılım yaptığımda, her metodu ve özelliği public olarak tanımlayıp heryerden her türlü objenin her türlü objeye ulaşmasının işimi kolaylaştırdığını ve protected ile private yapıların aslında benim kadar zeki olmayan :) insanlar tarafından ortaya konduğunu düşünmüştüm.
Public metodlar, bir nesnenin zayıf yönleridir. Bir nesnenin ne kadar çok public elemanı var ise o nesne o kadar zayıftır, çünkü onun diğerleri ile bağlantısı o kadar kuvvetlidir. Bu da, o nesneyi değiştirdiğim anda birsürü yerin etkileneceği veya başka bir yerde kullanabilmek için o nesne üzerinden sırayla çalışan birsürü fonksiyonu o yazılımda tekrar implement etmem gerekeceği, dolayısı ile nesnenin çalışma şeklini tekrar anlayıp bilmem gerekeceği manasındaydı.
Yaşayan bir sistemin ortasından bir parça alıp onu başka bir sistemin ortasına oturtmak için o nesnenin kodlarını tekrar tekrar çözmem gerekmemeliydi.
6. Tasarım kalıpları (design patterns) çok iyi öğrenilmesi gereken bir konu idi.
Tasarım kalıpları çok faydalı bir konuydu. Bunları inceleyip hem çok ciddi öğrenmek hemde bunlara bakarak nesneye yönelik yazılım yapmayı öğrenmek gerekiyordu.
Bu yazdıklarım ışığında devam edip kanaatimce uzun bir yol katettim. Bunların farkına vardıktan sonra izlenmesi gereken yol, nesneye yönelik mimarilerin kurulması esnasında verilecek kararlar ile ilgili bilgi edinmektir. Bu yazdıklarımı farkedip bilmek ayrı, bunları uygulamaya geçirmek ayrı birer bilgi. İkincisi birincisinden önce gelemiyor tabii ki.
Geldiğim noktadan çok memnunum ve prosedürel yazılıma dönmeyi kesinlikle düşünmüyorum. Tekrar kullanılabilir kod, sistemin tümünü etkilemeden değişiklik yapabilme, veritabanı değiştirebilme, bir uygulamayı her platformda tekrar baştan yazmaya gerek kalmadan çalıştırabilme gibi özellikleri yazılımlarıma verebiliyorum.
Benim için öğrenecek çok şey var, yolun ortalarındayım sanırım, ancak yolumu bildiğim için memnunum.
Ortada bir takım nesnelerin olması, iletişimi bunların kurması ve bu nesnelerin gerçek dünya benzeri davranışlar sergileyebilmeleri gerçekten ilginçti, ama vadedilen şeyler çok fazlaydı, bunlarda nesnelerin nasıl yardımcı olacağını veya nasıl başaracağını anlayamıyordum, sadece class tanımlayarak nasıl üstesinden gelinebilecekti ?
Üstelik, bu vaatlerin çoğunu ben zaten prosedürel programlama kullanarak, fonksiyonlar ile yaptığımı düşünüyordum, yeterince iyi tasarlanmış bir altyapıda nesneler beni prosedürel kodda yazdığımın nasıl daha ilerisine götürebilecekti ?
Bununla ilgili birkaç deneme yaptım, denemelerimin sonucunda ilginç kodlar ortaya çıkmıştı ancak bu kod mucize bir kod değildi, bunları prosedürel de yapabilirdim. Üstelik, veritabanı mimarisine alıştıktan sonra, bunların nesnelere uyarlanması sonucunda ortaya çıkabilecek yapılar etkili ve kullanışlı da gözükmüyordu.
Tekrar kullanılabilirlik, kolay değişiklik yapma, yazılım hızı, kolay değişiklik gibi vaatlerin karşılığını prosedürel yazılım kadar dahi alamıyordum ki.
Daha sonra nesneye yönelik yazılım ile ilgili bildiğim ufak tefek şeyleri bir rafa kaldırdım ve veritabanı üzerinden prosedürel gitmeye devam ettim.
Ancak, sürekli olarak beni rahatsız eden birşey vardı. Bunlardan birincisi, her yazdığım yazılım sonrasında, bu yazılıma bir takım özellikler ekledikçe, yazılımın şişip kontrolden çıktığını farkettim. Ne kadar çok özellik isteği gelir ve ben kod üzerinde ne kadar çok çalışırsam, o kadar yeni değişiklik veya ekleme süresi artıyor, bir yerlere müdahele ettikçe o kadar çok yer bozulmaya başlıyor, değişiklik yaparken sürekli aynı yerlerdeki aynı bugları temizlemekten kendi kuyruğumu takip ediyor gibi hissediyordum.
Ayrıca, veritabanı mimarisini çıkarıp sonradan kodlamaya geçtiğim zamanlarda tüm hissettiğim şey aynı şeyi tekrar tekrar yaptığımdı. Bazı kodlar birleştilip bir dizi fonksiyon ile beraber çalıştırılabiliyordu, ancak çoğu şeyi tekrar tekrar ufak değişikliklerle yazmak zorunda kalıyordum. Üstelik, her yaptığım yazılım, bir önceki yaptığım yazılımdaki bazı kısımlara çok benziyor, nadir olarak copy paste ile oradan bir takım kodları alıyor ancak çoğunlukla daha önce yapıtğım işi çok beğenmediğim için tekrar baştan yazıyordum.
Bunu yapmanın daha kolay bir yöntemi vardı ancak neydi ?
Tekrar kullanılabilirlik çok önemliydi. Her uygulamanın sabit ihtiyaç duyduğu şeyleri tekrar kullanılabilir yapmalıydım. Ancak ne yaparsam yapayım, bir sonraki uygulamada birtakım ekstra özelliklere ihtiyacım oluyor ve daha önce yazdığım kodu anlayıp içerisinden çıkamıyordum.
Bunun üzerinde düşünürken, bir projede, aklıma bu kodların dinamik olarak üretilebileceği geldi. Aslında, çoğu uygulama select insert update delete içeren şeylerdi, bunların veritabanı ilişkileri ve ekranlarını üretebilirsem, bu yapıyı standart bir hale getirebilirsem, hem tekrar kullanılabilirlik benim kod üretme sistemim tarafından sağlanmış olacak, hemde ufak değişiklikler yüzünden duplicate kod tutmamış olacaktım.
Bir süre üzerinde çalıştıktan sonra veritabanına bazı satırların girilmesi sonrasında ekranından sql kodlarına kadar kodu üretecek bir yapı kurmayı başardım. Bu yapı, veritabanından belirli bir tabloyu okuyor, o tablodaki alanlara göre yeni tablolar oluşturuyor, sql cümleleri ve ekranlar oluşturuyor, daha sonra bunları sistemin kullanacağı dosyalar içerisine yazıyordu. Değişiklik tekrar compile gerektiriyordu ancak gene de işler çok hızlı yürüyordu. Daha sonra runtimeda bu yeni kısımları implement edecek bir sistem geliştirdim ve dha da memnun kaldım.
Ancak sorunum hala çözülmemişti, sistemin belirli kısımları için bunları uygulayabilsem de açıkta kalan birçok nokta oluyordu. Bu sistem tarafından üretilemeyen kısımları gene her proje için ayrı ayrı yazmak zorunda kalıyor, saatlerce debug ile uğraşıyordum.
Daha da araştırdım ve nesneye yönelik programlama gene karşıma çıktı. Daha önce başarısız bir denemem olmuştu ancak bazı noktaların bende eksik olduğunu farketmiştim, acaba şimdi bir cevap alabilecekmiydim ? Başka şeyler aradım ancak sürekli olarak nesneye yönelik yazılım karşıma çıkıyordu.
İlk anladığım şey, benim nesneye yönelik yazılım yanlış ve eksik anladığımdı. Ciddi yapıları araştırdığım zaman, anlayamadığım nesneye yönelik kodlar ve girift ilişkiler vardı ki bunlara neden ihtyiaç duyulduğu veya niye yapıldığı hakkında en ufak bir fikrim yoktu. Kodları anlamaya çalışıp biraz daha araştırma yapınca, tasarım kalıpları (design patterns) ile karşılaştım, vaat ettikleri çok ilginçti, ancak anlayamıyordum, uml diyagramları biraz kafamı karıştırıyordu ve kod örneklerini kısmen anlasam da bana çok yabancı idi. Daha sonra karşıma mda (model driven architecture) çıktı. Bunları anlamam için uml bilmem gerekiyordu.
Umli araştırıp öğrendikten sonra, okuduğum şeyler beni heyecanlandırmaya başlamıştı. Değişik yerlerdeki makalelere giriyor ve çok akıllıca tasarlanmış nesneye yönelik yapılarla karşılaşıyordum. Ciddi yapıların hiçbirisinden uml eksik değildi ve onu öğrenmem sonrasında bir mana ifade etmeye başlamıştı.
Objelerin sakladığı sırların bazılarını öğrendim.
1. Nesne tabanlı yazılım anlattığını iddia eden çoğu kitap laf kalabalığı ve syntax bilgisi veriyor idi, özellikle dil öğreten kitaplar (C#,C++,Java vb.)
Bu tür kitaplar dilin öğrenilmesinde faydalı olabilir, ancak nesneye yönelik tasarım bilgisi aslında dilden bağımsız birşeydir, bir kere öğrenildiği zaman tüm nesneye yönelik dillerde kullanılabilir, ve bu bilgi dil bağımlı kaynaklarda çok zor bulunur.
1.a Uygulamanın türü önemli değildi, Web Application ile Client application veya Embedded bir nesneler kullanıldığında hep aynı şeydi
Tabii ki yazılımcı kendi alanını bilmeli ve Web bilmeyen birisinin web application yazarken çektii sıkıntıları göz ardı etmemelidir, ancak, asıl işi nesneler yapacak ise, bunlar uygulamanın nerede çalıştığı ile ilgilenmeyecek kısımların çoğunlukta olduğu bir gruptur. Yani asıl mimari kurulurken nerede çalışacağından soyutlayıp ne yapması gerektiğine odaklanırsak, hem eldeki problem daha kolay çözülüyor, hemde kod tekrar kullanılabilir oluyordu. Ayrıca, görev bölümü de çok kolay ortaya çıkıyordu, bir kişi sadece işi yapacak objeleri tasarlar ve yazarken diğer bir kişi bunlara ihtiyaç duymadan önyüzleri hazırlayabiliyordu.
1.b Microsoft Kaynaklarından bu bilgilere ulaşmak çok zordu, stratejileri hızlı kod yazan ucuz işgücü oluşturmaya yönelikti
Microsoft ile ilgili kaynakları araştırdığım müddetçe bu tür bir bilgiye ulaşmak çok eziyetli oluyor, bu bilgi belki de kasıtlı olarak saklanıyordu, dotnet frameworkün asıl yapısını anlamak için bulunan kaynaklar çok sınırlı idi.
2. Nesnelerle düşünmek için özgür olunmalıydı, veritabanına bağımlı bir yapı özgür olamazdı
Daha önce yaptığım gibi veritabanından hareket ettiğim durumlarda, mimariyi veritabanına göre tasarladığım durumlarda, hem veritabanındaki değişikliklere korkunç savunmasız kalıyordum hemde objeleri istediğim gibi kullanmaıyor ve tablolara kolonlara bağımlı bir kod yazmak zorunda oluyordum. Ancak anladığım bir şey var ki, benim için en değerli bilgilerden birisi, objelerle çalışınca, veritabanı, objelerin saklanılmasını istediğim kısmı saklamak için kullanılacaktı. Yani veritabanının sistemi yönetmek veya en değerli parçası olmak işlevi yoktu, sadece bir takım bilgileri bir yerde tutup bilgisayar kapandığında kaybolmamasını sağlayacak, tekrar istediğimde geri alabileceğim bir yapı için geçerli idi. O zaman nesneleri veritabanı ile sınırlandırmak, aslında bir uygulamanın o uygulama içerisindeki loglama sistemine bağlı olması kadar saçmaydı. Nesneleri istediğim gibi yazabilmeliydim, işi yapacak olan onlardı, veritabanı değil, sadece yapılan işin sonucunda ortaya çıkan şeyi kaydetmem gerekiyordu. (Tabii burada yapılan işten kasıt sistemin belirli kısımlarının ayrı ayrı yaptığı işlerdir, yoksa bütün nesneler her işini bitirir, uygulamanın çalışması biter sonra veritabanı erişimi sağlanıp objeler veritabanına yazılır gibi bir iddiam olamaz, özellikle web uygulamaları için.)
3. Yazılımın mimarisi aslında nesnelerin mimarisinden yola çıkılarak yapılmalı idi.
(2) de belirttiğim gibi, yazılım veritabanı mimarisinden bağımsız olmalıydı. Ayrıca, gösterimden de bağımsız olmalı idi. Ancak o zaman nesneler yazılımın belkemiği olabilir ve ancak o zaman nesneye yönelik yazılımın gerçek meyvelerini alabilirdim. Bu durumda, yazılımın belkemiği nesnelerdi, yazılım tasarımı da nesnelere göre yapılmalı idi. Ancak, nesne derken, asıl işi yapacak nesnelerden bahsediyorum. Bir uygulamanın menüsüde nesne yapısında olabilir. Ama uygulamanın aslında ne iş yaptığı önemlidir. Bir elektronik pazaryeri uygulamasında mimarinin asıl üzerine dayanacağı yerler veritabanı tablosunu temsil eden nesne, menüyü temsil eden nesne, sessionu temsil eden nesne değil, satılacak ürünleri temsil eden nesneler, açıkartırmayı temsil edecek nesneler vb. olmalıydı.
4. Nesneye yönelik olduğun iddia eden çoğu yazılım aslında nesneye yönelik değildi
Özellikle Türkiye için, yazılımın içerisinde bir nesne kullanıldığı anda o yazılım nesneye yönelik kabul ediliyordu, bu saçmaydı. Genelde veritabanına bağlı mimari kullanan firmalar, daha sonra yazılımlarının veritbanı bağlantısı kısmını nesneler yaptığı için yazılımlarına nesneye yönelik yazılım adını taktıklarını farkettim.
5. Nesnelerin birbirlerini etkilemeden değiştirilebilir ve çalışabilir yapılar olmasını sağlamak için çok dikkat gerekliydi.
Hatalarımdan birisidir bu, çoğu kişinin de aynı yanlışa düştüğünü farkettim. Nesnelerin avantajları, kendilerini bir diğerinden gizleyebildiği sürece maksimuma çıkıyordu. Daha önce nesneye yönelik yazılım yaptığımda, her metodu ve özelliği public olarak tanımlayıp heryerden her türlü objenin her türlü objeye ulaşmasının işimi kolaylaştırdığını ve protected ile private yapıların aslında benim kadar zeki olmayan :) insanlar tarafından ortaya konduğunu düşünmüştüm.
Public metodlar, bir nesnenin zayıf yönleridir. Bir nesnenin ne kadar çok public elemanı var ise o nesne o kadar zayıftır, çünkü onun diğerleri ile bağlantısı o kadar kuvvetlidir. Bu da, o nesneyi değiştirdiğim anda birsürü yerin etkileneceği veya başka bir yerde kullanabilmek için o nesne üzerinden sırayla çalışan birsürü fonksiyonu o yazılımda tekrar implement etmem gerekeceği, dolayısı ile nesnenin çalışma şeklini tekrar anlayıp bilmem gerekeceği manasındaydı.
Yaşayan bir sistemin ortasından bir parça alıp onu başka bir sistemin ortasına oturtmak için o nesnenin kodlarını tekrar tekrar çözmem gerekmemeliydi.
6. Tasarım kalıpları (design patterns) çok iyi öğrenilmesi gereken bir konu idi.
Tasarım kalıpları çok faydalı bir konuydu. Bunları inceleyip hem çok ciddi öğrenmek hemde bunlara bakarak nesneye yönelik yazılım yapmayı öğrenmek gerekiyordu.
Bu yazdıklarım ışığında devam edip kanaatimce uzun bir yol katettim. Bunların farkına vardıktan sonra izlenmesi gereken yol, nesneye yönelik mimarilerin kurulması esnasında verilecek kararlar ile ilgili bilgi edinmektir. Bu yazdıklarımı farkedip bilmek ayrı, bunları uygulamaya geçirmek ayrı birer bilgi. İkincisi birincisinden önce gelemiyor tabii ki.
Geldiğim noktadan çok memnunum ve prosedürel yazılıma dönmeyi kesinlikle düşünmüyorum. Tekrar kullanılabilir kod, sistemin tümünü etkilemeden değişiklik yapabilme, veritabanı değiştirebilme, bir uygulamayı her platformda tekrar baştan yazmaya gerek kalmadan çalıştırabilme gibi özellikleri yazılımlarıma verebiliyorum.
Benim için öğrenecek çok şey var, yolun ortalarındayım sanırım, ancak yolumu bildiğim için memnunum.
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.
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.
Pazartesi, Haziran 12, 2006
Yazılımsal Testler hakkında
Bu konuya özellikle ülkemizde gerekenden çok daha az önem verildiğini düşünüyorum. Manual testleri bırakıp otomatize edilmiş testlere geçmemiz, hem yazılımın hayata geçtikten sonra müşteri önünde ortaya çıkaracak sorunlarını azaltacak, hem değişiklik maliyetini, hemde tekrar kullanılabilirlik maliyetini artıracaktır. Bu konu ile ilgili yeterli bilgisi olan teknik personelin bulunmaması, yöneticilerin bu konunun önemini bilmemeleri ve zaman kaybı olarak görmeleri dolayısı ile çok nadir uygulanabilmiştir. Ancak, bu konunun anlaşılıp uygulanması ile kalitemizin çok ciddi şekilde artacağı ve karlılığımızın yükseleceği de ısrarla savunduğum fikirlerdir.
Yazılımsal testleri kullanan herhangi bir kişinin kolay kolay manuel test edilen ortamlara geri dönmek istememesinin sebebi bu yaklaşımın gerçekten işe yaramasıdır.
Yazılım projeleri tüm yaşam evresi süresince bir takım istenmeyenlerle boğuşup durur.
Yaılım hayata geçinceye kadar ve geçtikten sonra, bir sürü beklenmyen davranış sergiler. Sebebi tam bitirilmemiş fonksiyonalite olabileceği gibi, düşünülmeyen nedenlerden, değişiklikten, anlık davranışlardan ortaya çıkan sorunlar olabilir. Bunların toplamına bug diyebiliriz.
Sorun
- Bug terimi ilginç bir terim, bilgisayarların ilk yıllarından bize miras kalmış, o zamanlar oda büyüklüğünde bilgisayarla çalışan kişiler bazı problemlerin sebebinin uzun uğraşlar sonrasında devrelerin içerisine girmiş böceklerden kaynaklandığını bulmuşlar, işleme bug temizleme manasına gelen debugging adı vermişler ve terim bu şekilde günümüze kadar gelmiştir.
Bazı yazılımcılar tarafından küçümsense de, istatistiklere göre yazılım geliştirme sürecinin çok büyük bir bölümünü debug işlemi almaktadır. Sorun, sadece yazılım kullanılmaya başladıktan sonra çıkan sorunlar değil, yazılım esnasında ve yazılımın değiştirilmesi esnasında çok şekilde uzun debug süreçlerinden geçme ihtiyacının ortaya çıkması, ayrıca bu debug süreçlerine girilmesi için gerekli önkoşulun da yazılımda bir hata veya beklnemyen davranışla karşılaşılmış olmasıdır. Hata göze çarpmayan bir hata ise, gerçek ortamda ortaya çıkana kadar yazılımal beraber yaşar. Gerçek ortamda ortaya çıkan bir bug ise, hem müşterinin güvenini zedeler, hem yazılımın üzerinden zaman geçmiş olabileceği için unutma riskini artırır, hem de değişikliği esnasında sistemin diğer taraflarını bozarak başka bugları oluşturma sürecine girmesine sebep olur.
Orta veya büyük çaplı bir projede yer almış herhangi bir kişi, bu debug sürecini iyi bilir. Yazılımda bir hata vardır, bunun tespiti için uzun süre boyunca uğraşılır, daha sonra bu hata bulunup çözülür ancak bir süre sonra ortaya çıkarki bu hatanın düzeltilmesi başka bir yeri bozmuştur, o kısım düzeltilir ve bir durumda ilk düzeltilmiş hatanın tekrarlandığı gözükür.
Biraz uzun süredir üzerinde uğraşılıyor olan herhangi bir yazılım için bu durum genel bir durumdur. Yeni özellik ekleme esnasında bu problemlerin hepsi hem yazılım hem kullanım esnasında nükseder ve her seferinde üzerinde zaman harcanarak düzeltilmeye çalışılır.
Projenin toplam maliyetine eklenen bu süreler, yazılım büyüdükçe daha da uzar, o yüzden yeni bir özellik eklemenin yaratacağı problemlerden ürken bir ekip bu durumdan sonra yazılıma dokunmak istemez veya dokunduğu zaman çok uzun zamanlarda sorunlar çözüleceğinden yöneticiler yazılımın baştan yazılmasına karar verme durumuna gelir.
Bu durumun çözümü nasıldır ? Yazılımın gerçek ortama geçmeden önce her noktasının manuel test edilmesi belki yazılımın gerçek ortamda hata vermesini engelleyebilir, ki bu tür bir çalışmanını başarılı olması için her değişiklikten sonra bu testin tekrarlanması gerekir, bu yaklaşım debug süresini azaltmaya yardımcı olamaz.
Çözüm
Bu döngünün içerisinden çıkmamızı sağlayan yapı aslında sihir gibi bir yapı olabilir. Sistemin her tarafını test edecek, problemlerin yerini bizim yerimize tespit edip nerelere müdahele etmemiz gerektiğini söyleyecek bir yapı, bu kontrolü çok kısa zamanda yapabilecek, yazılımdaki her türlü sıkıntıyı oluşmadan bize haber verebilecek bir yapı lazımdır.
Edindiğimiz bilgi, bu tür bir sihirin ancak başka bir yazılım ile mümkün olduğu yönündedir. İnsan gibi davranabilecek, sistemin her yerine girecek çıkacak ve problemleri tespit edecek.
Eğer yazılımı yapan veya yapan ekipten birisi , yazılım esnasında yazılımın sağlaması gereken fonksiyonaliteleri bir kağıda değilde yazılıma dökerse ve bu yazılım çalışma anında kodu kontrol ederse, problemleri bulmuş oluruz. Ancak sorunlarımız sadece kullanıncının gördüğü fonklsiyonalite değil, yazılımın kendi içerisindeki işleyiştende kaynaklanıyor olabilir. Bu durumda, aynı şekilde, bir yazılımcı bu kısmında nasıl çalışması gerektiğini koda yazar ise, bu problemler de sorun olduğunda tespit edilebilir.
Software testingin doğuşu bu şekilde olmuştur, bunun faydasını gören yazılımcılar, testlerin yazılabileceği, hızlı, anında ve kolay anlaşılabilecek şekilde çalışabilmesi için frameworkler yazmıştır.
Bu şekilde test edilmiş bir sistem, değişikliklere karşı sağlamlaştırılmış bir sistem de olur. Eğer sistemin tüm noktalarına çalışma prensipleri kod olarak yazılır ve bu kontrolü yapar ise her ne değişiklik veya yeni fonksiyonalite olursa olsun, kod kolayca değiştirilip yeni fonksiyonalite eklenebilir. Ayrıca, kodu düzeltme, okunulurluğunu artırma, performans artırma veya refactoring gibi işlemlerde bu tür testler olmadan çok zor ve risklidir.
Konuyla ilgilenenler için unit testler bir giriş noktası olabilir. Unit testler, bir classın kendi içerisindeki işleyişini bilen ve buna göre kontrolü yapan testlerdir. Kontrol edecek bir test suite çalıştırıldığında, sınıfların tümü kontrol edilir ve problem var ise tespit edilir. jUnit bu suitelerden bir tanesi, java için olmakla beraber, yeni her dilde bununla ilgili bir yazılım mevcut.
Fonksiyonalite testlerini yapan başka yazılımlar da var, Fit bir örnek olabilir.
Ayrıca, takım olarak çalışan insanlar için, kodun tutulduğu ortak noktaya kodun iletilmesinden önce tanımlanan testlerin herbirini çalıştıran ve tümü olumlu sonuç vermezse kodun yerleştirilme işlemine izin vermeyen bazı yapılar da ekip çalışmasını kolaylaştırır. (crusie control)
Çarşamba, Haziran 07, 2006
Yazılım Maliyeti
Maliyet Azaltma
(Yazılım ve Türkiye makalesine ek olarak yazılmıştır)
Yazılım maliyeti azaltma işlemi kapsamlı bilgi gerektiren ve zor bir işlemdir.
Buradaki kalemler,
1- Üretim maliyeti
2- Değişiklik maliyeti
3- Sorun Çözme (debug) maliyeti
4- Satış maliyeti
5- Destek maliyeti
6- Kullanılan diğer yazılımların maliyeti (Veritabanı vs.)
şeklindedir. Değişiklik ve debug maliyetleri küçük gibi gözükebilir, ancak yapılan araştırmalara göre, yazılımın asıl maliyeti bu kısımlarda ortaya çıkar.
Karşılaştığım çoğu yazılımcının en büyük şikayeti, değişiklik talepleri idi. Kullanıcılarının çok zahmetli olduğu / yazılımın konusunun çok değişken olduğu ve sürekli değişiklik taleplerinin geldiği bunun da yazılımı bozduğu, bugün yazılımın içerisinden çıkılmaz hale geldiği ve fırsat olsa baştan yazacaklarını belirtiyorlar. Bunun sadece o seferlik kendilerine mahsus bir durum olduğuna dair bir yaklaşım olsa da, yazılım dünyasında bu en büyük problemlerin arasındadır. Her yazılım ve her konu değişikliğüe ihtiyaç duyar, değişikliğe ayak uydurmayı sağlayamazsanız da bu değişiklik yazılımı alaşağı eder. Yazılım her değişiklikle biraz daha bozulur ve yönetilmesi imkansız hale gelir. Artık başlangıçta özenle tasarlanan yazılım yerine neresinden ne çıkacağı bilinmeyen bir ucube vardır. Her türlü değişiklik ile bu ucube daha da tuhaflaşır ve en ufak bir işlem yazılımın bin tane yerini etkiler, bunlar kullanıma kadar ortaya çıkmaz, kullanımda ortaya çıkan problemler tekrar yazılımcıya gittiği zaman yazılımcı bu problemleri düzeltirken başka problemler oluşur.
Bu da debug maliyetini getirir. Bunlar bir yazılımcının günlük karşıklaştığı durumlardır, bunun farklı şekilde olabileceğini bilmeyen kimseler ise bu döngü içerisinde çırpınırlar. Bu yüzden de maliyetler sürekli artar.
Eğer maliyet düşürme bir amaç ise, bu husus çok ama çok önemli bir husustur. Yazılımlar değişir, bunu reddeden bir mantık yok olmaya mahkumdur. Maliyetlerin içerisine bu yerleştirilmelidir.
(Yazılım ve Türkiye makalesine ek olarak yazılmıştır)
Yazılım maliyeti azaltma işlemi kapsamlı bilgi gerektiren ve zor bir işlemdir.
Buradaki kalemler,
1- Üretim maliyeti
2- Değişiklik maliyeti
3- Sorun Çözme (debug) maliyeti
4- Satış maliyeti
5- Destek maliyeti
6- Kullanılan diğer yazılımların maliyeti (Veritabanı vs.)
şeklindedir. Değişiklik ve debug maliyetleri küçük gibi gözükebilir, ancak yapılan araştırmalara göre, yazılımın asıl maliyeti bu kısımlarda ortaya çıkar.
Karşılaştığım çoğu yazılımcının en büyük şikayeti, değişiklik talepleri idi. Kullanıcılarının çok zahmetli olduğu / yazılımın konusunun çok değişken olduğu ve sürekli değişiklik taleplerinin geldiği bunun da yazılımı bozduğu, bugün yazılımın içerisinden çıkılmaz hale geldiği ve fırsat olsa baştan yazacaklarını belirtiyorlar. Bunun sadece o seferlik kendilerine mahsus bir durum olduğuna dair bir yaklaşım olsa da, yazılım dünyasında bu en büyük problemlerin arasındadır. Her yazılım ve her konu değişikliğüe ihtiyaç duyar, değişikliğe ayak uydurmayı sağlayamazsanız da bu değişiklik yazılımı alaşağı eder. Yazılım her değişiklikle biraz daha bozulur ve yönetilmesi imkansız hale gelir. Artık başlangıçta özenle tasarlanan yazılım yerine neresinden ne çıkacağı bilinmeyen bir ucube vardır. Her türlü değişiklik ile bu ucube daha da tuhaflaşır ve en ufak bir işlem yazılımın bin tane yerini etkiler, bunlar kullanıma kadar ortaya çıkmaz, kullanımda ortaya çıkan problemler tekrar yazılımcıya gittiği zaman yazılımcı bu problemleri düzeltirken başka problemler oluşur.
Bu da debug maliyetini getirir. Bunlar bir yazılımcının günlük karşıklaştığı durumlardır, bunun farklı şekilde olabileceğini bilmeyen kimseler ise bu döngü içerisinde çırpınırlar. Bu yüzden de maliyetler sürekli artar.
Eğer maliyet düşürme bir amaç ise, bu husus çok ama çok önemli bir husustur. Yazılımlar değişir, bunu reddeden bir mantık yok olmaya mahkumdur. Maliyetlerin içerisine bu yerleştirilmelidir.
Yazılım Mimarisinde Veritabanının Yeri
Orta - Büyük çaplı herhangi bir yazılım belirli bazı kısımları tasarlanmadan hayata geçemez. (Kastettiğim bir yazılım yapılmadan önce mimarisi tamamen hazırlanmış olmalıdır şeklinde algılanmasın, agile modeller için bu geçerli değildir, yazılım geliştirme süresince de mimari ortaya çıkabilir).
Başlangıç seviyesinden daha yukarıda uğraşan her kişi böyle bir çalışmanın veya konseptin gerekliliğine inanmaktadır.
Bir yazılımın yapacağı işlevler, akışı, mekanizmaları belirlenir ve bunlara göre bir mimari oluşturulur. Bu konularda herhangi bir görüş ayrılığı veya problem yok.
Ancak, genel olarak yazılım sektöründe ülkemizde bir problem var, bu problem mimariyi veritabanından ibaret olarak görmektir.
Veritabanı, verinin saklanması ihtiyacı ile ortaya çıkan bir kavram olsa da, zaman içerisinde kendisine daha fazla iş yükler hale gelip, yazılımın çalışma mantığını da içerisine alabilecek bir yapı haline geldi. Oracle in bunda etkisi büyüktür demek yanlış olmaz, oracle forms ile tamamen veritabanı odaklı yazılımlar kolayca geliştirildi. Bu yazılımların hazırlaması ve öğrenmesi kolay, sonuçta data saklanacak ortam üzerinde çalışıyorsunuz, prezentasyon ile ilgili tüm konseptlerde oracle tarafından hazırlanarak kolay kullanımlı bir library haline getirilmiş durumda.
Buradan yola çıkılarak gelinen seviye, prezentasyonu başka bir dille yapmak ancak iş akışını gene veritabanı üzerinde yönetmek şeklinde oluştu.
Bu tür bir yazılım, tamamen veritabanı üzerine oturtulur. Sistemin değişik yerlerindeki değişik kod parçacıkları, veritabanına bazı kayıtlar atıp bazı kayıtlar alırak çalışır, bu data tutarlılığı açısından bir sorun teşkil etmese de, şu konularda sorun oluşturur.
- Değişiklik
- Tekrar Kullanılabilirlik
- Bakım
- Veritabanı Yazılımından bağımsız çalışabilme
- Test edilebilirlik (Software testing)
- Modülarite
- Farklı disiplindeki kişilerin birarada çalışma zorluğu
- Yazılımın tamamen veritabanına bağımlı olmasından ötürü yazılımcının veritabanına veritabanı ile ilgili kişinin yazılıma müdahele etmeden birşey yapamaması
- Veritabanı hazır olmadan yazılıma başlanamama
Tüm sistem mimarisi ve mantığı veritabanı içerisinde olursa, değişiklik külfeti çok büyük olur. En ufak özellik eklemek için en ufak hesaplama yapmak için veritabanını değiştirmek gerekir. Ayrıca, veritabanında gerekecek bazı performans değişiklikleri vb. de yazılımı doğrudan etkiler.
Eğer veritabanından yazılımı soyutlayabilirsek, o zaman istenilen tüm fonksiyonalite yazılım içerisinde olabilir. Sadece saklama işlemleri için veritabanı kullanılır ise, o zaman veritabanı yazılımını (Oracle sql server vb) değiştirmek de çok kolay olur.
Sistem veritabanına göre düzenlenmiş ise, tekrar kullanılabilirlik sıfıra yakın bir seviyede olur. Sistem çok fazla içiçedir ve bazı fonksiyonları çıkarıp bazı yenilerini eklemek, bazı modülleri çıkarmak, sistem tamamına müdahele etmeden imkansız gibidir. Dolayısı ile maliyeti artırır.
Eğer sistem veritabanına çok sıkı bağlı ise test edilebilirlik de mümkün değildir, testten kasıt manuel test değil yazılımsal testtir. Sistemin parça parça çalışıp çalışmadığını kontrol etmek, problemleri ortaya çıkmadan yakalamak için kullanılan yazılım testlerinin veritabanına çok sıkı bağlı sistemlerde oluşturulması çok güç olur.
Modülaritedeki zorluk, tekrar kullanımdaki zorluk gibidir.
Pazartesi, Haziran 05, 2006
Yazılım ve Türkiye
Yazılım sektöründe Türkiye'nin olması gereken pozisyonundan daha aşağıda bir pozisyonda olduğu ve ülkenin geleceği için önemli bir rol oynayabileceği ile ilgili bir fikir birliği var, bu iş ile ilgili biraz bilgi sahibi olan kimseler bu konunun önemine değiniyor.
Öngörüler
Düşük yatırım maliyeti, lojistik sorunu olmaması, diğer sektörlere nispetle daha az maliyetle daha büyük pazarlarda oyuncu olabilme imkanı genel olarak heyecanlandırıcı bir sektör görünümü veriyor. Ancak konu ile ilgili bilgi çok sığ kalıyor ve bu konu ile ilgili politikaların düzenlenmesinde bazı eksiklikler var kanaatindeyim.
Üretim
Öncelikle ülke ve sektör içerisindeki bireyler olarak konuya yaklaşımı yanlış buluyorum, yazılım projeleri ve şirketlerinde genel gidişat başıboş bir atı bırakıp hedefine varmasını beklemek şeklinde oluyor. Amatör bir ruhla profesyonel iş yapmaya çalışıyoruz, her amatör uğraş gibi ortaya çıkan şey çok fazla emek ancak nisbeten daha az değer sağlıyor.
Bu konuda hiçbir zaman bir atölye den ileriye gidemedik ve büyük şirketlerimiz de dahil, henüz bir yazılım fabrikası vücuda getirebilmiş değiliz. Sektörün ülkemizdeki üyeleri ise Fabrika olmak istemediği gibi bir fabrika olabileceğinin dahi farkında değil. Dünyada uzun zaman önce çözülmüş problemlerin varlığının farkına varılması dahi yıllar alıyor. Eğitim eksikliği gibi gözüküyor.
Şimdiye kadar üretim yöntemlerindeki problemlerin çok farkına varılamamasının bir sebebi, ülke içerisine iş yapan şirketlerin yaptıkları işleri yüksek fiyatlardan pazarlayabilme ve bu sayede maliyeti çok önemsememedir. Aynı hata senelerce sanayicilerimiz tarafından yapıldı, çok yüksek maliyetlerle yüksek fiyata satılan mallar ülke içerisinde müşteri bulmasına rağmen ülke dışında müşteri bulamadı. Bir değişiklik geçirmeleri gerekti, geçiremeyenler de bu gün ayakta değil.
Sonuç olarak, hem kalite olarak yazılımlarımız belirli bir seviyenin üstüne çıkamadı, hemde maliyetlerimiz hep yüksek oldu.
Global Oyuncular
Global oyuncu ve rakip olarak karşımıza çıkarılan örnek Hindistan. Gerçekten Hindistan bu konuda çok yol katetmiş ve her taraftan yazılım şirketleri fırlıyor. Büyük bir hızla özellikle Amerika'dan Hindistan'a para akıyor. Bizim için de aynı modeli savunanlar mevcut, ancak gözardı edilen birşey var. Türkiye Hindistan'dan nüfus açısından korkunç farklılık gösteriyor, bunun sonucu olarak da Hindistan Çin gibi ucuz iş gücünün olduğu bir yer. Bu, bizim sanayimizin Çin'in sanayisiyle yarışmaya çalışması veya o modeli uygulamaya çalışması gibi olur.
Ayrıca, yazılımın emek yoğun bir iş olmasından dolayı, yatırım maliyetinin yükselmesi de rekabeti sağlamak için yeterli olamaz, buradakinin 5 de biri maaşla aynı işi yapabilecek kişilerin Hindistan'da mevcut olması bu yönden rekabet veya model kopyalanmasını imkansız kılmaktadır.
Kar Maksimizasyonu
Yazılım için üretim maliyetinin satılan adetle doğru orantılı olduğu aşikardır, eğer yapılan üründen bir tane yerine bin tane satılır ise kar bu kadar artıp maliyet bu kadar azalmış olur. Ayrıca, burada hammadde sıkıntısı olmadığı için, diğer üretim sektörlerine göre adet artışından elde edilen kar çok daha üstlere çıkabilir. Microsoft'un bir anda bu kadar büyüyebilmesinin bir sebebi, 1 kere üretip n kere satabilmesidir.
Ancak, yazılımdaki ekstra bir maliyet, değişiklik ve güncelleme talebidir. Diğer üretim sektörlerinde üretilen bir ürünün üzerinde değişiklik yapma ihtiyacı olmadığından maliyet sadece ilk üretim ve teslim anında, belki bazı sektörler için bakım vb durumunda oluyor. Ancak bakım maliyeti, yazılımdaki değişiklik maliyeti yanında küçük bir maliyet gibi duruyor.
Bir işletmenin karının hesaplanmasını kabaca satış fiyatı - maliyetler şeklinde düşünecek olursak, sektörden daha fazla nemalanabilmek için ya satış fiyatı artırılacak yada maliyetler düşürülecektir. Şimdiye kadar, Türkiye'de (ve bir süre öncesine kadar tüm dünyada) kar maksimizasyonu satış fiyatlarının yüksek tutulması ile sağlandıysa da, artık müşteri bu yaklaşımı kabul etmemekte, bu yüzden rakipler fiyat indirmekte, yüksek fiyatta satış yapanlar ise rekabet edememektedir. Bu durumda, gelinen durum, artık ayakta kalabilmek için dahi yapılacak şey maliyetlerin düşürülmesi ve bu sayede rekabet içerisine dahil olmaktır.
Maliyet ile ilgili kısım için tıklayınız.
Öngörüler
Düşük yatırım maliyeti, lojistik sorunu olmaması, diğer sektörlere nispetle daha az maliyetle daha büyük pazarlarda oyuncu olabilme imkanı genel olarak heyecanlandırıcı bir sektör görünümü veriyor. Ancak konu ile ilgili bilgi çok sığ kalıyor ve bu konu ile ilgili politikaların düzenlenmesinde bazı eksiklikler var kanaatindeyim.
Üretim
Öncelikle ülke ve sektör içerisindeki bireyler olarak konuya yaklaşımı yanlış buluyorum, yazılım projeleri ve şirketlerinde genel gidişat başıboş bir atı bırakıp hedefine varmasını beklemek şeklinde oluyor. Amatör bir ruhla profesyonel iş yapmaya çalışıyoruz, her amatör uğraş gibi ortaya çıkan şey çok fazla emek ancak nisbeten daha az değer sağlıyor.
Bu konuda hiçbir zaman bir atölye den ileriye gidemedik ve büyük şirketlerimiz de dahil, henüz bir yazılım fabrikası vücuda getirebilmiş değiliz. Sektörün ülkemizdeki üyeleri ise Fabrika olmak istemediği gibi bir fabrika olabileceğinin dahi farkında değil. Dünyada uzun zaman önce çözülmüş problemlerin varlığının farkına varılması dahi yıllar alıyor. Eğitim eksikliği gibi gözüküyor.
Şimdiye kadar üretim yöntemlerindeki problemlerin çok farkına varılamamasının bir sebebi, ülke içerisine iş yapan şirketlerin yaptıkları işleri yüksek fiyatlardan pazarlayabilme ve bu sayede maliyeti çok önemsememedir. Aynı hata senelerce sanayicilerimiz tarafından yapıldı, çok yüksek maliyetlerle yüksek fiyata satılan mallar ülke içerisinde müşteri bulmasına rağmen ülke dışında müşteri bulamadı. Bir değişiklik geçirmeleri gerekti, geçiremeyenler de bu gün ayakta değil.
Sonuç olarak, hem kalite olarak yazılımlarımız belirli bir seviyenin üstüne çıkamadı, hemde maliyetlerimiz hep yüksek oldu.
Global Oyuncular
Global oyuncu ve rakip olarak karşımıza çıkarılan örnek Hindistan. Gerçekten Hindistan bu konuda çok yol katetmiş ve her taraftan yazılım şirketleri fırlıyor. Büyük bir hızla özellikle Amerika'dan Hindistan'a para akıyor. Bizim için de aynı modeli savunanlar mevcut, ancak gözardı edilen birşey var. Türkiye Hindistan'dan nüfus açısından korkunç farklılık gösteriyor, bunun sonucu olarak da Hindistan Çin gibi ucuz iş gücünün olduğu bir yer. Bu, bizim sanayimizin Çin'in sanayisiyle yarışmaya çalışması veya o modeli uygulamaya çalışması gibi olur.
Ayrıca, yazılımın emek yoğun bir iş olmasından dolayı, yatırım maliyetinin yükselmesi de rekabeti sağlamak için yeterli olamaz, buradakinin 5 de biri maaşla aynı işi yapabilecek kişilerin Hindistan'da mevcut olması bu yönden rekabet veya model kopyalanmasını imkansız kılmaktadır.
Kar Maksimizasyonu
Yazılım için üretim maliyetinin satılan adetle doğru orantılı olduğu aşikardır, eğer yapılan üründen bir tane yerine bin tane satılır ise kar bu kadar artıp maliyet bu kadar azalmış olur. Ayrıca, burada hammadde sıkıntısı olmadığı için, diğer üretim sektörlerine göre adet artışından elde edilen kar çok daha üstlere çıkabilir. Microsoft'un bir anda bu kadar büyüyebilmesinin bir sebebi, 1 kere üretip n kere satabilmesidir.
Ancak, yazılımdaki ekstra bir maliyet, değişiklik ve güncelleme talebidir. Diğer üretim sektörlerinde üretilen bir ürünün üzerinde değişiklik yapma ihtiyacı olmadığından maliyet sadece ilk üretim ve teslim anında, belki bazı sektörler için bakım vb durumunda oluyor. Ancak bakım maliyeti, yazılımdaki değişiklik maliyeti yanında küçük bir maliyet gibi duruyor.
Bir işletmenin karının hesaplanmasını kabaca satış fiyatı - maliyetler şeklinde düşünecek olursak, sektörden daha fazla nemalanabilmek için ya satış fiyatı artırılacak yada maliyetler düşürülecektir. Şimdiye kadar, Türkiye'de (ve bir süre öncesine kadar tüm dünyada) kar maksimizasyonu satış fiyatlarının yüksek tutulması ile sağlandıysa da, artık müşteri bu yaklaşımı kabul etmemekte, bu yüzden rakipler fiyat indirmekte, yüksek fiyatta satış yapanlar ise rekabet edememektedir. Bu durumda, gelinen durum, artık ayakta kalabilmek için dahi yapılacak şey maliyetlerin düşürülmesi ve bu sayede rekabet içerisine dahil olmaktır.
Maliyet ile ilgili kısım için tıklayınız.
Kaydol:
Kayıtlar (Atom)