Tasarımın Sonumu Geldi (2) - İsmail KIRBAŞ ile Web Sitesi Tasarımı
İsmail Kırbaş ile Tasarım Yolculuğu [AnaSayfa] İsmail Kırbaş ile Tasarım Yolculuğu [AnaSayfa] İsmail Kırbaş ile Tasarım Yolculuğu [AnaSayfa]
 Site Haritası 
 
Site Map
Ana SayfaYeriniz | Ana Sayfa | Makaleler | Proje Yönetimi | Tasarımın Sonumu Geldi (2)

Diğer Yazılar
Başarılı Projelerin Ortak Özellikleri
Tarihten Ders Almak
Proje Yönetimine Giriş
Yazılım Projelerinde Rol Dağılımı
Tasarımın Sonumu Geldi? (1)
Tasarımın Sonumu Geldi? (3)
Duvara Açılan Projeler
Toplam Kalite Yönetimi
Kriz Yönetimi 2
Kriz Yönetimi 1
İş Zekası
Risk Yönetimi Nedir?
Proje Yönetimi Nedir


E-posta Gönderin Yorum Yazın
Güvenlik Kodu:2029Güvenlik Kodu:2029Güvenlik Kodu:2029Güvenlik Kodu:2029




En Son Okunan 10 Makale
  1. E-Marka Olmada Aşamalar
  2. Marka Olmak
  3. MySQL'e Giriş
  4. Web tasarımında "pattern" kullanımı
  5. Web Site Piramidi
  6. Kısa Bilgiler Örnekler
  7. E-Posta Takibi
  8. Stil Sayfaları
  9. Duvara Açılan Projeler
  10. Veri Aktarımı
 
Tasarımın Sonumu Geldi (2)>
Yazı Tipi KüçültYazı Tipi BüyütAna SayfaYazıcıdan ÇıkarPDF Belgesi Olarak GörüntüleFavorilerime EkleArkadaşıma Tavsiye EdeceğimRTF (Word Dokümanı) olarak görüntüle

Basitliğin Değeri

XP’de en çok duyulan sloganlardan ikisi “Çalışabilecek en basit çözümü uygula” ve “Gelecekte ihtiyacın olmayacak” ( kısaltması YAGNI ) şeklindedir. Bu iki sloganın temeli XP pratıği olan basit tasarıma dayanır.

YAGNI prensibine göre gelecekte kullanılır düşüncesiyle önceden kod eklenmemelidir. Bu prensibe uymak kolay görünebilir fakat problem esnek çatılar(flexible frameworks), tekrar kullanılabilir bileşenler(reusable components) ve esnek tasarımlar gibi konular gündeme geldiğinde ortaya çıkar. Bu tür yapıları geliştirmek zordur ve gelecekte esnekliği sağlayabilmek için başlangıçta büyük bir tasarım çalışması gerektirir ve etkili yazılım tasarımının hedeflerinden biri esnekliktir.


Fakat XP’nin önerilerinden birisi esnek çatılar ve bileşenlerin hemen geliştirilmemesi yönündedir. Sadece o anki gereksinimleri karşılayacak şekilde bir yapının geliştirilmesi önerilir. Bu yapı zamanla eklenen gereksinimlerle evrimleşir. Örnek vermek gerekirse bugün Para nesnesinde sadece Toplama işlemine ihtiyacım varsa ve Çarpma işlemi benim için bir ihtiyaç değilse sadece Toplama işlemini koda eklemeliyim. Gelecek yinelemede (iteration) da Çarpma işlemine ihtiyacım olacağını bilsem ve bunu eklemenin çok kolay olduğuna inansam bile bunu sonraki yinelemeye kadar ertelemeliyim.

Bunun nedenlerinden biri ekonomik olmasidir. Eger gelecekte ihtiyacim olacak birsey icin bugun zaman harcarsam su anki yinelemede kullanabilecegim zamandan kaybetmis olurum. Yayim plani(release plan) icinde bulunulan yinelemede neler ustunde calisilmasi gerektigini belgeler ve yazilim gelistiricilerin bunlar disinda seyler ustunde calismasi bu plana aykiri duser. Mevcut yinelemede zaman olmasi olasiliginda bile hangi ozellikler ustunde calisilacagi musterinin insiyatifindedir ki bu yazilim gelistiricinin secimiyle ayni olmayabilir.

