Monthly Archives: August 2007

Test Driven Development Araştırması

Geçenlerde IEEE software dergisinin 2007 haziran ayına ait ücretsiz olarak sunduğu TDD–The Art of Fearless Programming yazısınını okumuştum. Yazıda genel olarak TDD hakkında bilgi veriyordu asıl ilgimi çekense yazılım geliştirme yöntemi olarak Test Driven Development uygulayan şirketlerin projelerindeki toplam kalite oranı üzerindeki etkisi, üretkenlik değerlerini tablo olarak yayınlamış.

Yukarıdaki tabloda da gördüğünüz gibi TDD kullanılan projelerin üretkenliğinde ve ürün kalitesindeki artış oldukça dikkat çekici.

tddarastirma2.jpg

Tabi bu kalite ve üretkenlik artışını tablodan görünce hikaye gibi gelebilir en güzel anlama yolu kendinizin denemesi. Kendi deneyimlerimden de aynı sonucu almıştım ve oldukça etkilenmiştim.  Bu arada denemeden önce kullanım klavuzununda bulaşıcıdır yazıyor dikkatli olun. Bir kere etkiledimi eski kod geliştirme tekniklerinize asla dönemezsiniz. Banada bulaştı işte o gün bugün TDD ile yatar kalkar oldum :)

Unutma Ey İyi Yazılım Mühendisi Adayı!

“You don’t have to be

great to get started, but you have to get started to be great.”

Les Brown

Das Experiment

Uzun zamandır film arşivimde bulunan fakat bir türlü izlemeye fırsat bulamadığım Das Experiment (Deney) filmini sonunda izleyebildim. Yaklaşık 5 dakika önce bitirdiğim film hakkında hemen kısaca birşeyler yazayım dedim. Oyuncular arasında tanıdığım daha önce Im Juli (Temmuzda ) filminde oynayan Moritz Bleibtreu vardı. Oyunculuğunu bu filmdede çok beğendim açıkçası. Özetlersek film bir 4000 mark karşılığında başvuranların 14 gün boyunca katılacağı bir deneyi anlatıyor. Deneklerden bir kısmı gardiyan diğer kısmı mahkum olarak hapishaneye yerleştiriliyorlar. Ardından deney havasından çıkıp gardiyan rolündeki arkadaşların buranın ağası biziz moduna girmesi. 77 numaralı Moritz Bleibtreu‘ın da Tatar Ramazan olarak özünü bulmasıyla ortalık iyice karışıyor. Filmi izlerken gerçekten gerildiğimi hissettim. Hele sona doğru mahkumlar kaçarken gardiyanlar sanki beni kovalıyordu:) Filmi herkese tavsiye ederim. İnsan psikolojisi üzerine gerilim tarzında güzel bir film.

Taşındık!

vet uzun süredir düşündüğüm

kendi adıma ait bir siteye taşınma işlemini başarmış bulunuyorum. Tembellikten ne zamandır aklımda olan ama bir türlü gerçekleştiremediğim bu taşınma işine birazda wordpress.com’ın yasaklanması ön ayak oldu diyebilirim. Lafı fazla uzatmadan kurdaleyi keseyim… Hayırlı olsun.

Practices of an Agile Developer Working in The Real World

pad Bu aralar yolda gidip gelirken Practices of an Agile Developer Working in The Real World kitabını okuyorum. Oldukça eğlenceli ve bir o kadar yararlı bir kitap. Bir yazılımcı için Agile development felsefesi genel olarak anlatıyor. Kitap kısa ve öz yaklaşık 200 sayfa civarı ve anlatılan konular genel olarak yazılım geliştirme sürecinde kodlamadan müşteri ilişkilerine ,takım içi iletişimden, günlük yapılan birçok işleme kadar oldukça pratik bilgiler anlatıyor. En çok hoşuma giden tarafıda şeytan-melek diyalogları örnek olarak şöyle bir diyalog vardı;

Şeytan : Kodu gerçekten anlamana gerek yok zaten çalışıyora benziyor. Sadece küçük bir takla attırılmaya ihtiyacı var. Bir iki satır kod ekle muhtemelen çalışacaktır

Melek : Kodun temiz sade anlaşılabilir tutmak için uğraş.

