Pazar, Ocak 31, 2010

Eflatun ve İyilik üzerine


Eflatun deyince aklıma ilk gelen resim (Devlet), mağara içerisinde yaşamaya mahkum edilen ve sonrasında gerçeğin gösterildiği kişilerdir. Karanlık mağara içerisindeki ütopik dünyada resmedilen bir kişi, gerçek dünya ve ışığı gördükleri anda korkar ve geri kaçmaya çalışır, ama sonrasında gerçeği tam olarak hissettiği anda artık geri dönmek ona hiçbirşey ifade etmez. Daha önce mağarada karanlıkta oturup gelip geçen gölgeleri seyrederken, o dönemde geliştirdikleri tahminler, geçişler ile ilgili ürettikleri fikirler, hayatları ve bu hayatlarındaki değişimin aslında tamamen manasız olduğunu ve ışığa çıktıkları zaman bu ilüzyonu farkederek artık geri dönemeyecekleri bir duruma düşer. Bu durum bilgi tarafından oluşturulur.

Aynı Matrixdeki haplar ve gerçek dünyayı görme gibi.

Burada Sokrat (Apology of Socrates), bu benzetmeyi, yaşanan dünya ve gerçek iyi arasında kurar, gerçek iyi, erişilmesi gereken, erişildiği zaman herşeyi değiştirecek ve tek amaç olacak şeydir, daha önce hayatta yapılan şeyler manasını yitirip boş uğraş haline gelir. Sıradan günlük yaşamla uğraşan kişiler, mağarada yaşayan kişiler gibidir ve bu kişiler, bir kere uğraşlarının ne kadar saçma olduğunu gördüklerinde artık geri dönmek istemeyecek, dönemeyecek ve gerçek iyiye ulaşmak için uğraşacaklardır.

Aynı gerçek iyi, Eflatun'un diğer yazılarında da ortaya çıkar, bu gerçek iyi, kişinin ulaşmaya çalıştığı varlık, kişinin kendisiyle ilgili çalışmasıyla ulaşılaiblecek bir yer olup, kişinin iyi olmayanla teması arttıkça gerçek iyi ile olabilecek ilişkisi zarar görerek, mağaraya daha da kenetlenir. Kişinin bu yüzden, iyiyi takip etme zorunluluğu öncelikle kendinden doğar, bu zorunluluk kanun yasa veya korku yüzünden değil, gerçek iyiye ulaşma kaygısından doğar. Bu da aslında etik felsefesini oluşturur.

Etik, eski yunan felsefesinde, bugün kullanılan gibi basit bir kavram değil, tamamen kişinin hayatını şekillendiren ve inanç sisteminin göbeğinde olan birşeydir, bugünün sevap günah kavramı gibi. Etikten uzaklaşan insan, gerçek iyiden, dolayısıyla erginlenmişlikten, bilgiden ve en son mutluluktan uzaklaşmış olur.

Sokrat, sırf iyilikten uzaklaşmamak pahasına, öğretilerinden herhangi bir para talep etmemiş, ücret olmadan aydınlatma ve fikir yayma çalışmasına devam etmiş, yaygın olan ve çok karşılaşılan sofistlerin aksine, ki bu da o dönemde aslında bu hizmetlerin para karşılığı verildiği ve paraya rağbet edildiği manasına geliyor.

İslam'ın yükselme devirlerinde, özellikle 9-13. yüzyıllar arasında antik yunan ile ilgili kitapların incelendiği bilinir bir gerçek. Hatta birçok kitabın yunancadan ilk arapçaya çevirildiğini hatırlıyorum. Sonradan bu yapıtlar Endülüs veya haçlılar vasıtasıyla Avrupa'ya doğru yayılmış. Bu da aslında eski yunan uygarlığının Avupadan önce müslüman kültürünü etkilediğini söylemek çok da anormal olmaz sanırım. Tasavvuf tarafına bakıldığında, buradaki mutlak iyi yerine gelen kavramlar sonucunda, mutlak iyiye ulaşmak nefsin zincirinden kurtulmak şeklinde ifade ediliyor, Doğu dinlerindeki gibi, ve nefsin zincirinden kurtulmak için de insanın yapması gereken şeyin kaba bir tabirle iyiliğe yönelmek olduğu görülüyor.