Ekonomik olmamasının yanında bir olasılıkta Çarpma işleminin o an müşterinin istediği şekilde yapılamaması riskidir. Ne kadar emin olursak olalım detaylı bilgimizin olmadığı bir konuda yanlış yapabiliriz. Yanlış bir çözüm üstünde çalışmak daha büyük zaman kaybıdir. XP uzmanları bu tur durumlarda çoğu zaman yanlış yapılacağına inanırlar ve bende bu fikirdeyim.

İkinci neden ise kompleks tasarımın basit tasarıma göre anlaşılmasının daha zor olmasıdır. Eklenen her karmaşıklıkla beraber sistemde değişiklikler yapmak zorlaşır. Değişiklikler gerçekten bu değişikliklere ihtiyaç duyulan zamandan önce yapılırsa bu durum diğer yapılan çalışmaları zorlaştırabilir ve bu nedenle ek bir maliyet getirir.

Bu öğütler çoğu insana saçmalık gibi gelebilir ve böyle düşünmelerinde haklı olabilirler çünkü alışılan biçimde yazılım geliştirmede XP nin buna olanak sağlayan pratikleri mevcut değildir. YAGNI nin iyi bir pratik olması için XP pratiklerine ihtiyaç vardır.

Özetlemek gerekirse gelecekteki bir yineleme(iteration) için gerekli bir özelliği şimdiden eklemeyin. Size hiç maliyeti yok gibi görünebilir fakat gene de sistemi daha kompleks haline getireceği için sistemin kolayca değiştirebilirliğini etkiler. Basitlikten yana olursanız ancak XP pratiklerini (tekrar tasarım, test, sürekli tümleşim) kullanarak başarılı olabilirsiniz.

Basitlik de ne demek?

Evet yazdığımız kod mümkün olduğu kadar basit olmalı dedik. Bu tartışılacak bir konu değil gibi çünkü kimsenin karmaşıklık peşinde olduğunu sanmıyorum. Fakat soru şu olabilir “Basitlik tam olarak ne demek”?

XPE de Kent basit bir sistem için 4 kriter veriyor. Önem sırasına göre (İlki en önemli olduğu halde)
1. Bütün testleri başarıyla çalıştıran
2. Maksadını kolayca gösterebilen -anlaşılabilir
3. Aynı kodun birkaç yerde karşımıza çıkmadığı- kopya kodların olmadığı
4. En az nesne ve metodun olduğu


Bütün testleri başarıyla çalıştırıyor olması basit bir kriter. Kopya kodların olmaması da aynı şekilde basit bir kriter fakat çoğu yazılım geliştiriçin bunu gerçekleştirebilmesi için bir kılavuza ihtiyacı olabilir. “Maksadını kolayca gösterebilme-anlaşıbilir olma” kriterinin biraz açıklamaya ihtiyacı var. Bu tam olarak ne demek?


Anlaşılabilir olma burada kodun kolayca anlaşılabilmesi anlamındadır. XP kodun rahatça okunabilmesine çok önem verir.

John Kerievsky XP 2000 deki bir makalesinde bunun için güzel bir örnek veriyor. Bu örnekte Junit kodunu inceliyor. Junit dekorator(decorator) tasarım kalibini(design pattern) kullanarak mevcut testlere aynı anda kullanım durumunda senkronizasyon(concurrency synchronization) ve topluca testlerin kurulabilmesi için kullanıyor. Bu tasarım kalıbının uygulanmış olması kodu daha anlaşılabilir ve okunması kolay hale getiriyor.

Fakat kodun basit olup olmadığını göreceli bir durum. Bana göre basit olan bir durum başkaları için daha karmaşık bulunabilir veya tam tersi. Kodun anlaşılabilirliği koda bakan insanın deneyimine göre değişebilen bir durum. Deneyimli tasarımcılar için kodun anlaşılması daha kolaydır.

Kod kopyalamalarının engellenmesi XP nın (Sadece ve sadece bir kere – Önce and Önly Önce)ve Pragmatic Programmer in DRY (Kendini Tekrar Etme- Don’t Repeat YourSelf) in verdiği en iyi öğütlerden biri. Sadece bu tavsiyeyi uygulamanız size çok yarar getirecektir. Fakat sadece bu herşey demek değildir ve basitliğe ulaşmak çok zor olabilir.

