Tasarımın Sonumu Geldi? (1) - İ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? (1)

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 (2)
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:5567Güvenlik Kodu:5567Güvenlik Kodu:5567Güvenlik Kodu:5567




En Son Okunan 10 Makale
  1. Web Tasarım Rehberi
  2. Grafik Tasarım Ürününün Öğeleri
  3. Tasarımın Sonumu Geldi? (3)
  4. 10 Maddede Kullanıcı Odaklı Tasarım
  5. İçerik Yönetimi
  6. Kağıt Prototip
  7. Niçin Web Sitesi ?
  8. Yönetim ve Organizasyon
  9. Okunacak Kitaplar
  10. İnternetten
 
Tasarımın Sonumu Geldi? (1)>
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

Martin Fowler in "Is Design Dead?" adlı makalesinden Türkçeye çevrilmiştir. Bu makale bölümler halinde yayınlanacaktır.

Extreme Programlama(XP) hakkında üstünkörü bilgiye sahip olan çoğu insanın izlenimi “XP tasarıma son vermeye çalışıyor” şeklindedir. Bunun nedeni birçok tasarım aktivitesinin(örneğin proje başlangıcında detaylı tasarım aşaması) XP içinde yeri olmamasi ve XP’de UML, kalıplar(patterns), esnek çerçevelerin(frameworks) gibi tekniklerin uygulanmıyor olmadığı görüşüdür. Bu görüşlerin aksine XP’de tasarımın önemli bir yeri vardır fakat tasarım klasik yazılım süreçlerinindeki gibi uygulanmaz. XP evrimleşen tasarım fikrini savunur ve bunu uygulanabilir bir teknik haline getirmiştir. Basitlik prensibi, tasarımı temiz tutmak için tekrar tasarım(refactoring), kalıpların evrim ortamında nasıl kullanılacağı gibi tasarımcıların kendini geliştirmesi gereken yeni konular ortaya çıkarmıştır.

Makalenin geri kalan kısmı aşağıdaki bölümlerden oluşuyor.

•Planlı ve evrimleşen tasarım
•Evrimleşen tasarıma olanak sağlayan XP pratikleri
•Basitliğin değeri
•Basitlik de ne demek?
•Tekrar tasarım(refactoring) YAGNI prensibine aykırı mı?
•Kalıplar ve XP
•Mimarinin evrimle geliştirilmesi
•UML ve XP
•Metafor üzerine
•Büyüdügünde mimar mı olmak istiyor musun?
•Tersinirlik(reversibility)
•Tasarım isteği
•Tekrar tasarlanması zor olan şeyler
•Tasarım gerçekleşiyor mu?


Extreme Programlama klasik yazılım geliştirme düşünce yapısına aykırı olarak nitelendirilebilecek fikirler öne sürüyor. Bu fikirlerden başta geleni proje başlangıcında büyük çaba harcanan detaylı tasarım aşamasının XP tarafından reddediliyor olması ve bunun yerine evrimleşerek gelişen tasarımın tercih edilmesi. XP’yi eleştiren kimseler için bu düzensiz, kodlayalım sonra düzeltiriz (code and fix- hacking) şeklinde çalışmaya geri dönüş anlamına geliyor. Ayrıca UML, tasarım kalıpları ve prensiplerinin XP tarafından reddedildiği gibi eleştiriler sözkonusu. Bu eleştirilere göre XP’de tasarımın önemi yok , kodu yazıp düzelterek sonunda mucizevi bir şekilde iyi bir tasarıma ulaşmak mümkün.

Ben bu tartışmada kendimi orta noktada görüyorum. Kariyerimde uzun yıllar boyunca grafiksel tasarım dilleri- UML ve öncesi – ve kalıplar ile ilgili çalışmalar yaptım ve bu konularda kitaplar yazdım. XP yi savunuyor olmam sizce bu konulardaki çalışmalarımı reddettiğim ve bunlara artık inanmadığım anlamına geliyor olabilir mi?

Kısaca cevabım HAYIR. Uzun cevabım ise bu makalenin geri kalan kısmı….


Planlı ve evrimleşen tasarım