Bu şekilde aydınlanmış bir toplum, ideal bir toplum şekline en çok yakın olan toplum olacaktır kuşkusuz, yeterki iyiliğin ne olduğu konusunda saptırılmasın. İyiliğin ne olduğunun saptırılması bir çok örnekte var, en etkileyici olduğunu düşündüklerimden birisi de Hasan Sabbah'ın haşhaşinlerinin yaptıkları şeylerle ödüllendirileceklerinin kesin olarak kendilerine gösterildiği, intiharın dahi emir doğrultusuna yaptıklarında iyi bir hareket olarak nitelendirildiği ve bu intihar ile cennetle ödüllendirilmelerinin bunun hem iyi bir hareket olduğunun kanıtı hemde ödülü olduğu.

Başka bir saptırılmış iyilik hikayesi, haçlıların örneği olabilir, iyilik yaptığını düşünerek Kudüsteki tüm müslümanları atların bileklerine kadar kan akan sokakları görecek kadar kan akıtmış olmaları (Islam - Empire of Faith / BBC belgeseli). 

Hitlerin son sözlerinden birisi de (Der Untergang), yenilgi sonrasında Berlin'de çöküşü beklerken, en azından dünyayı Yahudilerden kurtarmayı başarmış olmasına sevindiği diye düşünecek olursak, aslında iyiliğin ne kadar göreceli ve saptırılmış olduğu da akla gelir. Burada da yahudilerin yaptıkları kötülükleri gören ve o kötülükleri engelleyerek dünya üzerinden bu kadar kötü kimseleri kaldırıyor olmak sürücü güçtür, bunu da birçok örnekler vererek Mein Kampf'da açıklar. Üstelik, diğer tarafta da, bu konularla ilgili yahudilerin suçlandığı durumda, yahudiler tarafına bakıldığında, aslında yaptıkları işler konusunda kendilerini kötü görüp görmedikleri de ayrı bir sorudur. Komunizmin getirilmesi o dönem Hitler için en büyük kötülüklerden biriyken, komunizmin dünyanın başına gelen en iyi şeylerden birisi olduğunu düşünen sayısı da az değildir. Hitler'in görüşlerini paylaşmayan ancak savaş sonrası Nürngberg mahkemelerinde bazı savaş suçlularına çok sert davranılmaması veya Almanya'nın daha fazla zayıflatılmamasının sebebi de aslında, karşı taraftaki Rusyanın ve Rusyanın içerisindeki komünizmin verdiği bir korku olduğuna göre, Hitlerin bir kötülük olduğunda hemfikir olan bir topluluk, aynen Hitlerin kötü dediği şeye kötü diyerek, ortak iyilik kötülük kesişimine sahip olmuştur.

Moğol saldırıları - özellikle Cengiz Han döneminde ise - Moğolların yaptıkları akınlar sırasında diğer bölgeleri korkutmak için kurduğu kesilmiş kafa kuleleri de, Moğollar açısından bakıldığında, dünya fethi ve sonrasında hem kendileri için hemde dünya için daha iyi olacağı ile ilgili bir iyilik anlayışı olarak gözükebilir.

Dale Carnegie'nin bahsettiği gibi, en azgın suçlular dahi yaptıklarını yaparken kendilerinin kötülük yaptığını düşünmeden (iyilik yapmıyor olsalar bile) bu işi yapıyor olmaları.

Bunlar gibi birsürü örnek verilebilir. Güncel olarak da bir sürü örneği vardır.

Sonuç olarak, kötülük ve iyiliğin göreceli olması, iyiliğe yaklaşma isteği olan bir insan olsa bile, iyiliğin ne olup olmadığını gösteren bir mekanizmanın olma gereksinimi. Bu mekanizma, temelde din olarak yerini bulabilir, ancak örneklerde gözüktüğü gibi, aslında din referansıyla yola çıkanlar bambaşka yerlere de gidiyor olabilirler. 

