Yazılım Mühendisliği

Özcan Hocanın öncülük etmesiyle türkiyenin ilk Java Dergisi bayilerde yerini almış bulunuyor tükenmeden kapışın derim Gerçekten kaliteli bir içeriğe ve tamamen gönüllülük usülü ile çıkarılan derginin çok başarılı olacağına inanıyorum.
Bu benim içinde bir ilk olmuş oldu çünkü ilk defa bir yazım dergide yayımlandı. İçerisinde acizane çok sevmesem de bir adet Singleton Design Pattern yazım bulunmaktadır:) Neden sevmediğimi dergiden öğrenebilirsiniz.(Okuyucuyu teşvik edelim ) Ben daha elime alamadım fakat en kısa zamanda almayı düşünüyorum. Umarım herkes için oldukça faydalı bir dergi olur. Başta Özcan Hoca olmak üzere emeği geçen herkese teşekkür ederim…

Javascript programlama dili içerisinde eval fonksiyonu genellikle dinamik kod çalıştırmak için kullanılıyor. Örnek olarak server tarafından dönen bir JSON formatındaki nesneyi eval fonksiyonu ile Javascript nesnesine kolaylıkla dönüştürebiliriz.

Bunun dışında Javascript kodlarına baktığımda içerisinde eval gördüğüm yerlerin çoğunda kullanım yanlışlığı var ve bunun sebebi Javascript dilini iyi bilmemekten kaynaklanıyor. Eval’in yanlış kullanımına dair sıkça gördüğüm durumlardan bir tanesi şöyle oluyor.Örneğin bir nesnenin bir özelliğinde formu kayıt ederken çalıştırılacak fonksiyon ismi tutuluyor.

var form ={
	name :'Save',
	url : '/Form/Save',
	validation_function :'validateForm':
}
function save(form,element){
    eval(form.validate_function+'(element)');
    //....diger islemler
}

Yukarıdaki kodda formu kayıt ederken nesnenin özelliği olan hangi validasyon fonksiyonuna gireciğini kullanıp bu fonksiyonu çalıştırmak.Bu fonksiyon her nesne için farkı olabileceği için burada sabit bir fonksiyon çağıramıyoruz. Yani yapmak istediğimiz aslında dinamik olarak belirlenen bir fonksiyonu çalıştırmak bunu da yukarıdaki gibi eval kullanarak kodu çalıştırdığımızda Script Engine dinamik kodu tekrar derleyip belleğe yükledikten sonra çalıştırmaktadır. Bu da performans bakımından oldukça masraflı bir işlemdir.Kısacası balyoz ile sinek öldürmek diyebiliriz yani:) Bu yüzden gerçekten gerekmedikçe eval funksiyonundan kaçınmak Javascript performansı için oldukça faydalı olacaktır.

Peki yukarıdaki kodu eval kullanmadan nasıl yazabilirdik? Çok basit Javascript dilinde aşağıdaki iki ifade aynı şeyi yapar.

    nesne.method();
    nesne['method']();

Javascript içerisindeki fonksiyonlara yada nesnenin özelliklerine “.(dot)” notasyonu dışında “[](array)” notasyonu ile de ulaşabilirsiniz. Bunun dışında bilmemiz gereken birşey daha var; tanımlanan bütün fonksiyonlar global window nesnesine aitdir.Yani aşağıdaki 3 satır kod da aynı şeyi yapar

    function taklaAt(){
        //takla at...
    }

    //aynı seyi yapan satirlar
    taklaAt();
    window.taklaAt();
    window[taklaAt]();

Bu bilgileri de öğrendikten sonra ilk kodumuzu aşağıdaki gibi yazabiliriz.

var form ={
	name :'Save',
	url : '/Form/Save',
	validation_function :'validateForm':
}
function save(form,element){
    window[validation_function](element);
    //....diger islemler
}

Yukarıda ne yaptık? Window nesnesine ait olan dinamik fonksiyonumuzu array yani [] ile çağırdık.Javascript gibi performansın gerçekten önemli olduğu bir dilde yukarıdaki yaptığımız işlem oldukça iyi performans kazancı sağlayacaktır. Ayrıca debug ederken eval ile çağırılan fonksiyonların debug edilmesi normallerine göre daha zor olduğu için eval kullandığınız heryeri gözden geçirmenizde fayda olabilir.

Boşuna Eval is Evil dememişler

Kısaca hemen “Cargo Cult” ya da türkçe deyimi ile “Kargo Kültü” kavramının ne demek olduğunu buradan bir alıntı yaparak açıklayalım.