Bahsedeceğim iki tasarım yönteminden biri olan evrimleşen tasarım basit anlamıyla tasarımın sistem geliştirildikce evrimleşerek oluşması anlamına gelir. Tasarım sistem gelişip büyüdükçe değişime uğrar. Tasarım kod yazım sürecinin bir parçasıdır ve kod değişimine paralel değişir.

Genel kullanımı ile evrimleşen tasarım yöntemi felaketi davetiye çıkarır. Tasarım birbirinden kopuk üstünkörü alınmış tasarım kararlarının bütünününden oluşur ve bu kodun gelecekte değiştirilebilmesini güçleştirir. Tasarımın amacı Kent Beck’in ifade ettiği gibi yazılımda meydana gelebilecek değişiklikleri uzun vadede kolaylaştırmaktır. Tasarım kötüleştikçe değişiklerin yapılması zorlaşır ve bu durum devam ettikçe tasarım daha da içinden çıkılmaz hale gelir.

Planlı tasarım ise diğer mühendislik dallarındaki tasarım aşamalarına benzer. Örneğin bir köpek kulubesi yapacaksınız biraz tahta bulup bunları birbirine çakarak sonuçta bir yapı meydana getirebilirsiniz. Fakat bir gökdelen bina edecekseniz inşaatın yıkılmaması için başlangıçta detaylı bir planlama yapmanız gerekir. Bunun için eşiminde çalıştığı mühendislik ofisinde yapıldığı gibi çizimler yapar , matematiksel analizler gerçekleştirir ve yapı kodlarını kullanırsınız. Yapı kodları yapıların nasıl oluşturulması gerektiğine dair geçmiş deneyimler ve matematiksel veriler sonucu ortaya çıkmış kurallardır. Tasarım hazırlandıktan sonra mühendislik ofisi bu tasarımı inşaata başlaması için başka bir firmaya verir.

Yazılım projelerinde planlı tasarım benzer bir şekilde kullanılır. Tasarımcılar yazılım açısından önemli noktaları göz önüne alarak tasarımı hazırlar. Bu aşamada kod yazmak yerine UML gibi tasarım teknikleri ile çizimler yapılır. Bu çizimler kodlamanın zorlukları ile uğraşmadan tasarımcıların kolayca daha soyut bir bakış açısıyla çalışmasını sağlar. Tasarım aşaması bittiği zaman bu aşamanın ürünü olan çizimler çoğu zaman başka bir gruba verilir. Büyük ölçekte düşünülmesi ile gelecekte ortaya çıkabilecek karmaşa durumu engellenmeye çalışılır. Programcılar bu tasarımı bir rehber olarak alıp bunu takip ederek iyi bir sistem geliştirmeye çalışır.

1970’lerden beri planlı tasarım yöntemi yazılım projelerinde kullanılıyor ve kodlayalım sonra düzeltiriz (code and fix) yönteminden daha iyi olduğu kesin. Fakat bazı kusurları olduğu da gerçek. İlk kusuru tasarım aşamasında iken kodlama aşamasında ortaya çıkabilecek sorunları, almanız gerekecek önemli kararları öngörmenizin imkansiz olması. Yani kodlama aşamasında tasarımı etkileyecek, tasarımı sorgulayan kararların alınması gerekecek bu kesin. Fakat tasarımcılar proje grubundan ayrılmış ve başka bir projeye geçmiş iseler ne olacak? Programcılar kodlamaya başlar ve tasarımla kodlama arasında yaşanan çelişkiler karmaşa yaratırsa ne olacak? Tasarımcıların hala proje grubunda olduğunu varsaysak bile sorunları çözüp zaman harcayıp yaptıkları çizimleri değiştirmeleri gerekecek ve daha sonra programcılar tarafından bu değişiklikler koda yansıtılacak. Zaman baskısı altında projelerin bunu uygulaması hiç gerçekçi değil. Sonuç tekrar karmaşa.

Ayrıca tasarımcı ve programcı ayrımı kültürel bir probleme de neden olabilir. Tasarımcılar deneyim ve yetenekleri sayesinde tasarımcı olur. Fakat tasarımla uğraşırken kodlama da meydana gelen son teknolojik gelişmeleri kaçırırlar ve zamanla kodlayan insanlarla aralarında bir kültür farkı oluşur. Bu çekişmeyi beraberinde getirir ve iki grup birbirlerine olan saygılarını yitirirler.

