Kitap – Head First Design Patterns

21 Ağu
Head First Design Patterns
Head First Design Patterns

Kitaplar serisine ait bu yazıda Hear First Design Patterns isimli kitabı incelemeye çalışacağız. Kitabın yazarları Eric Freeman ve Elisabeth Freeman‘dır. O’REILLY yayınlarından çıkmıştır. Amazon üzerinden bu kitaba ulaşabilirsiniz.

Kitap 638 sayfa olup dili İngilizcedir. İngilizce seviyesi ortanın üstünde olmayanlara bu kitabı önermem.

Head First Design Patterns tasarım şablonlarını nesneye yönelik programlama teknikleri ile harmanlayarak işlemiştir. Anlatımı gayet akıcıdır ve anlaşılması kolaydır. Konuları düz metin ağırlıklı değil, resimlerle ve şekillerle güçlendirerek görsellik üzerinde anlatımını yoğunlaştırmıştır. Bu sayede konuların kolay anlaşılması sağlanmıştır.

Bu kitabı okurken Java bilgisine sahip olmanız gerekir. Örnekler Java programlama dili ile geliştirilmiştir. Ancak C# programlama dilini bilenlerin de okuyabileceği bir kitaptır. Java veya C# dillerinde uzmanlaşmış olmanıza gerek yoktur, nesneye yönelimli programlama tekniklerini bilmeniz yeterlidir.

Kitabı okurken hiç sıkılmadım. Örnekler gayet sade ve anlaşılır geldi bana. Tasarım şablonlarını öğrenmek ve uygulamak isteyenlere kesinlikle öneririm. Tabi ki bu kitap sihirli bir değnek değil. Okuyan herkes tasarım şablonlarının en iyi uygulayıcısı olacak diye bir kaide koymuyorum. Kitaptan aldıklarını kendi problemlerinize uygulamak size kalmış. Umarım faydalı olur. Tekrar görüşmek dileğiyle.

TDD Sizi Yavaşlatmaz

19 Ağu

TDD(Test Driven Development) yaklaşımı için ortaya atılan eleştirilerden biri kod geliştirmeyi yavaşlattığı yönündedir.  TDD yaklaşımı, yöntem olarak şelale(waterfal) tarzı yaklaşımdan çok farklıdır. Dolayısıyla şelale tarzı geliştirmeyi bırakmak demek eski alışkanlıklardan vazgeçmek demektir. Ben TDD yaklaşımını ilk uygulamaya başladığımda, kendimi sanki sağ ayakla futbol oynarken sol ayakla oynamaya alıştıran oyuncu gibi hissetim. Çünkü alışkanlığımın tersi bir durum söz konusuydu. Önce kodu yazıp sonra test etmeye alışmışken, önce testin yazılıp sonra kodun üretildiği bir ortamda buldum kendimi.

Eski yöntemde yazdığım kodu test etmek için kullanıcı arayüzü (form, console) hazırlamam gerekirdi. Bu da hayli bir zaman kaybı demekti. Test edilecek sınıfa ait üyeleri test etmek için kullanıcı arayüz hazırlamak zahmetli ve uzun süren bir işlemdir. Test arayüzünü hazırladıktan sonra, ilgili forma kritik test parametrelerini elle tekrar tekrar girip denemek gerekir. Örneğin matematiksel bir fonksiyonu hesaplayan bir metodu test etmek için önce parametrenin sıfırdan küçük, sonra sıfır, sonra sıfırdan büyük olması durumunu sürekli test etmek gerekebilir. Metodun özellikleri arttıkça test sayısı da artar. Arada bir hata alırız ve hatayı düzelttikten sonra testleri tekrar yapmamız gerekir. Test senaryoları arttıkça, elle yapılan işlem sayısı da doğru orantılı olarak artar.

Testlerin elle yapılmasının gereksiz yere zaman harcadığını fark eden yazılımcılar, test sürecinin otomatik işletilmesi gerektiğine karar vermiştir. Tek bir tuşa basarak yazılımın bütün testlerini çalıştırıp kısa bir süre içinde geliştiriciye sonucu veren araçlar geliştirilmiştir. Bu araçlar sayesinde testler hızlı bir şekilde yapılmaktadır.