Güney Pasifik’te daha önceleri Batı dünyasından kimsenin uğramadığı, unutulmuş birtakım adalar, II. Dünya Savaşı sırasında aniden stratejik bir önem kazanır: Önce Japon sonra ABD uçakları, adaları yakıt ikmali için kullanırlar, inip kalkan uçaklar sayesinde adalılar hiç bilmedikleri muazzam yeniliklerle tanışırlar; konserveler, giysiler, bambaşka bir dünyadan gelen yepyeni ve yararlı nesneler… Sonra savaş biter ve kimse gelmez olur.

Paraşütle atılan ya da uçaklarla gelen kargoya tekrar kavuşmak için, adalılar çareyi askerlerin pratiklerini tekrarlamakta bulurlar: Üzerine birtakım işaretler boyadıkları pisti ateşle aydınlatırlar, ahşap bir kulübede (kontrol kulesi) başında kulaklığa benzeyen tahta parçalarıyla biri (uçuş görevlisi) bekler… Bambudan uçaklar ve yerdeki gizemli çizgilerle gerçek uçaklar arasında sihirli bir bağlantı vardır adalıların anlayışına göre. Uçakların tekrar gelmesi için, her şey yapılmış, her önlem titizlikle alınmıştır. Gelen giden olmaz, o ayrı.

Kargo Kültü kısaca bir süreci ya da sistemi anlamaksızın, en dışsal, en yüzeysel görünümlerini tekrar ve taklit ederek yeniden üretmeye çalışmak.

Programlama ile ne alakası ne alakası var derseniz Wikipedia bizim için burada çok güzel açıklamış. Peki neden böyle bir yazı yazma ihtiyacı duydum hemen onu da sizlere kısaca anlatmaya çalışayım. Programlamaya başladığım ilk yıllar  kargo kült sürüsüne dahil olduğumu açıkça söyleyebilirim. Ne yapardık peki bu sürüde ? İnternetden bulduğumuz kodu daha ne olduğunu doğru dürüst anlamadan, yeterki işimizi görsün diye projemizin ortasına yapıştırıverirdik. Nede olsa tekrar kullanılabilir kod böyle birşey olsa gerekti. Lazım olduğu sürece kopyala yapıştır gitsin. Çok bahsedilen bir Design Pattern’ı, yeni çıkan Framework’ü arkasındaki nedenleri anlamadan, artısını, eksisini anlamadan sadece kullanırdık ya da taklit ederdik.

Peki bunun dezavantajı nedir? Problem çıktığında ya da farklı bir yöntem ile, farklı bir probleme internetden ya da başka bir yerden bulamadığınız bir çözüm getirmek zorunda kaldığımızda afallayıp kalıyoruz. Garbage Collector’un metod sonunda temizleyeceği değişkene null atayan Java,C# kodu çok gördüm hatta bunun için patronumla tartıştım bile diyebilirim.

Hatta kendi adıma jQuery’nin yaptıklarını sihir yapanları sihirbaz olarak düşünüyordum diyebilirdim. Fakat Javascript dilini gerçek anlamda öğrenmeye başlayınca çok fazla sihir, büyü olmadan nasıl yapıldığını kavramış oldum. Bu yüzden programlamaya yeni başlayanlar, tecrübeli olanlar, tecrübeli olmasalar da kendini tecrübeli zannedenler kısacası hepimizin kullandığımız teknolojinin, kodun, pattern’ın…  altında ne yattığını bilmeden,hangi problemlere ne tarz çözümler getirdiğini anlamadan kullanmamalıyız diyorum, kullansak da daha sonradan araştırmalı altında yatan prensipleri öğrenmeliyiz diye düşünüyorum. Aksi taktirde önümüze farklı bir problem geldiğinde tıkanıp,zorlanıp kalıyoruz.

Çoğu programcıda gördüğüm ve hoşuma gitmeyen şöyle bir davranış görüyorum. Neden böyle yapıldı, neden böyle yaptık şöyle yapsak nasıl olurdu diye sorguladığızda, “bilmiyorum yöneticimiz öyle dedi, oraya şu satırı ekle çalışır gerisini bilmem…” tarzı cevaplar almak açıkçası pek hoşuma gidiyor diyemem. Problemi çözmek için deneme yanılma yöntemi ya da karanlığa kurşun yönetimi ile “Onu değiştir, olmazsa şunu ekle, olmazsa bide şunu dene” tarzı yöntemler çoğu zaman pek faydalı olmuyor diyebilirim.