Tasarımcılar ile kod yazanlar arasındaki tansiyon inşaat sektöründe de ortaya çıkabilir. Fakat yazılım sektöründe bu tansiyon daha yoğun yaşanacaktır. Bunun nedeni yazılım mühendisliği disiplinlerinin(tasarım,kodlama,test vs) inşaat mühendisliğindeki kadar birbirinden kesin çizgilerle ayrılmış olmamasıdır. Bir programcının kendisine verilen tasarımla birlikte çalışabilmesi için çok yetenekli olması gerekir ve yetenekli programcılar tasarımı özellikle tasarımcının günün teknik koşullarından haberdar olmadığı durumlarda sorgular.

Bunlar aşılabilir sorunlar olabilir. Gruplar arasındaki çekişmeleri önlemeye çalışabiliriz. Çok yetenekli tasarımcıları işe alıp disiplinli bir sürec ile sorunlar çıktıkca sürekli tasarımı güncel tutabiliriz fakat buna rağmen bir problem hala önümüzde duruyor. Bu da Değişen Gereksinimler(Requirements). Değişen gereksinimler günümüzde projelerin en büyük problemlerinden biri.

Değişen gereksinimlerle başaçıkabilmenin bir yolu tasarımı esnek hazırlamak ve bu şekilde gelecekte değişiklikleri kolayca tasarıma ekleyebilmek. Fakat böyle bir tasarım kararlarını alabilmek için sadece o anki değil gelecekte de ne tür değişikliklerin olabileceği hakkında fikir yürütmeniz gerekli. Eğer yanlış fikirler yürütürseniz hazırladığınız tasarım değişiklikler karşısında size yarar yerine zarar getirebilir. Bunun olmaması için yazılım gereksinimlerini çok çok iyi anlamak gerekiyor ki benim gözlemlerime göre bu aynı derecede güç.

Bazı problemler ise yazılım gereksinimlerinini iyi anlaşılmamasından kaynaklanıyor. Bu nedenle doğru gereksinimleri alabilmek için analiz süreçlerine odaklanılıyor fakat bu bile çözüm olmayabilir. Birçok değişiklik analiz edilen işin işleyiş şeklinde yani işin kendisinde meydana gelen değişikliklerden kaynaklanıyor. Bu yüzden gereksinimleri ne kadar iyi anlarsanız anlayın bu değişikliklerden kaçış yolu yok.

Bütün bunlar planlı tasarımın imkansız olduğunu gösteriyor. Buna rağmen planlı tasarımın kodlayalım sonra düzeltiriz mantığıyla çalışan evrimleşen tasarımdan daha iyi olduğunu düşünmüyorum. Aslına bakarsanız tercihim planlı tasarımdan yana fakat planlı tasarımdaki problemleri görüyorum ve bunlar için bir çözüm arıyorum.

Evrimleşen tasarıma olanak sağlayan XP pratikleri
Xp klasik yazılım süreçleri ile karşılaştırıldığında çatlak bir ses olarak nitelendirilebilir. Bunun büyük nedenlerinden birisi XP nin evrimleşen tasarımdan yana olmasındandır. Bildiğiniz gibi genel kullanımıyla evrimleşen tasarım üstünkörü verilen kararlar ve karmaşa yüzünden uygulanması çok güç olan bir yaklaşımdır.
Yazılım projelerinde değişiklikler zaman geçtikçe daha pahalıya malolur. Bu proje aşamaları gözönüne alınarak şu şekilde ifade edilebilir. “Analiz safhasında 1 liraya malolan bir değişikliği yapmak üretim aşamasından sonra binlerce liraya malolacaktır.” Bazı projelerde analiz safhasının olmamasına rağmen sonraları aynı değişiklik maliyetine ulaşmaları biraz komiktir. Durumun böyle olması evrimleşen tasarımın çalışmasının imkansız olduğunu gösterir ve aynı nedenle planlı tasarım çok detaylı ve dikkatli yapılmalıdır.