Gerçekten içimizdeki şeytanın sesine kulak vermişler. :)

 

Programın içinde bütün bölümlerde bu

tarz şeytanın vesveselerine karşı gerçekten yapmamız gereken meleğin tavsiyeleri yer alıyor. Kitabı oldukça eğlenceli buldum herkese tavsiye ediyorum.

Son olarakta şeytana uymayalım uyanları uyaralım diyorum :)

Yazılım Performans Optimizasyonu

“The First Rule of Program Optimization: Don’t do it.
The Second Rule of Program Optimization (for experts only!) : Don’t do it yet.”

Michael A. Jackson

Benim fikrimi büyük ölçüde ifade eden  kod optimizasyonu hakkında en çok hoşuma giden sözlerden biri.  Optimizasyon derken programı daha hızlı,performanslı çalıştırmak için yapılanlar kast ediliyor genelde. Gerçekten yazılımı kompleksleştirme açısından üzerimize yok ayrıca bu kompleksliğin dışında birde yazılımı geliştirirken ilk olarak performansı düşünüp iyice kodu karmaşıklaştırdığımız zaman kod içinden çıkılmaz bir hal alıyor ve ardından performans bu tarz değişiklikleri kolaylıkla yapamadığımız için yerlerde sürünüyor.

Bugünlerde üzerinde çalıştığım modülde eski bir kod üzerinde refactoring yapıyorum. Eski kod ilk yazıldığında kod esnekliği, okunabilirlik, test, tasarım yerine ağır olarak performans kaygıları gözetilerek yazılmış. Aşırı olarak Thread kullanılıyor. Yani aklınıza gelebilecek her işlem bir sınıfda ve bu sınıfların hepsi Thread sınıfından türemiş. Tabi kod kalitesi açısından kötü olduğu için performans iyileştirmesi yapılabilecek birçok yeri göremiyorsunuz. Özellikle herşeyin Thread olması avantaj gibi gözüksede aşırı Thread kullanımu CPU için ciddi performans düşüşüne yol açıyor.

Bu kod için yavaş yavaş unit testleri hazırlayıp refactoring yapınca birçok performans açısından büyük kazanç sağlayacak şey ortaya çıktı, Thread kullanımı oldukça azaldı, birçok gereksiz nesneden ,alandan kurtuldu  ve birçoğu daha çıkacağa benziyor.

Performans optimizasyonu çoğu zaman kodu karmaşıklaştırır. Yukarıdaki gibi performans için yazılımın ilk başında bu tür kaygılara düşerek kodu karmaşıklaştırmak benim yaşadığım gibi sizin için yönetilmesi zor oldukça karmaşık bir yazılım ortaya çıkaracaktır. Bu yüzden öncelikli hedefin okunabilir ,test edilmiş,esnek bir yazılım geliştirmek olması gerekir ardından çalışan yazılım performans problemi yaşıyorsa bu tarz optimizasyonları yapmak çok daha kolay ve verimli olacaktır.

Daha mutlu, rahat, zevkli,hızlı,kaliteli, performanslı, yazılımlar için daha önceden tekrarladığımız gibi hep bir ağızdan tekrarlıyoruz.

"Clean Code that Works".

WordPress.com yassah hemşerim…

Şuanda wordpress.com yasaklı farklı bir DNS adresinden girip bu yazıyı yazıyorum ne acı. Dün eve gelip hevesli hevesli blogda yazı yazmak için siteyi açtığımda birde karşıma ne çıksın "Bu siteye erişim mahkeme kararıyla engellenmiştir." . Devamında da Fatih adliyesi kararıyla vs vs.. yazıyordu. Birden töbe töbe dedim ne sitesi ne mahkemesi kısa süreli şoku atlattıktan sonra diğer sitelere bakında genel yasaklama olduğunu gördüm. Yani bu ne mantıktır bir türlü anlamadım eğer bloglardan birinde yanlış birşey yazılıysa gider bildirirsin wordpress.com”a ardından gerekli işlemler yapılır o blog yayından kalkar ama telekomdaki abilerimiz kökten çözüm bulmuşlar hepsini yasaklamıştır. Bu kararın ardında kim varsa kınıyorum. Zaten tembellikten ayda yıldar bir yazı yazıyordum dün o hevesli anlarımdan birindeyken de sağolsun telekom hevesimi kaçırdı bir daha bekleki ilham gelsinde yazı yazalım.:)