Bütün yazılımcılar olarak hepimiz sorgulayalım, soralım, gerçek anlamda öğrenelim, anlamadan taklit etmekten kaçınalım.Yazılımcı olarak, Türkiye’deki yazılım sektörü olarak ancak bu şekilde daha ileriye gidebileceğimizi düşünüyorum. Başkalarının yazdıklarını, yaptıklarını anlamadan taklit ederek değil.

Kısaca sıralarsak

• Kullandığınız kodun ne yaptığını ,
• Kullandığınız framework, mimari .. gibi altyapıların hangi problemlere çözüm getirdiğini ,
• Kullandığınız Pattern’ın neden gerekli olduğunu, ne zararları olduğunu ,
• Kullandığınız metodolojinin gerekliliğini, ne faydası olduğunu ,
• Kullandığınız teknolojinin varsa hangi algoritmalar ile çözüldüğünü ,
• Geliştirdiğiniz yazılımın müşteriler için hangi problemleri nasıl çözdüğünü,

Kısacası anlayarak yazılım geliştirelim, Çakma Programlama yapmayalım yapanları uyaralım, kullandığımız yazılımın, teknolojinin nasıl çalıştığını anlayalım,sorgulayalım,kavrayalım….

Merak eden varmıdır bilmiyorum fakat ben yinede iyimser düşünüp merak edenler için açıklama yapayım dedim. Uzun zamandır yazamıyorum sebeplerini kısaca şöyle sıralayabilirim.

Sanatımızı sürekli icra etmeden usta olamayacağımızı düşündüğüm için, çok okuyup, çok yazı yazmak yerine, az okuyup çok kod yazmak yönünde bu aralar tercihimi kullanıyorum.  Bu yüzden sürekli yakındığım politik ve diğer bazı nedenlerden dolayı iş ortamında uygulayamadığım yazılım pratiklerini kendim evde uygulamaya karar verdim ve kolları sıvadım diyebilirim.Yani  Hackers and Painters kitabında verilen tavsiyeye uydum karnımı doyuran bir gündüz işine sahibim, geceleri ise istediğim pratiği uygulayabildiğim, pratik yapabildiğim, sanatımı icra edebildiğim projelere sahibim. Lafı fazla uzatmadan bahsedeyim nelerle uğraşıyorum?

ASP.NET MVC,NHibernate,jQuery,DI,TDD kullanarak uzun soluklu bir proje geliştiriyorum.

Gerçek anlamda JavaScript öğrenmeye çalışıyorum.

Perl,Ruby on Rails’e göz kırpıyorum.

Sizlere, başkalarına birşeyler öğretmek için öncelikle kendim yaşamalıyım o yüzden bu projeler süresince öğrendiklerimi, uyguladığım pratikleri ve belkide kaynak kodlarını sizinle paylaşacağım. Hatta kalmaya devam edin çok yakında güzel projeler ve yazılarla tekrar birlikte olacağız.

Daha önceden yazdığım Yazılım Mühendisi Maaşı yazısından en çok okunan yazılardan biri oldu. Ayrıca birçok kişi tarafından yorum yapıldı ve kaç YTL maaş alındığı konusunda sorular soruldu. Bu yüzden daha önceden belirtmediğimiz rakam olarak maaş konusunu açıklığa kavuşturalım istedim. Hemde sektöre girenler, girecekler.. için bir klavuz olsun.

 Loading ...

Maaş ücretleri için yukarıda gördüğünüz anketi hazırladım. Fakat yazılım sektöründe maaş konusu tecrübe, uzmanlık, çalıştığınız il,okul.. gibi birçok parametreye göre değiştiği için anketten ziyade bu yazının sonuna yorum olarak isminizi vermeden

• Mezun olduğunuz okul
• Mezun olduğunuz bölüm
• Çalıştığınız İl
• Çalıştığınız uzmanlık alanınız
• Sene olarak tecrübeniz
• Aldığınız brüt ya da Net Maaşınız

Yazarsanız bu konuda oldukça meraklı olan arkadaşları oldukça sevindirirsiniz. Mühendis, programcı, başka alandan mezun olup yazılım alanında çalışan kısacası Yazılım Uzmanı olan herkesin anketi doldurmasını temenni ediyorum.  Yorumların arasına bende kendi maaşımı ekleyeceğim ama isimsiz tabi