Çözüm nedir ? Bir toplumun iyiliğin ne olduğu konusunda fikir birliğine varması dahi, bu aksiyonu iyi yapmaz ve evrensel iyilik aslında sözkonusudur. Evrensel iyiliğin ne olduğunu arayış, arınmış bir ruh isteyebilir. Burada iyiliğin bulunması, kendi ruhunu temizlemiş ve iyilik kötülük konusunda kendi benliğinin ve egosunun içerisinden çıkabilmiş bir bakış açısıyla mümkün olabilir. İyiliği bir takım kurallara ve ritüellere bağlamak başlangıç için bir çözüm olarak durabilir gibi gözükse de, kuralın olmadığı veya hakkında birşey söylenmeyen hiçbirşey için bu durumda iyiliğin ne olduğu belirli olmayacak, flu bir alanda insanların anlayışlarıyla sınırlı kalacaktır. Burada özellikle vicdan demiyorum çünkü vicdan da kişinin kendi duygu ve düşünceleri ile hareket eden bir mekanizmadır, başlangıçta kabul ettiğimiz kişinin iyiliği aradığı varsayımı doğrultusunda düşünürsek, sürekli iyi hareket etmek isteyen bir toplum yada insan, bu şekilde de davranırsa, vicdanının rahatsız edeceği herhangi bir alan olmayacaktır. Zaten asıl tehlike kişinin kötü yaptığını bilerek değil iyiyi yaptığını düşünerek oluşan davranışlardan geliyorsa, asıl korkulacak şey iyilik kavramının kendisi olduğundan, iyiliğin manası netleştirilmeden gerçek iyiliğe ulaşılamayacağı malumdur.

Bu düşünceler sonrasında, iyiliğin tanımlanması gereken bir mekanizma, ancak kuralların değil, içsesin değiştirilmesi ve mantık yürütme yetisiyle iyiyi bulabilecek kişileri oluşturma arayışı da bir gereksinim olur. Burada her bireyin bunu bulabileceği seviyeye getirilmesi gibi bir fikir olabilecekken, bunun yerine, iyiyi bulmuş insanlar tarafından yönetilen bir toplum da ayrı bir çözüm olabilir.

Burada Eflatun'un devlet kitabındaki çözümü akla gelebilir : Aristokratik bir devlet yapısı anlatan Eflatun (yada kitaptaki anlatan olan Sokrat), devlet yöneticilerinin önce seçimi sonra yetiştirilmesi konusunda çok hassas davranmış, ancak 60 yaşından sonra kişilere yönetim hakkı vermiş, bu zamana kadar kendilerini geliştirmeleri gerektiğini söylemiş ve yönetimin sadece filozoflara verilmesi gerektiğini ifade etmiştir. Bu kişiler erginlenmiş kişiler olacağından, iyi ile kötüyü birbirinden rahatça ayırt edebilecek ve halkı doğru yönde ilerletebilecektir. Aynı zamanda yasa koyucu ve uygulayıcı olan bu kişiler, o anki ihtiyaca göre gerçek iyi tarafında durabilip buna göre toplumu yönlendirerek iyinin ne olduğunun tanımını anlık yapacaktır.
Eflatun'un Devlet'i ile ilgili sürekli olarak dikkatimi çeken başka bir konu gene sınıflar arası ayrımdan gelir, savaşçı sınıfın tanımı burada ilginçtir. Savaşçılar toplumun diğer kesimleri ile ilişki kuramaz, mal sahibi olamaz, aile sahibi olamaz ve ancak bu sayede düzeni tehdit etmeden kendilerine verilecek görevleri sağlayabilir. Bu kişiler gelecek endişesi taşımamalı, yönetim içerisinde bir çabaya girmemeleri için sadece savaşla uğraşmalı ve çocuk sahibi dahi olmamalıdır (çocuk sahibi olmak aslında vardır, ancak tüm sınıfın ortak çocukları vardır, kendilerine ait çocukları değil.)