Yazılım Mühendisliği Rehberi-(P)Object Oriented

Nasıl daha iyi yazılım mühendisi olabiliriz diye daha önceden birkaç şey karalamıştık hatırlarsanız. Bu seferde birkaç satır Object Oriented dünyasına ait birşeyler karalayalım. Object Oriented yani türkçeye çevirmeye çalışırsak Nesneye Yönelik yazılım felsefesi hakkında birkaç şeyde biz söyleyelim. Object Oriented Programming, Object Oriented Design, Object Oriented Analysis hepsine yazının bundan sonraki kısmında Object Oriented diyeceğim.

Bugünlerde Object Oriented denince nedense aklıma eski bi Ruffles reklamı vardı o geliyor. Reklamda spiker taraftarın birine mikrofonu uzatıyortı birşey soruyordu yanılmıyorsam ardından geçen konuşmadan sonra öldürücü slogan geliyordu : "Ruffles Her maça gidiyor , her maçta yeniyor" diyordu. Nereden Object Oriented ile bağdaştırdığımı sorarsanız size hak vererecek şöyle açıklamaya çalışayım. Günümüzdeki modern yazılım dünyasında, modern object oriented programlama dilleri, modern geliştirme ortamları, modern framework’lere sahibiz. Bunları kullananlardan herhangi birine sorduğunuzda size muhtemelen Object Oriented yazılım geliştirdiğini söyleyecektir. Bunların gelişiminde Object oriented felsefenin etkisi çok büyük fakat bunları kullanarak gerçekten Object Oriented yazılım geliştirmiş oluyormuyuz? Cevap acı ama gerçek malesef olmuyoruz. Hatta daha da acısı büyük bir çoğunluğumuz Object Oriented olarak yazılım geliştirdiğimizi düşünüyoruz fakat eski prosedürel mantıktaki programlanın biraz bozuk şekilde evrimleşmiş şekli olan Prosedürel Object Oriented diye yorumladığım PObject Oriented yazılım geliştiriyoruz.

Kendimden örnek vereyim ilk önce. Okul yıllarında Java’da ya da C# , C++ gibi dillerde programlama yaparken dil Object Oriented diye benim yaptığım programlarında Object Oriented olduğunu düşünürdüm. İşin kötüsü tabi bunu sonradan yanlış olduğunu anlamak oldu. Tabi ilk başta insanın aklına "E ben java’da program yazmıyormuyum? Yazıyorum.. E java’da herşey nesne değil mi? Nesne.. E o zaman ben Object Oriented yazılım geliştirmiş olmuyormuyum?" diye bir soru geliyor. Bu soruya cevabımız "Malesef hayır, geliştirmiş olmuyorsunuz.". Muhtemelen Object Oriented olduğunu düşünerek Object tabanlı modern bir dilde geliştirdiğiniz programların çoğu PObject Oriented. Etrafta birkaç (on,yüz,bin) sınıf var, bu birkaç (on,yüz,bin)’lik sınıfların içindeki çoğu kod sadece birkaç onluk sınıfta toplanmış, o da yetmezmiş gibi bu sınıfların içindeki onlarca metod yüzlerce satırdan oluşuyor. Ayrıca şöyle bi yapıya göz gezdiriyorsunuz kimin eli kimin cebinde değil bütün sınıfların referansları bütün sınıflarda bulunuyor. Proje interface fakiri vb….Zaten niye interface diye bir kavramı bu programlama dillerine koymuşlar bir türlü anlamadım neymiş efendim C++’da çoklu kalıtım varmış modern programlama dillerinde de çoklu kalıtımın sorunlu yapısı yerine interface kavramı çıkarılmışşşşşşşş.. Sınıfları şöyle bir inceliyorsunuz bazıları metodlarını kabadayı binlerce satırlık sınıflara kaptırmış. Bu sınıflarda property ya da getter/setter ‘dan başka birşey yok. Aslında bu tarz sınıfları C’ deki struct ya da Pascal’daki Record yapısını kullanarakta çok güzel yapabilirdik. Bana sorarsanız o binlerce satırlık sınıflarıda prosedürel programlama ana sınıfta birkaç yüz satırlık uzun parametreli metodlarla yapabilirdik ne gerek vardı Java’ya, C#’a. Birde object oriented havası vermek için Köpek sınıfını Hayvan sınıfından türettikmi olay bitmişti. :)