XP nin en temel hedeflerinden biri değişiklik maliyetini projenin hangi aşamasında olduğuna bakmadan sabit hale getirebilmek ve bu şekilde evrimleşen tasarımı hayata geçirmektir. Değişim maliyet eğrisini sabitleştirmek için XP deki bazı pratiklerin birbirinden ayrılmayacak şekilde çalışması şarttır. Pratiklerin bazıları değişim eğrisini sabitleştirmeye çalışırken bazıları ise bu sabitlikten faydalanır yani bu pratiklerin bütün olarak uygulanması şarttır. XP yi eleştiren çoğu insan sabitlikten faydalanan pratikleri eleştirir fakat bunların çalışmasına olanak sağlayan pratiklerin varlığını unutur. Bu pratikleri gördüklerinde tek başlarına uygulanmaları imkansız olduğundan kendi kötü hatıraları canlanır.

XP pratiklerinin özünü Test ve Sürekli tümleşim (integration) yatıyor. Testlerin verdiği güven olmadan XP yi uygulamak imkansız. Sürekli tümleşim ise ekibin uyum içinde çalışmasını sağlıyor. Yapılan bir değişikliğin başkalarının işleriyle entegrasyonu için kaygılanmaya gerek kalmıyor. Bu pratiklerin tümünün uygulanması değişiklik eğrisini büyük ölçüde etkileyebilir. Bunu Thoughtworks de bir kez daha anladım. Test ve sürekli tümleşimi yazılım geliştirme sürecimize dahil etmemiz çok faydalı oldu.
Çok daha büyük faydalar için XP nin tabiiki tüm pratiklerini uygulamak gerekiyor.

Tekrar tasarım(refactoring) ında benzer bir etkisi var. Disiplinli bir şekilde kodlarını tekrar tasarlayanlar başıboş yapılan tasarım iyileştirmelerine göre daha etkili sonuçlar aldıklarını belirtiyorlar. Kent’den nasıl tekrar tasarım yapılacağını ögrendikten sonra bu benimde yararına şahit olduğum bir pratik oldu ve bu konuda ancak büyük bir motivasyon hakkında tüm bir kitap yazmamı sağlardı.

Jim Highsmith “Özetle XP” yazısında tartı örneğini veriyor. Tartının bir tarafında planlı tasarım diğerinde ise tekrar tasarım(refactoring) var. Klasik yaklaşımlarda planlı tasarım daha baskın çıkıyor çünkü daha sonra değişiklik yapamayacağız fikri hakim. Değişiklik maliyetinin azaldığını, değişim eğrisinin sabit olduğunu farzedersek daha fazla tasarımı tekrar tasarım(refactoring) ile yapmak mümkün oluyor. Planlı tasarım tamamen bitmiyor fakat ikisinin dengeli bir beraberliği var. Tekrar tasarım(refactoring) i uygulamaya başlamadan önceki zamanlarda tasarımı eksik yaptığımı düşünüyorum.

Sürekli tümleşim, test ve tekrar tasarım evrimleşen tasarım için gerekli ortamı sağlıyor ve daha akla yatkın hale getiriyor. Fakat şu anda karar veremediğimiz nokta dengenin nerede olacağı. İzlenimin aksine XP sadece test yaz, kodla ve tekrar tasarla(refactor) dan ibaret değil. Kodlamaya başlamadan önce tasarım için yer var ve bunun büyük kısmı yinelemeler(iteration) içindeki bir işe başlamadan oluyor. Başlangıç tasarımı ile tekrar tasarım(refactoring) arasında bir denge var.



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

Yazar : Cenk Çivici (Yazılım Mühendisi )
Son Güncelleme : 26 Ekim 2005, Çarşamba
Sayfa Sürümü : 1
Okunma Adedi : 7,499
Son Okunma : 2017-12-13 03:04:22
Kaynaklar : http://www.yazilimmimarlari.com

Yazılım Projelerinde Rol DağılımıTasarımın Sonumu Geldi? (1)Tasarımın Sonumu Geldi (2)
© [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 5 kişi çevirimiçi | Bugün =25 | Dün =289 | Bu Ay=2,476 | Günlük En Fazla=1,109 tekil ziyaretçi