Bu yapıyı ilk okuduğum zaman doğrudan aklıma gelen Yeniçeriler oldu, sonradan bozulmuş olsada, yeniçerilerin de kendilerine ait aileleri,çocukları  (tabii burada ortak çocuk ve kadınlardan da bahsedilmiyor, Eflatuna göre biraz daha sert gibi), mülkleri, ocak dışında yaşayacakları yerleri yoktu. Bunu mümkün kılabilmek için de toplum dışarısından kişiler seçildi. Bu kurumun oluşturulmasında Eflatun'un devletinin etkisi nedir bilemiyorum, ancak benzerlik çok ilginçtir. Aynı Devlette belirtilen yetiştirilen yönetici sınıfı için de, Enderun benzerlik taşır. Burada da ayrı bir sınıf, seçilen ve yıllarca yetiştirilen çocuklar, birçok alanda eğitim alarak devletin mekanizmalarında görev alır.

Eflatun'un devletinde geçen konulardan bir tanesi, demokrasi verilen halklarda, halkın bir süre sonra bozulmaya uğrayacağı, verilen özgürlüklerden daha fazlasını isteyerek, cahil kesimin bir süre sonra bilgililere, gençlerin yaşlılara saygısını kaybedeceği, özgürlük vaadiyle sürüklenen toplumun sürekli bireysel olarak daha fazla hak isteyeceği ve demokrasinin çekilmez bir hale gelip sonrasında muhakkak tiranlığın geleceği, çünkü bu durumu düzeltebilen bir yöneticinin halk gözünde çok üstün bir yere oturtulmasından bu kişi istese de istemese de halkın gözünde tek yönetici olacağı, sonucunun da tiranlığa gideceğidir.

Demokrasiye saldırıda bulunan kişilerden bir taneside Hitlerdir, demokrasinin özellikle hatalar sonrasında mesul tutulacak kişilerin bulunmadığı bir yapı olduğundan bahseder, kendisi seçimle başa geldiği halde, daha sonraki halkın desteğiyle tirana dönüştüğü malumdur. Bu dönüşme halka rağmen değil, halkla birlikte olmuştur. Aynı örnek Julius Caesarda vardır, J. Caesarın başarıları ve yönetiminin etkileyiciliği sonrası tiranlığın geleceğinden korkan senato üyelerinin Caesarı öldürmesi sonrası, daha sonra Augustus adını alacak Octavian, Roma'nın düşmanlarına saldırıp yendikten sonra da yarı tiranlığa ulaşmıştır.

Benzer savlar olmasada benzer hislere sahip olan Türkiyedeki bazı gruplar, halkın çoğunluğunun seçtiği bir iradenin, aslında halk adına karar verecek kadar yetenekli ve bilgili olmadığını söyleyerek özellikle ordu ile ilişkiler vasıtasıyla yarı demokratik yarı militer bir rejim yanlısı oldular. İnönü döneminde köylere neden yol yapılmadığı sorulduğunda, yol yapalım da insanlar kente mi gelsin şeklinde verdiği bir cevap vardır. İnsanların kente gelmesi, yeni kurulan hassas bir demokraside, demokrasinin istenmeyen bir demokrasi olacağının işaretidir, ki sonrasında Menderes dönemiyle, demokrasinin tartısında, aslında kurucuların çok da istemediği (en azından bazılarının) bir yapının oluşması görülmüş, hala da kendine sol diyen ancak aslında muhafazakar olan bu kesim içerisinde bedbaht bir olay olarak anılmıştır. (sol aslında demokrasinin daha fazla yanında yeralması gereken kesim olduğu için muhafazakar olan diyorum).

Demokrasinin başlangıçta savunulması, imparatorluk sonrasında imparatorluğa ait olan mekanizmaların reddi için demokrasinin gerekli olan şeylerden biri olmasıdır. Aslında demokrasi, burada monarşiden sonra gelebilecek bir çözümdür ve monarşinin ortadan kaldırılması için gereklidir. Sonrasında gelen demokrasi, bu ekibin kurduğu bir demokrasidir ve kurallar demokrasiyi bilmeyen halk tarafından değil demokrasiyi kuranlar tarafından belirlenir. Aynı halk, bir süre sonrasında demokrasiye alışıp ibreyi kendi yönüne çevirince, demokrasinin Türkiye içerisinde kurucuları olan kişiler bu ibre yönünden rahatsız olarak demokrasinin kurucuların istediği şekilde gitmesi gerektiğini düşündüklerinden bu tarafa doğru yönlendirirler.