Yukarıdaki bahsettiğim şeylerin hepsini Ali desideronun dediği gibi bizzat denedim çocuklara denettim. Valla hepside okumuş çocuklar bende dahil olmak üzere ama Object Oriented’ın böyle olmadığını birtürlü okulda ya da başka bir yerde okuyamamışız :)

Günümüz modern Yazılım dünyasında, Yazılım Mühendisliğinde gerçekten Object Oriented yazılım geliştirmenin önemi çok büyük fakat bunu ancak gerçek anlamda Object Oriented felsefeyi öğrendikten sonra anlıyorsunuz.Bunu bilmeden önce Pascalda C de aynı programı geliştirmişsiniz bir fark yaratmıyor gibi geliyor insana. Hatta ilk başlarda orda geliştirmek daha kolay bile gelebilir çünkü onlar saf kan Prosedürel Oriented, (P)Object Oriented değil. Ama Object Oriented dünyasına bir daldığınızda işlerin ne kadar temiz , düzenli, kolay yönetilebilir, kolay yeni özellik eklenebilir, esnek olarak geliştirildiğini görünce eski günlere geri dönmeyi pek istemiyorsunuz. Tabi unutmamak lazım amacımız Object Oriented hatrına böyle yazılım geliştirmek değil amaç gittikçe kompleksleşen yazılım projelerini daha ucuza daha kısa sürede daha yönetilebilir, yeni özellikleri kolayca eklenebilir yapıda geliştirmek bu yüzden Object Oriented sayıklayıp duruyoruz.

Object Oriented denince aslında ilk akla gelmesi gereken şey Data Hiding, Encapsulation kavramlarıdır. Ayrıca Polymorphism ve Overloading kavramlarıda bunlardan sonra oldukça önemlidir. Aslında bunlardan kısa kısa bahsetmektense uzun uzun makale hazırlamak istiyorum. Çünkü ilk başta bu kavramları yarım yamakak öğrendiğimde tamam Object Oriented felsefeyi kaptım demiştim ve hiçte önemsememiştim ama ilerledirkçe hiçde doğru anlamadığımı ve ne kadar önemli olduğunu anladım.

Object Oriented ile prosedürel programlama arasındaki en büyük farklardan birisi de Prosedürel programlamada veriler ve fonksiyonlar birbirinden ayrıdır.Yani dışarıda global veriler bulunur ve bu verileri işleyen fonksiyonlar bulunur. Object Oriented programlamada ise tam tersi veriler ve onlar üzerinde işlem yapan fonksiyonlar bir aradadır.Ayrıca Kısa bir tanımlama yaparsak Data Hiding (Bilgi Saklama) nesnelerin iç yapılarının yani sahip oldukları verilerin dışarıdan gizlenmesidir. Encapsulation ise bu dışarıdan saklanmış verilerin nesne üzerinde tanımlanmış fonksiyonlar ile dışarıya açılmasıdır. İlerleyen zamanlada daha detaylı bu konulara değiniriz…

Yukarıda olmaması gereken birçok özellik saydım bunlar sadece bazılarıydı. Eğer kodunuzda bu tarz şeyler görüyorsanız birkaç OO kitabı almanın biraz makale okumanın vakti gelmiş demektir. En azından benim için en faydalı olanda öyle sanarak yazdığım kodların Object Oriented olmadığını kısa sürede görebilmiş olmamdı. Ondan sonrası zaten kolaylıkla geliyor doğru olanın arayışı içine giriyorsunuz çünkü.

