Monthly Archives: October 2008

Composition Over Inheritance (Kalıtım yerine Birleşim)

Uzun zamandır işlerin yoğunluğundan dolayı yazamıyordum ama telafisi olarak düşündüğüm Object Oriented programlama açısından hayati konulara değinerek kendimi affettireceğimi umuyorum :)

Şimdi neden önemlidir ondan biraz bahsedelim. Öncelikle Object Oriented programlama dillerinde kodun tekrar kullanımını(code reuse) iki şekilde sağlayabilirsiniz. Birincisi inheritance(kalıtım) ikincisi ise Composition(güzel bir türkçe isim bulana kadar “birleşim” :) ) yöntemidir. Şimdi bu iki kullanımın neler olduğuna bakalım. Önce UML sınıf diyagramı olarak aralarındaki farka bakalım.
Devamını Burudan Okuyabilirsiniz

CSS ve Separation Of Concerns

Yazılım geliştirmede bütün programlama felsefelerine,bütün dillere,bütün metodolijilere uyan bir kavram varsa o da muhtemelen Separation Of Concerns kavramıdır. Türkçeye çevirebilmek için düzgün bir isim bulamadım fakat anlamı yazılımda farklı kavramların,işlerin birbirinden ayrılmasıdır. Geliştirdiğiniz ortam ister object oriented, ister prosedürel olsun ister static bir dil ister dinamik bir dil kullanın uygulamada birbiri ile alakalı olmayan işlerin, kavramların birbirinden ayrılması uygulamanız için her zaman faydalı olacaktır.

Peki nedir bu kavramlar? En basitinden herkesin bildiği tekerlemelerden olan Presenration Layer,Businesss Layer, Data Access layer gibi ayrımlar aslında Separation Of Concerns’ü uygulamaktan başka birşey değildir. Bu şekilde birbiri ile alakalı olmayan modüllerin,sınıfların farklı şekillerde birbirinden ayrılması uygulamanın esnekliği,yönetimi açısından oldukça faydalı olacaktır.Geliştirdiğiniz ortam ne olursa olsun fark etmeyecektir. Mesela C ile geliştirdiğiniz bir programda da Grafik çizim işlerini yapan sınıfları ayrı bir modülde toplayıp uygulamanın diğer kısmından ayırmak isteyeceksiniz ortam object oriented olmasa da burada yaptığınız şey uygulamanın farklı alanlarını birbirinden ayırmak yani Separation of Concerns. Bu yüzden bu ayrımı ne kadar iyi yapabilirseniz uygulamanız için o kadar iyi olacaktır.Tabi bunu yapmak o kadar basit olmayacak burada anlattığımız Patterns,Practices,Refactoring,TDD bu ayrımı sağlamak ve daha kolay yönetilebilir,esnek,kaliteli yazılımlar geliştirmek için kullanılan teknikler.

Separation of Concerns kavramına verilebilecek en güzel örneklerden birinin herzaman CSS ve HTML olduğunu düşünmüştürüm. İşyerimde bu aralar kısa bir CSS eğitimi vereceğim için bu konuda yazmak istediklerimi her zamanki gibi klasik uygulama kodlarının dışına çıkarak CSS ve HTML ile göstermek istedim. CSS ve HTML ve Web standartlarının hayranı olduğumu söylememe gerek yok sanırım. Sebebini söylemeden sizin anladığınızı umuyorum.Her zamanki gibi daha kolay ve yönetilebilir yazılım elde etmek. Konuyu fazla uzatmadan Separation of Concerns örneğimize geçmeyi istiyorum. Aşağıda klasik mantıkla geliştirilmiş bir ASP.NET sayfası var

Devamını Burdan Okuyabilirsiniz

Değişim Açlığı , IBM Yazılım Zirvesi 2008

Bugün IBM 2008 Yazılım zirvesindeydim. Aslında bu tarz zirveler genelde ürün tanıtımı ve şov olarak geçtiği için pek hoşlanmam. Fakat bu zirvede ilgimi birşey çekti o da zirvenin ana sloganıydı.Slogan Değişim Açlığı olarak belirlenmiş. İlk açılış konuşmasında da slaytlarda yazılım sektöründeki gidişatı göstermiş ve de değişime adapte olabilmenin artık bir seçenek değil zorunluluk olacağına değinilmiş. Geleceğin firmasının değişimi bir fırsat olarak görüp daha iyi işler çıkarıp müşteriyi daha memnun etmek için kullanması gerektiğini söylemiş.