Bu kısımlara geldiğimde belirtmek istediğim şey aslında halk her zaman haklıdır veya demokrasinin önünün açılması gerektiği değildir aslında. Demokrasi ile ilgili düşünmeye başladıktan sonra, kendimce Türkiye içerisindeki gelişimini de değerlendirmeye çalıştım, ama genel bir yönetim şekli olarak demokrasinin ne kadar işe yaradığı ayrı bir tartışma konusudur.

Gene Roma'da, senatoya karşı Caesar veya yöneticiye karşı senatonun kullandığı araç, kalabalık alt halk kitlesi gücüdür. Bunların ikna edilmesi her durumda Roma'nın yönünü belirler. Roma'nın yönü, halkın istediği yöndür, ve Roma'nın halkı bunu isteyerek bir süre sonra Roma'yı monarşiye çevirmiş, buradaki senato etkisiz hale gelmiştir. Bunun doğru mu yanlış mı karar olduğu konusunda tartışacak kadaar bilgim yok, bu olmasaydı Romanın daha fazla devam edip etmeyeceği de bilinmeyen bir soru işareti.

Burada önemli olan nokta, değişik idare şekillerinde halk değişik şeyler için kullanılmış, bu kullanma işlemi de halkın iyi olduğunu inandığı kişi veya olgu yönünde yönlendirilmesi sonucu olmuştur. Bu yönlendirme, direk bir iş yaptırmak isteyen kişi/ekibin korkutmasıyla veya sindirmesiyle değil, iyinin ne olduğunun öğretilmesiyle sağlanmıştır.

Sonuçta gene iyi kavramının manipüle edilmesi tehlikesi ile başbaşa olduğumuzda, iyiyi belirleyen kişilerin gene iyiyi isteyen halkı kolaylıkla yönlendirebildiğini ve halkı yönlendirenin de herşeyi yönlendirebileceğini belirtir. İyinin gerçek iyi olup olmadığı her zaman bir soru işareti olarak kalabilir. Farklı olarak, demokrasi, topluluğun en çok beğendiği iyinin peşinde gitmesidir, gerçek iyi olan iyiyi bulma yetisine sahip olmayan halk (yeterince erginlenmiş olmadığı için) rotayı yanlış yöne çeviriyor olabilir.
Bu durumda, ciddi anlamda aydınlanmış topluluk olan eski yunan şehir devletlerinde dahi, demokrasinin mümkün olmayacağı ifade edilirken, bugünkü beyni yıkanmış topluluk için de demokrasinin doğru olup olmadığı da sorgulanabilir. 

Burada belki alternatiflere bakmakta da fayda olabilir, demokrasinin alternatifi olan bir yönetim, mesela Türkiye örneğinde, gene Aristokratik bir yönetim, hem uzun süre başarılı olamamış, hemde herkes tarafından iyi kabul edilen bir takım davranışlarda bulunamamış ve aslında başarısız olmuştur.

Burada soru Aristokrasinin kim olacağıdır, soru artık ne den kime döner, yeterince olgunlaşmamış bir aristokrasi, halkı kötü yönlere sürükleyebilir, üstelik halkın bu doğruda aynı fikirde olması da başka bir problemdir, Fransız İhtilalinin aslında monarşiden çok aristokratik düzenden kaynaklanması gibi. Charles Dickens'ın A Tale of Two Cities de verdiği en etkileyici örnek, marki'nin arabası altında ezilen çocuğun ve ona karşı markinin kayıtsızlığıdır. Avrupada aristokrasi aynı zamanda din tarafından da savunulmuş, 1793 te Vendee li asilzadenin, kardeşini öldürdüğü sandalcı tarafından öldürülmemesinin tek sebebi, o kişinin senyörü olan markiyi öldürdüğü takdirde sandalcının cennete gidemeyeceğine inanmasıdır.