Kısaca yazılım mühendisi olanlara, adaylarına kodlarını tekrar gözden geçirmelerini gerçek anlamda Object Oriented yazılım geliştirip geliştirmediklerini sorgulamasını tavsiye ediyorum. En kısa zamanda Object Oriented felsefeyi kavramalarını şiddetle tavsiye ediyorum. Hatta aynı projede çalışsaydık muhtemelen şimdi arkadaşlara yaptığım gibi durmadan faydalarını anlatıp ikna etmeye çalışırdım olmadı dikte ederdim :)Gerçekten Object Oriented felsefenin yazılım mühendisliği alanının en önemli konularından biri olduğunu düşünüyorum . Diğer birçok yazılım mühendisliği konusu (Design Patterns, Refactoring, TDD vb..) aslında nasıl daha iyi Object Oriented yazılım geliştireceğimiz hakkındaki tekniklerdir.

Şimdi benimde en çok zorlandığım nasıl öğreneceğiz kısmına geldik . Öncelikle eğer şanslıysanız ve çevrenizde Object Oriented felsefeyi iyi bilen birileri varsa hemen yapışın hiç bırakmayın derim.Beraber yazılım geliştirin yazdığı kodu inceleyin sınıflara atadığı metodların neden oraya konduğuna dair sorular sorun vb… Dikkat edin tecrübeli demiyorum çünkü gözlemlediğim şöyle bir sonuç var Çalışma yılı = İyi yazılım mühendisi demek değildir. Bu kişilerden ne kadar bilgi alırsanız yazılım kariyeriniz için o kadar iyi olacaktır. Kitaplardan makalelerden günlerce okuyup bulamayacağınz bir bilgiyi yanınızdaki kişiden 5-10 dakika içerisinde öğrenebilirsiniz. Benimde seçtiğim ikinci seçenek kendi kendinize öğrenmekten geçiyor yani zor olan yol. Açıkçası bu şekilde öğrenmek yıllar alabiliyor. Sürekli konu hakkında kitap makale blog forum takip etmeniz gerekiyor. Takıldığınız yerlerde forumlardan yardım almak biraz zorlaşıyor dolayısıyla öğrenme süresi oldukça uzuyor. Yıllar oldu ben açıkçası hala OOP adına bilmediğim yeni şeyler öğreniyorum. Kitap olarakda daha önceden okuduğum en iyi Object Oriented başlangıç kitabı olarak tavsiye edebileceğim

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

aklınıza takılan sorular varsa ben burdayım. Object Oriented dünyasına giriş biletinizi kestik hadi hayırlı yolculuklar….

Yazmayı Planladığım Gelecek Konular

Eğer bir aksilik çıkmazsa inş. aşağıda vereceğim listedeki faydalı olacağını düşündüğüm konularda burada yazı yazmayı planlıyorum. Kafamda böyle bir liste uzun zamandır vardı fakat yoğunlukdan dolayı pek vakit bulamıyordum. Bu yüzden burada bir nevi yol haritamı gösterip bu planlarımın ne kadarını gerçekleştirip gerçekleştiremediğimi kontrol edeceğim. İşte türkçe kaynak sıkıntısı olduğunu gördüğüm Yazılım mühendisliği ile ilgilenenlere oldukça faydalı olacağını düşündüğüm yazacağım konular. Başlıklara uygun türkçe uydurmaya çalışmayacağım zaten çalışsamda düzgün bişey bulabileceğimi sanmıyorum o yüzden başlıkları direk ingilizce olarak yazacağım

Şuanda aklıma gelenler bunlar . Bu liste sürekli değişecek başlıklar değişip yeni konular eklenebilir. Umarım hepsi hakkında ufak tefekte olsa bişeyler yazmaya fırsat bulurum…

Refactoring – Introduce Parameter Object

Eski kodu yeniden düzenlemek gerçekten zahmetli bir iş. Birde bunu yaparken etrafta Unit Test yoksa vay halinize.Çünkü değiştirdiğiniz herhangi bir kod sonucunda programın çalışıp çalışmayacağından asla emin olamıyorsunuz. Eski kodu refactoring yaparken öncelikle yapmanız gereken eski kod için Unit Testlerin hazırlanması ardından da refactoring yapılması. Zaten Eski kodu refactoring yapmak başlı başına ayrı bir konu. Bu konuda en iyi kaynaklardan birinde Working Effectively with Legacy Code kitabı. Daha önceden de okunacaklar listesinde belirtmiştim gerçekten çok faydalı kitap.Kitapta şöyle bir tanımlama yapıyor Michael C. Feathers . Unit Test’i olmayan kod eski koddur. Bizimde önümüzdeki 5-10 sene genelde Testi yazılmamış eski kodlarla çalışacağımızı düşünürsek önemi dahada artıyor. Bu konuda uygulanacak tekniklerden vaktim oldukça bende bahsetmeye çalışacağım.