TDD yaklaşımı testlerin otomatik bir şekilde çalıştırılması anlamına gelmez. Çalışan koddan önce testin yazılması anlamına gelir. Test öncelikli(Test First) yaklaşım olarak da adlandırılır. TDD yaklaşımında kodu yazan kişi, kodunu kullanıcı gözü ile görerek geliştirmeye çalışır. Bu yazdığım API veya Framework’ün kullanıcısı olsam nasıl bir sınıf ve metod yazardım diye düşündürür geliştiriciyi. Bu geliştiriciyi yavaşlatmaz. Kodlama yapan kişinin koduna olan güvenini arttırır. Kişi geliştirdiği koda hükmetmeyi öğrenir. Testler başarıyla gerçekleştiğinde kişi güvenilir bir kod ürettiğini bilir.

TDD yaklaşımında uzmanlar hızdan ziyade kaliteli ürün geliştirmenin önemli olduğuna vurgu yapmaktadır. Yani müşteri sizin hangi yöntemlerle geliştirme yaptığınıza değil ortada düzgün çalışan bir uygulamanızın olup olmadığına bakar. Puanınızı buna göre alırsınız. Kötü uygulamalar demek hata oranı yüksek, kullanımı zor ve zaman kaybettiren uygulamalar demektir. Kötü uygulamaların üzerine yeni özelliklerin eklenmesi veya mevcut özelliklerinin değiştirilmesi zordur. Test edilmeden hızlı bir şekilde geliştirip teslim edilen uygulamaların bakımı ve ilerletilmesi sonraki aşamalarda zaman kaybettirici olacaktır. Değişimin zamanında yapılamaması da müşteri memnuniyetini önemli ölçüde azaltacaktır. Hiçbir müşteri binlerce satır boş koda para harcamak istemez. Binlerce satır kod yazmış olmak kişiyi iyi bir geliştirici yapmaz. (Ancak bazı kariyer ilanlarında aranan programcı kriterleri arasında “10000 bin satır kod yazmış olmak” şeklinde komik maddelere rastlarız)

TDD ile geliştirme yaparken çalıştırdığınız testlerin sonucunu almak çok uzun sürüyorsa bu durum, kodunuzu direkt olarak bir veritabanına veya bir dosya sistemine veya bir ağa bağımlı olmasından kaynaklanıyordur. Testlerin hızlı çalışması açısından kodların bu tür ortamlardan izole edilmesine dikkat edilmelidir. Test ortamında bu şekilde hız kazanmak mümkündür. Gerçek veritabanı ile dakikalarca sürecek testleri izole edilmiş ortamlarda saniyeler içinde gerçekleştirmek mümkündür.

TDD yaklaşımı genel olarak uygulamanın geliştirme sırasında ve ömrü boyunca devamlılığının sağlanabilmesi açısından size hız katar. Bir  çok firmanın sonraki versiyonlarını çıkaramadığı için çöpe giden uygulamaları vardır. Bir kurumda çalışan bir tanıdığımın anısıyla sözümü bitirmek istiyorum. Kurumuna yazılım yapan firmadan, mevcut yazılıma yeni bir özellik eklemesini istemiş. Firmanın verdiği cevap ise şu olmuş:  “Sen şimdi bir binanın aradaki bir katını kır ve araya bir kat ekle diyorsun, bu çok zor”.

Blog sayfam 2 yaşında

19 Ağu

19.08.2011 tarihinde web dünyasına açtığım blog sayfam artık 2 yaşında. 2 yıl önce kişisel bilgisayarımda metin dosyalarında biriken notlarıma her yerden ulaşabilmek ve onları unuttuğumda hatırlayabilmek için açtığım bir sayfadır blog sayfam. Zamanla gelen olumlu yorumlar bana yazılar yazmanın insanlara da faydalı bir aktivite olduğunu öğretmiş oldu. Bunun mutluluğunu da burada ayrıca paylaşmak istedim. Okuyuculardan gelen bir teşekkür bile içimde yeni yazılar yazma isteği uyandırıyor. İkinci yılı geride bıraktığım bu günlerde tüm okuyucularıma da teşekkürlerimi sunuyorum.