Moğollar veya Hitler örneğine bakacak olursak da, bir toplumun bir konuda fikir birliğine varmış olması, bir Aristokrat kesimin toplumla barışık olması da aslında sonuçta ne topluma nede dünya geneline faydalı olacağı anlamı taşımadığını gösterir.

İşte bu yüzden eğer olacaksa bu tür bir aristokratik yapının aslında politika veya ekonomi üzerine yetişmiş ve genel dünya düzeni hakkında çok etkili veya başarılı kişiler değil, gerçek olgunlaşmış kişiler olmasını gerektirir, spritiüel düzende olgunlaşmış bir elit, diğer elitler gibi olmayacaktır. Ancak bu elitin de oluşturulması veya bulunması çok zordur. Bu tür bir yapı sözkonusu olduğunda, bugün toplumları da bundan 1000 yıl önceki toplumların tamamı gibi din tarafına bakmak zorundadır, zira din mekanizmasının dışında bir sprititüel zenginleşme ancak minör radikal topluluklarda mevcuttur.

Bu elitin oluşturulması durumunda, diğer tüm yeteneklerin daha alt sayıldığı, tüm yönetimin spiritüel olgunluk elinde olduğu bir mekanizmadan bahsederiz. 

Roma'da ki bir söz gibi, başka toplumlar çok iyi bronz işçiliği yapıyor, çok iyi fikir oluşturuyor, çok iyi marangozluk yapıyor olabilir. Bunları biz yapamayız, yapmak zorunda değiliz. Roma fetheder ve yönetir. (Idiots guide to Roman Empire)

Diğer kesimler bu spiritüel kesimin yönlendirmesinde gider, ama aynı Drucker (Effective Executive kitabı)'ın Knowledge Worker yöneticisi gibi, yönetenler yönettikleri kişiler kadar çok şey bilmez, işi asıl yapanlar yönetilenlerdir, yöneticiler onların doğru iş yapmasını sağlar.

Bu düşünce doğal olarak bizi teoloji tarafına doğru götürür. Gene haçlı seferleri örneğinden, teolojinin de aslında bir çözüm olmadığı, teolojik bir yapının çoğu zaman gerçek spiritüel olgun kişilerin oluşturulmayacağını da görmüş oluruz. Osmanlı'nın kısmi teolojik yapısının son yıllardaki çökme olgusunu da içerdiğini düşünürsek, cevap burada da değildir. Bu aynı zamanda farklı dinlerdeki davranışlar sonrasındaki çözülmeleri de açıkladığından, bu din değil şu din olduğundan şeklinde bir yargıya da varılamaz, din tek başına yeterli bir mekanizma olmayacaktır, muhtemel yardımcı, ancak tek başına bir çözüm olamaz.

Kısmen oligarşik düzenin yönlendirdiği Amerika örneğinde görüldüğü gibi, bu tür bir yönetim şeklinin de çözüm olamayacağı gözükür. Sosyalist/Komunist düzenlerde aslında kısmen aristokratik bir yönetim düzenidir, bunun da geçerli olmadığı 100 yıl dayanamayan örneğinden anlaşılır. Ayrıca Stalin dönemi yaşanan sürgünler ve yöneticinin kendi halkına yaptığı eziyet, bunun gerçek iyiden çok uzak olduğunu da gösterir.

Çözüm nedir ? Sanırım çözüm buralardan farklı yerlerdedir, çözüm topyekün erginlenme, topyekün bilgilenmedir, böyle birşey olabilirse. Bugünkü toplum buna çok uzak ve belkide bunun başarılabilmesi için çok büyük, daha küçük toplumlarda, daha küçük sistemlerde bu oluşabilir, belki yapay olarak oluşturulması da mümkün değildir, o seviyeye gelmek gerekecektir, ama küçük de olsa bir toplumda bu başarılırsa da, bu toplum küçük kalmayacak, büyüyecek, sonuçta bu yeni büyük toplum da etik açıdan zayıflayacak ve çökmek zorunda kalacaktır. Yani bu tür birşeyin başarılması, evrensel seviyede değil, ancak lokal olarak mümkündür, yada bünyeye dahil edilen yeni parçaların yavaş yavaş sindirilmesi, önce toplum mühendisliği yapılması.