Dikkatimi çeken başka bir konu ise açılış konuşmasında grafiklerde ve konuşmada “Ne kadar iyi teknolojiye sahip olursanız olun, bu teknolojisi kullanarak iyi işler ortaya çıkaracak olan insanlardır” kavramının yer almasıydı. Ve nitelikli ve istekli bireylere ihtiyacın gittikçe artan bir grafiğe sahip olduğunu şekiller ile gösteriyordu. Birçok tanıtımda da takım ve insan faktörünün projelerde ne kadar önemli olduğundan bahsedildi.Biz önceden beri diyoruz ama sakalımız yokki dinletelim :)

Bu kadar çok değişim ve insan faktörü üzerinde durulması beni neden ilgilendirdi ondan bahsedeyim. Öncelikle daha önce okuduğum Extreme Programming Explained: Embrace Change kitabı gözümün önüne geldi diyebilirim. Sizinde okumanızı öneririm Extreme Programming’in kurucularından Kent Beck oldukça güzel anlatmış. Kitabın başlığıda gördüğünüz gibi Değişimi Benimsemek  olarak konulmuş. Ayrıca Agile yöntemlerin temel felsefesi olan Individuals and interactions over processes and tools yani araçlar ve süreçler yerine bireyler ve iletişimin aslında konferansın ana konularından biri olmasıydı. Aslında IBM zirvesindeki temel konu Extreme Programming ve Agile yöntemler ile oldukça yakından alakalı. Çünkü Agile yöntemlerin temelinde kitabın başlığından da anlayabileceğiniz gibi değişimi benimsemek, ondan korkarak ya da kaçarak değilde onu müşteriyi daha memnun etmek için kullanılan bir araç olarak görmesi, efektif motive olan takımlardan oluşması ve projeyi asıl başarılı kılan faktörün bu olduğu var. Bu bakımdan IBM gibi genelde RUP tarzı ağır yazılım süreçlerinin daha ağır bastığı bir firmanın bu sloganı benimsemesi hoşuma gitti.

Konuşmanın diğer kısımlarında da IBM Jazz adlı ürününü tanıttı. Tabi konunun başlığından da gördüğünüz gibi şaşırmamak gerekli. Jazz ürün ailesi ile Agile yöntemlere uygun yazılım geliştirmenin nasıl kolaylaşacağından oldukça bahsedildi. Sonuçta zirveden benim çıkardığım artık Agile yöntemlerin gittikçe kabul gördüğü ve faydalarının ortaya çıktığı, IBM gibi büyük firmalar tarafından da kabul edilmiş durumda. Bu bakımdan Agile felsese belirli araçları kullanmak olmamasına rağmen en azından Türkiye’de firmaların “IBM gibi biri bunu tanıtıyorsa buna yatırım yapıyorsa bundan bir hikmet vardır” demesine vesile olabilir. Bu bakımdan sektörün Türkiye’de artık yavaş yavaş Agile tarzı yöntemler ile kaliteyi ve müşteri memnuniyetini arttırmasını ümit ediyorum.

Code Metrics : Cyclomatic Complexity

Kompleks kod hata oranı fazla, anlaşılması zor, değiştirmesi zor, test etmesi zor kısacası ençok problem içeren kod olduğu için bunu ölçebilmek ve buna göre önlem almak oldukça önemli. Kodun kalitesini ölçmekte kullanılan birçok metrik(ölçüm) bulunuyor. Bunların kodun kompleksliğini değerini ortaya çıkaran en önemli metriklerden biride Cyclomatic Complexity.  Kim, ne zaman, nasıl, kaç tarihinde bulmuş onları linkteki wiki sayfasından öğrenebilirsiniz.

Metriklerın yaptığı iş kodun belirli kriterlere göre değerlendirmesini yapıp size bazı değerler hakkında fikir vermesi. Mesela geliştirdiğiniz projede kaç satır kod,kaç satır yorum satırı var,sınıflarınız ortalama kaç metod,kaç değişken içeriyor,sınıfların birbirlerine bağımlılıkları nedir… gibi birçok metrik aslında kodunuzu çeşitli konulardaki değerlerini izlemenizi sağlıyor.