Neyse konuyu fazla uzatmadan örneğimize başlayalım.Şu sıralar çalıştığım projede daha önceden yazılmış eski kodu refactoring yapıyorum. Genelde kodda şu şekilde sınıflar ortalıkta geziyordu;



public class MessageProcessor {
    private Converter converter;   
    //.....
   
    public void process(byte[] data,String message,int messageID){
        if(data!=null && data.length>0 && message!=null && !message.equals("")){
            BaseMessage baseMesage =converter.convert(data,message,messageID);
            //...
        }       
    }
}


Yukarıdaki kodda belki ilk başta görmesi zor olabilir ama dikkar ederseniz process metodunun parametreleri olan ayrıca convert metodunada iletilen byte[] data,String message,int messageID göreceksiniz. MessageProcessor sınıfında gördüğünüz gibi bu parametrelere ait çeşitli kontroller yapılıyor. Yazmaya gerek duymadım ayrıca işlemler aslında Converter sınıfının convert metodunda da tekrarlanıyor. Birden fazla parametrenin çeşitli metodlara genelde beraber olarak geçildiğini gördüğünüzde ilk olarak yapmanız gereken bu parametreleri kendi sınıf alanı olarak kullanan yeni bir sınıf üretmektir işte bu sınıfa Parameter Object denir. Aşağıda kodun ve yeni oluşturduğumuz Parameter Object sınıfımızı görebilirsiniz.



public class MessageProcessor {
    private Converter converter;
    //.....

    public void process(Message message){
if(message.getData()!=null && message.getData().length>0 
&& message.getMessage()!=null && !message.getMessage).equals("")){
            //....
            BaseMessage baseMesage =converter.convert(message);
            //...
        }
    }
}

class Message {
    private byte[] data;
    private String message;
    private int messageID;
    public Message(byte[] data, String message, int messageID) {
        this.data = data;
        this.message = message;
        this.messageID = messageID;
    }
    public byte[] getData() {
        return data;
    }

    public String getMessage() {
        return message;
    }

    public int getMessageID() {
        return messageID;
    }
}


Gördüğünüz gibi bu parametreleri bir sınıfta topladık ve ardından onların yerine ihtiyaç duyan sınıflara bu yeni oluşturduğumuz Message parametresini gönderdik. Genellikle bu tarz bir Parameter Object oluşturduğumuzda daha önceden oluşturmadan önceki parametrelere ait yapılan kontroller işlemlerinde bu sınıfa taşınması daha doğru olacaktır. Yani ikinci aşamada kodumuzu bu şekilde değiştirebiliriz.



public class MessageProcessor {
    private Converter converter;
    //.....

    public void process(Message message){
        //.....
        if(message.isValid()){          
            BaseMessage baseMesage =converter.convert(message);
            //...
            //...
        }
    }

}

class Message {
    private byte[] data;
    private String message;
    private int messageID;
    public Message(byte[] data, String message, int messageID) {
        this.data = data;
        this.message = message;
        this.messageID = messageID;
    }
    public byte[] getData() {
        return data;
    }

    public String getMessage() {
        return message;
    }

    public int getMessageID() {
        return messageID;
    }

    public boolean isValid() {
        return getData()!=null && getData().length>0 
&& getMessage()!=null && !getMessage().equals("");
    }
}

Yukarıda gördüğünüz gibi Message sınıfımızda artık isValid adında bir metodumuz var aynı metodu diğer sınıflarda da kullanacağız. Hem kod tekrarını hemde okunulabilirliği oldukça arttırmış oldu.

Refactoring gerçekten yazılım geliştirmenin olmazsa olmazları arasında. Kodunuzu sürekli gözden geçirip bu tarz yapılar gördüğünüzde bu Refactoring tekniğini uygulamanızda oldukça fayda var aklınızda bulunsun.. …