Haddim olmayan konularda fazlaca yazmış oldum.




Pazartesi, Şubat 09, 2009

Salı, Eylül 09, 2008

Pazar, Şubat 25, 2007

Bilgi Yönetimi

İş dünyasına bakıldığı zaman, görünen şeylerden bir tanesi, gücün bilgi ile eşdeğer olarak gitme davranışı mevcut olduğudur.

Bu bilgi yumağı, hangi sektörde olursa olsun, firmaların sadece ileri gitmesi veya başarılı olmasını değil, varoluşlarını da direk etkileyen bir değerdir. Aynı değerlendirmeler belki ülkeler için dahi yapılabilir.

Bilgiden kasıt, çok farklı şeyleri içerebilir. Ticari değeri olan bilgi olarak ilk başta görünebilecek olan direk iş imkanlarıyla ve satışla alakalı olabilecek bilgi veya rakipler ile ilgili bilgi olsa da, aslında daha önemli olan bir takım bilgiler kurum kimliğini oluşturur ve rekabet gücünü belirler.

Bu bilgi, arasında, insan kaynakları politikası, muhasebe ile ilgili yaklaşımlar, proje yönetimi, firma içerisinde tanımlanmış olan süreç davranışları, stratejik kararlar ve yol haritası, bazı kişi ve kurumlara karşı belirlenmiş davranışlar, projeler süresince edinilmiş tecrübeler olabilir.

Bir otomotiv üreticisi için otomotivin nasıl üretildiği, hangi maddelerin kullanıldığı, ideal maaş skalaları vb gibi tüm bilgiler, değeri olan, işletmeyi yürütmek için belirli kriterler dikkate alınarak meydana gelmiş bir karar yumağıdır.

Yazılım sektörü için, bu bilgi bahsedilen konular dışında, ayrıca, yazılım geliştirme metodolojileri, tekrar kullanılabilir kod parçacıkları ve componentlar, kullanılan toollar ile ilgili edinilen tecrübeler, kullanılan teknolojiler olduğu kadar, bu kodlar kullanılarak hayata geçirilen alan bilgisi de çok önem taşımaktadır. Örnek olarak, bir muhasebe yazılımındaki alan bilgisi, sadece muhasebe yazılımı içerisinde kalamayacak kadar değerli bir kaynaktır. Bu bilgiye ihtiyaç olan herhangi bir başka projede erişilmesi gerekecektir.

Bilgi Koruma
Mevcutta genel davranış, bir kişiyi alanla ilgili bilgilendirmek ve bu alanla ilgili işler yapılması gerektiği zaman bu kişiye yaptırmak, imkanlar daha geniş ise bu alanı bilen kişi(ler) i istihdam etmek şeklindedir. Ancak bu davranış, bilginin paylaşılmasını engeller, kurumu kişiye bağımlı hale getirir. Bu kişi bilgiyi kurum içerisinde kazanmış veya kurum içerisine bilgiye sahip halde gelmiş olabilir, ancak gittiği zaman bu bilginin kuruma kazandırılmış olması, kurumların kişilerden bağımsız olmasını sağlayabilir.

Aynı zamanda, tek kişinin sahip olacağı bilgi, kurumun tümünün sahip olacağı bilgi kadar fazla olamayacağından, tek kişi, sadece kendi bilgisi ile kararlar verme ve hareket etme mecburiyetinde iken, kurum içerisinde yoğurulabilen bir bilgi, kurumda yayılarak, farklı fikirlerin birleşmesi ile, daha olgun bir hale gelir.

Firmalar her zaman kendi çıkarlarını kollamalı, yapmış olduğu yatırımları korumalıdır. Bu amaçla müşterilerle ilişki sıkı tutulur, çalışanların memnuniyeti dikkate alınır, kurumun toplumdaki bilinirliği ve güvenilirliğini artırmak için çalışmalar yapılır. Kurumun değerli sayılabilecek her türlü mevcudatı korunmaya çalışılır. Ancak, en önemli rekabet gücünü oluşturacak olan bilgi, unutma kadar olası bir olayın oluşumuna karşı dahi önlem almamış durumdadır.