Geçenlerde fazlaca tasarlanmış(over-design) bir projede yeraldim. Tekrar tasarım(refactoring) uygulandı ve esnekliğin bir kısmı sistemden kaldırıldı ve sistem basitleştirildi. Yazılım geliştiricilerden birinin dediği gibi “Fazlaca tasarlanmış bir kodu tekrar tasarlamak ve iyileştirmek hiç tasarımın uygulanmadığı bir kodu tekrar tasarlamaktan daha kolay”. Gerekenden biraz daha basit olmak iyi fakat kompleks bir tasarım facia demek değil”. Yani fazla tasarımdan korkmamak gerekiyor.

Robert Martin den duyduğum en iyi öğüt basit tasarım konusunda çok tutucu olmamak şeklindeydi. Sonuçta tekrar tasarımın önemi neyin daha basit olduğuna karar vermekten çok daha fazla ve tekrar tasarım sayesinde sistemi gelecekte basitleştirmek mümkün olabilir.

Tekrar Tasarım(refactoring) YAGNI prensibine aykırı mi?

Bu konu geçenlerde bir XP haber listesinde tartışıldı. Bence burada bu konuyu irdelemekte yarar var. Basitçe soru söyle başlıyor. Tekrar tasarım (refactoring) zaman alıyor fakat sisteme yeni özellikler eklemiyor. Fakat YAGNI prensibi sadece o an için tasarım yap dediği için bu bir çelişki doğurmuyor mü? YAGNI deki ana nokta sistemi gelecekte ihtiyaç duyulabilecek özellikler için daha karmaşık hale getirmemek.

Bu basit tasarım pratiğinin bir parçası. Tekrar tasarım ise mevcut kodu mümkün olduğunca basit tutmaya olanak sağlayan bir pratik. Yani ikişide basitliğe hizmet ediyor. Ne zaman kodunuzda bir iyileştirme imkanı görseniz, bunu tekrar tasarım pratiğiyle gerçekleştirmeniz gerekir.

Basit tasarımın uygulanabilmesi için test,sürekli tümlesim ve tekrar tasarım gibi XP pratiklerinin uygulanıyor olması lazım. Basit Tasarım aynı zamanda başka pratiklerin çalışabilmesi için de gerekli bir pratik.Yani XP pratikleri bir bütün teşkil ediyor. Tasarımı basit tutmak değişim eğrisini sabit tutmak için de gerekli. Gerekli olmayan kompleks özelliklerin eklenmesi sadece beklediğiniz değişikliklerin gerçekleşmesi durumunda yararlı olur. Beklentilerin çoğu zaman gerçekleşmediğini düşünürsek bu eklentiler sistemi karışık hale getirmekten birşeye yaramayacaktir. Böyle bir durumda tekrar tasarım ile basitleştirilmelidir. Hedef : Basitlik...



Not: Yazılar konusundaki yorumlarınız için lütfen Yorum Yazın bölümümüzü kullanın.

Yazar : Cenk Çivici
Son Güncelleme : 26 Ekim 2005, Çarşamba
Sayfa Sürümü : 1
Okunma Adedi : 9,215
Son Okunma : 2017-10-19 16:19:00
Kaynaklar : http://www.yazilimmimarlari.com

Tasarımın Sonumu Geldi? (1)Tasarımın Sonumu Geldi (2)Tasarımın Sonumu Geldi? (3)
© [Site Haritası]
| Makaleler | Seyir Defteri | Kaynaklar | İndirin | İletişim |

RSS dosyasını görmek için tıklayınız. RSS dosyasını görmek için tıklayınız.XML versiyonu için tıklayınız WAP versiyonu için tıklayınız Bu site DyNA İçerik Yönetim Sistemi üzerinde çalışmaktadır.
İsmail KIRBAŞ ile Tasarım Yolculuğu Anasayfa İsmail KIRBAŞ ile Tasarım Yolculuğu Anasayfa İsmail KIRBAŞ ile Tasarım Yolculuğu Anasayfa
ismail kırbaş ile web sitesi tasarimi sitemap ismail kırbaş ile web sitesi tasarimi sitemap
  Sitemizde 4 kişi çevirimiçi | Bugün =20 | Dün =154 | Bu Ay=4,653 | Günlük En Fazla=1,109 tekil ziyaretçi