Programcılıkta isimlendirmenin önemi

7 Ağu

Bu blog yazıma konu olarak programcılıkta isimlendirmenin önemini seçtim ancak mesele aslında bir kitap yazdıracak kadar mühimdir. Hatta bu konuyu kitaplarına konu almış programcılar da mevcuttur.

Bilgisayar bilimine yıllarını vermiş kişilerden bu konunun aslında zorlayıcı bile olduğunu duyunca insan bir kez daha durup düşünüyor. Phil Karlton şu sözlerle isimlendirmenin zorluğundan bahsetmiştir: “There are only two hard things in Computer Science: cache invalidation and naming things”. Yani bilgisayar biliminde en zor iki şeyden biri isimlendirmelerdir.

Bilgisayar bilimine programlama branşı açısından baktığımızda mimari tarafında, kodlama sırasında ve veri tabanlarında yapılan isimlendirmeler, bir sistemin anlaşılabilir olması açısından çok önemlidir. Anlaşılabilirliğin sağlanması için programcılar olarak niyetimizi ortaya koyan isimlendirmeler yapmalıyız. Doğru isimler bulmak, iş modeline göre veya sistemin büyüklüğüne göre zorlaşabilir. Yazılım ve mimari genişledikçe verilen isimler birbirine benzemeye başlayabilir. Benzerliklerin artması ise kafa karışıklığına yol açar.

Doğru isimleri bulduğumuzda ise dikkat etmemiz gereken bir diğer husus, okunabilirlik kurallarına uymaktır. Yani yazdığımız isimler okunuş açısından gözü rahatsız etmemeli ve kısaltmalardan arındırılmış olmalıdır.

Oluşturulan sistemin her elemanına verilen isim özenle seçilmelidir. Sistemin elemanı bir mimari katman olabileceği gibi bir sınıfa ait bir üye de olabilir, bir veritabanı tablosu da olabilir.

Kendi tecrübelerim adına söyleyeyim, kodlama sırasında sınıflara veya sınıf üyelerine verdiğim isimler kafamda oturuncaya kadar onları birçok kez yazıp değiştirdiğim olur. İsmiyle özdeşleşmeyen nesnelere kafayı takarım desem hiç yanlış olmaz. Bu alışkanlığa nereden kapıldığımı da söyleyeyim, ta ki programlamada isimlendirme teamüllerini (Naming Conventions) okudum ve uygulamaya başladım, bu alışkanlık o gün bugündür benimle beraberdir. Aslında bu şikayet ettiğim değil sevindiğim bir durumdur. Alışkanlıklarım kodlama ile başladı, proje isimleri ile devam etti, veritabanı tablo isimleri derken dosya isimlerini bile özenle seçer hale geldim.

Programcılıkta isimlendirme meselesine gerçekten dikkat edilmesi gerekir. Çünkü isimlendirme, programcılıkta artık bir standart halini almıştır. İşin üstatları olarak bilinen birçok programcı buna dikkat ediyor. Önder yazılım firmaları ve programcıların oluşturduğu açık kaynak(open source) kodları açıp incelediğimizde bunu rahatlıkla görebiliriz. Amacının dışında bir isimlendirmenin olmadığını hemen fark edebiliriz. Düzenli ve sistemli bir çalışmanın isimlendirmelere de yansıdığını hemen anlayabiliriz. Yani isimlendirme kuralları düzenli, okunabilir ve anlaşılabilir sistemler için bir standart olmuştur.

Eğer standartlara uygun bir Framework, API v.s yazmak istiyorsak dikkat edeceğimiz noktalardan biri isimlendirmelerdir.

İlham kaynağım:
MSND Naming Conventions
Clean Code