Mart ayının son haftasında Ceturk davetlisi olarak Elazığ Fırat Üniversitesi etkinliğinde Design Patterns konusunda konuşmacı olarak bulundum. Özcan Acar,Mehmet Aca ve Gökay Okutucu ile tanışmak güzeldi.

Seminer notlarını ancak şimdi yazabiliyorum.Notları derken “seminerde şunu yaptım,bunu yaptım, şuraları gezdim” gibi cümlelerden ziyade bildiklerimi öğretmek için gittiğim seminerden neler öğrendim ondan bahsetmek istiyorum.

• Bilen öğretir, bilmeyen yönetir. (Ramazan hocaya sonsuz teşekkürler.)
• İstekler sonsuz, kaynaklar sınırlı.(Özellikle zaman)
• Kendimi sunum konularında geliştirmeliyim

Tası tarağı topladık Elazığ yollarına düştük. Yarın Ceturk’ün davetlisi olarak Fırsat Üniversitesinde Design Patterns üzerine bir sunum yapacağım sizleride beklerim…

Orjinal adıyla “Should architects write code?” olan meşhur soruya kendi kişisel cevabımı burada vereyim. Soru belki binlerce kez cevaplandı, herkes kendince fikirlerini belirtti fakat yinede birkaç ayda bir bu sorununun yazılım dünyasındakilere hatırlatılması gerektiğini düşünüyorum.Peki neden?

Yazılım mimarı ünvanı adı altında,ya da projede yazılımın tasarımında,mimarisinde rol alan insanların genelde şöyle bir eğilimi olduğunu sık sık görüyorum. Yazılım mimarı arkadaş gereksinimlere göre Visio, Enterprise Architect,Rational Rose…gibi araçlarda güzel güzel UML diyagramlarını çizmiştir.Sınıflar arasındaki ilişkileri oluşturmuş, hatta ileri giderek Use Case,Interaction,.. diyagramları çizmiştir.Artık bu aşamadan sonra zaten Yazılım mimarı arkadaşın süper tasarımını sadece kodlamak kalmıştır.”Ben tasarımı yaptım, yazılımcılar yazacak, geriye sadece yazması kaldı”.

Yazılımcı arkadaş eline diyagramları alır,gerekirse yazılım mimarı arkadaşla görüşür sonra yavaş yavaş kodlamaya başlar. Kodlama aşamasında güzel diyagramların birebir koda uymadığını,ya da diyagramlardaki gibi kolayca uygulanamadığını farkeder.Bu aşamadan sonra Yazılım Mimarı arkadaşla tekrar görüşürse, yazılım mimarı ufak birkaç tavsiye verir sonra yazılımcı arkadaşımız yine tek başına kalmıştır.Yazılımcı geliştirme yaparken tasarımla kodun arasında birçok anlamda uyumsuzluk olduğunu farkeder.Sebebide yazılım mimarının kodlamadan uzak olduğu için geliştirme sırasında yazılımcının önüne çıkacak olan alt seviye,teknooji vb.. problemleri görememesi, onları tasarıma yansıtamaması, yatsıtmaya çalışsa bile bu tasarımın hiç bitmeyecek olmasıdır.

Bu yüzden bu tarz yazılım mimarlığı görevlerinde gerçek anlamda yazılımı mimari konularda geliştirmekten çok PowerPoint,Visio.. gibi araçlarda çizim yeteneklerini geliştirmeye yarıyor.Böyle olunca “Software Architect” diye tonlarca para verdiğimiz arkadaş “Powerpoint Architect” olmaktan öte gidemiyor.

Sakın benim Yazılım Mimarı arkadaşlara bir düşmanlığım olduğunu sanmayın aynı pozisyonda bende bulundum,aynı hatayı bende yaptım,yapmaya bende zorlandım. Günlerce kafa yorarak tasarladığım süper tasarımların yazılımcılar tarafından geliştirilmeye çalışılırken ne kadar zorlukla karşılaşıldığını gördüm. Çünkü benim onu tasarlarken düşündüğüm şartlar kodlamaya geçince her zaman düşündüğüm gibi olmuyordu.

Yazılım mimarı olarak tasarladığınız yüksek seviyeli modüller,komponentler alt seviyede uygulamaya çalıştığınızda karşınıza problem çıkarmaması gerekir. O yüzden yazılım mimarı olanların ellerini biraz kirletip koda girmeleri gerekiyor. Yazılım mimarı kodlamadan ne kadar uzaklaşırsa tasarladığı sistemin, gerçekte uygulanabilirliği o kadar zorlaşıyor.Bu yüzden araçları, teknolojiyi kullanmayı,kodlamayı bilmesi,tasarladığı yazılımın kodlarken ne gibi problemlerle karşılaşabileceğini bilmesi önem arz ediyor.