Bu bakımdan kodun kalitesini bu çeşit ölçümler ile izleyip, problemli alanları ortaya çıkarıp ardından bunlara göre önlem almak oldukça faydalı oluyor. Hatta bu tarz metrikleri eğer düzgün bir sürüm otomasyon sisteminiz varsa sürüm çıkarma işlemine bile ekleyebiliyorsunuz. Mesela 1000 satır ve daha fazla kod içeren sınıf varsa bu sürümü çıkarma gibi. (Biraz saçma oldu ama idare edin :) ). Şimdi metriklerin neden önemli olduğu konusunda anlaştık sanırım. Anlaşmadıysakta örnekten sonra anlaşacağımızı umuyorum :)

Cyclomatic complexity metriği nedir onu açıklayalım : Cyclomatic complexity kodun ne kadar kompleks olduğu hakkında fikir veren en önemli ölçümlerden biridir. Bunu yapmak için kodun içerisindeki if,else, while, switch,for gibi yapıların sayısını kullanır.Bu değerin projemize nasıl yansıyacağını aşağıdaki tablodan yorumlayabilirsiniz.Bir metodun Cyclomatic complexity değerine göre taşıdığı risk aşağıdaki tabloda bulunuyor.

Cyclomatic Complexity Risk
1 – 10 Basit ,risk az
11 – 20 daha komplex,orta derece riskli
21 – 50 kompleks,yüksek derece riskli
> 50 test edilemeyen,çok yüksek riskli( silin daha iyi :) )

Matematiği sevenler için Wikipedia formülleri oldukça güzel anlatmış. Eğer formüllerle fazla uğraşmak istemiyorsanız Cyclomatic complexity daha basit olarak şu şekilde hesaplanıyor. Mesela aşağıdaki gibi bir metodumuz var diyelim.

Devamını Burdan Okuyabilirsiniz

.NET Reflector

Şimdi aslında bu yazıyı hazırlamamın amacı bir sonraki yazımda .NET için bunu kullanarak bazı şeyler anlatacak olmam. O yüzden sonraki konuyu fazla uzatmamak ve Reflector aracının diğer amaçlarla da kullanılması faydalı olabileceği için böyle bir yazı yazmaya karar verdim.

Öncelikle şunu belirteyim yazılım geliştirirken bu tarz araçlar kullanmak oldukça faydalı oluyor. Daha önceden Java kullandığımda da bu tarz araçların yardımına oldukça başvuruyordum. .NET’e geçince de tabi ilk işim bu tarz araçlar aramak oldu ve oldukça güzel bir araç olan Reflector‘e rastladım. Fazla uzatmadan kuruluma geçelim ve ardından bize ne gibi faydalar sağlıyor ona bakalım.

Devamını Burdan Okuyabilirsiniz

Refactoring : Extract Method

Örnekleri buradan indirebilirsiniz.Örnekleri Java kullanarak yaptım. Mantık herhangi bir dilde aynı olduğu için problem olacağını düşünmüyorum. IDE olarak Netbeans 6.1 kullandım.

En çok kullandığım refactoring yöntemi kesinlikle Extract Method. En çok kullandığım tekniklerden bahsetmek neden sonlara kalıyor hala bende çözebilmiş değilim :) Hemen örneğe geçelim ve aşağıdaki gibi bir metoda bu tekniği uygulayalım.Öncelikle şunu belirteyim normal şartlarda Refactoring yapmadan önce mutlaka testlerin olmasına dikkat ederim.Eğer yoksa değiştireceğim metod için test yazıp ardından Refactoring işlemini yaparım. Fakat burada sadece Extract Method nedir onu anlamanız için yazıyı fazla uzatmak istemiyorum. Siz aşağıdaki metodların testlerinin olduğunu düşünün ve gerçek projelerde testler ile refactoring yapmaya çalışın. Nasıl refactoring yapmalıyız başka bir yazıda bu konuya değineceğim.

Devamını Burdan Okuyabilirsiniz