Bu fikirler ışığında, bilginin kollanması, korunması ve paylaşılması gereksiniminin olduğu net olarak gözükmektedir.

Bilgi Paylaşımı

Özellikle yazılım sektörü için, yeni işe başlayan bir kişinin bilgilendirilmesi ve veriminin artırılması çok önemlidir. Mythical Man Month'da belirtildiği üzere, yazılım yapan kişiler arasındaki fark 1/20 kadar olabilir. Yani, iki farklı kişi için, bir kişi diğerine göre 20 kat daha verimli iş üretiyor olabilir. Bu durumda, 1 birim üretim yapan kişiyi 20 birim üretim yapar hale getirmedikçe, tam kapasite kullanımı olduğu söylenemez. Bu, teknik açıdan bilgi paylaşımıdır.

Yapılan yazılım hangi alanda olursa olsun, bir firmanın daha önceden hakkında bilgi edindiği bir alanda çalışma yapması durumunda, daha önceki bilgilerinden faydalanması, bu firmanın iş becerisini, karlılığını, doğruluğu ve müşteri memnuniyetini artıracaktır. Bu davranış, büyük yabancı yazılım firmalarında net olarak gözlenebilir. Bilgileri ve tecrübelerini farklı ülkelerdeki çalışanlarına dahi aktaran bu firmalar, birikmiş tecrübeleri sayesinde rekabet edilemez bir güç olmayı başarmışlardır. Bu bilginin oluşturulup, herhangi bir alanda yazılım analizi veya geliştirme esnasında elde edilen bir bilgi, paylaşılmalıdır.

Bilgi paylaşımı, sadece bilginin korunması ile sağlanamayacaktır. Bilgi, şu anda zaten mevcuttur. Bu bilgi kitaplarda veya internettedir ancak bu şekilde saklanan bilginin kazanılması, aktarımı, paylaşımı çok zaman alan bir iştir. Paylaşılabilecek bir bilgi, öncelikle kolay bulunabilir olmalıdır. Ayrıca, ihtiyaç olunduğu zaman kolay bulunabilir olmalıdır. İhtiyaç olunduğunda bulunamayacak veya ihtiyaç olunmadığı zamanda bulunacak bilgi kümesi faydalı değildir. Geçmişte yapılan projeye benzer tekrar yapılan bir projedededir ki geçmişte ihtiyaç duyulan bilgiden faydalanılabilsin.

Bu fikirler doğrultusunda, knowledge management alanında çalışma yapmaktayım. Bu çalışma kuşkusuz bir tool veya yazılım olmadan gerçekleştirilemeyecektir. Öncelikle,

- Ortak saklama alanı yaratılmalı
- Ortak paylaşım alanı yaratılmalı
- Kişiler paylaşmaya sevkedilmeli
- Paylaşılacak bilgi belirlenmeli
- Ulaşılması istenen bilgiye ulaşmak için yöntemler bulunmalı

Bunlar doğrultusunda wiki ile çalışmaya başlayacağım. Kurumsal bir wiki kurulumu yapıp, bilginin aktarılmasını bir rutin davranış haline sokmak, sanırım ilk başarı adımı olacak.

Cuma, Kasım 10, 2006

SQL Server 2000 Enterprise Manager Yavaşlaması veya Kilitlenme Sorunu

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.

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 .

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.

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.

Pazar, Ağustos 20, 2006

Yazılımda Modülarite Nedir ?

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

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

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

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

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

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

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

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

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

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

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

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

Salı, Ağustos 15, 2006

Yazılım ve Performans

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

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

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

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

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

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

Pazartesi, Ağustos 14, 2006

Java vs. Dotnet

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

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

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

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

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

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

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

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

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

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

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

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

İş Gücü Maliyeti

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Frameworkler

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

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

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

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

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

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

- Client Application için Swing

- Kod üretme için Xdoclet

- Data mapping için hibernate

- Kural implementasyonu için Drools

- Flash üretebilmek için openlazslo

- Inversion of container için Spring

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

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

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

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

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

Performans

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

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

Sonuç

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

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

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.

- 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.
Sorun

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.