Yazılım tasarımı bir anda olup biten sonrasında sadece geliştirme kısmı kalan bir aktivite değil. Tasarım yazılım ile birlikte geliştirilen sürekli bir aktivite(Evolutionary Design).Yazılım tasarımınızında sürekli iyileştirilmesi ve geliştirilmesi gerekiyor yoksa belirli bir süre sonra yazılımınız güncel ihtiyaçları karşılayamayacak hale gelebiliyor.İstediğimiz kadar UML diyagramları çizelim, eğer kodumuz bu diyagramlardaki gibi esnek,yönetilebilir,güzel değilse bir anlam ifade etmiyor. Source Code Is Design yani
Geliştirdiğiniz yazılımın tasarımının göstergesi UML diyagramları değil kodlardır.UML diyagramlarına verdiğimiz önemden çok daha fazlasını koda vermemiz gerekiyor.Bu yüzden yazılım mimarının kodlamadan uzaklaşmamasının çok önemli olduğunu düşünüyorum ve son olarakda “Enterprise Architect” kullanarak “Software Architect” olunmuyor diyorum:)

ALT.NET grubunu ilk kurulduğu günden bu yana takip ediyorum. Geçen sene Java Developer olduğum sıralarda ALT.NET Fırtınası yazımda bunu belirtmiştim. Ve ALT.NET felsefesinden Java Developer olduğum zamanlarda da, şuanda da oldukça fazla yararlandım. Türkiyede ALT.NET tarzı bir felsefenin,topluluğun yokluğundan yakınırken ALT.NET grubundan tanıdığım Tuna , Sidar ve Doğa önayak olup Türkiye ALT.NET grubunu kurmada, yapılandırmada öncülük ettiler.Grupta gerçekten ellerinden gelenin en iyisini yapmaya çalışan,yetenekli,bilgili birsürü arkadaş var.

Kuran ve öncülük eden arkadaşların hepsine teşekkürü ediyorum. Türkiye’de yazılım sektörünün bu tarz gruplara gerçekten çok ihtiyacı var. Bu yüzden Java,Ruby, .NET.. hangi teknolojileri kullanırsanız kullanın bu topluluktan faydalanacığınızı umuyorum. Herkesin desteklemesi gereken bir grup.Teknoloji bağımsız daha iyi kod yazmayı,sürekli öğrenmeyi isteyen bütün yazılımcı arkadaşları davet ediyorum.

Birkaç gün önce Süreçler mi?, insanlar mı? adında bir yazı yazmıştım. Martin Fowler blogumu takip ettiğinden olsa gerek birkaç gün sonra dediklerimi tastikler bir şekilde  FlaccidScrum yazısını yazmış:) Yazıda Scrum metolojisinin uygulanırken karşılaşılan zorluklardan ve sebeplerinden bahsediyordu. Son iki paragrı aşağıya kopyalıyorum.

I always like to point out that it isn’t methodologies that succeed or fail, it’s teams that succeed or fail. Taking on a process can help a team raise it’s game, but in the end it’s the team that matters and carries the responsibility to do what works for them. I’m sure that the many Flaccid Scrum projects being run will harm Scrum’s reputation, and probably the broader agile reputation as well. But since I see SemanticDiffusion as an inevitability I’m not unduly alarmed. Teams that fail will probably fail whatever methodology they mis-apply, teams that succeed will build their practices on good ideas and the scrum community’s role is to spread these good ideas around widely.

Many people are looking to Lean as the Next Big Agile Thing. But the more popular lean becomes the more it will run into the same kind of issues as Scrum is facing now. That doesn’t make Lean (or Scrum) worthless, it just reminds us Individuals and Interactions are more valuable than Processes and Tools.

Şaka bir yana Fowler’da paragrafta benim de daha önceden vurguladığım konuların üzerinde durmuş. İşaretlediğim yerlerde bizlere başarının yada başarısızlığın süreçlerden değil insanlardan kaynaklandığını, herhangi bir sürecin bir takıma uygulandığında onu başarıya ulaştıracak olanın takım tarafından alınan sorumlulukla mümkün olduğunu belirtmiş. Asıl başarının insanlardan kaynaklandığını birçok teknik, araç ve metodolojinin öncüsü olan Martin Fowler tarafından tekrar belirtilmesi beni sevindirdi. Sizinlede paylaşmak istedim.