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

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




En Son Okunan 10 Makale
  1. E-Marka Olmada Aşamalar
  2. Kısa Bilgiler Örnekler
  3. Web tasarımında "pattern" kullanımı
  4. Danışmanlık ve Yönetim
  5. Koç kimdir, katma değeri nedir?
  6. ISO 18001-14001
  7. Zorluklar
  8. CE İşareti ve ISO Belgesi
  9. Toplantıdan Zaferle Çıkmanın Yolları
  10. Mali Müşavirlik ve Yönetim Danışmanlığı
 
Tasarımın Sonumu Geldi? (3)>
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

Kalıplar ve XP

JUnit örneği ister istemez kalıpları akla getiriyor. XP ve kalıplar arasındaki ilişki merak edilen ve hakkında çok soru sorulan konulardan biri ve bence aralarindaki iliski oldukça ilginç. Joshua Kerievsky XP de kalıpların gerektiğince vurgulanmadığını öne sürüyor. Çoğu insanda aynı fikirde gibi. XP kalıpların kullanılmasıyla zıt düşen özelliklere sahip gibi bir önyargı var.


Bana göre kalıplar kas yapalım derken göz çıkartılan başlıca alanlardan biri. Günümüzde Design patterns - GOF kitabını okuduktan sonra 32 satır kodda 16 kalıp kullanan birçok efsanevi programcı mevcut. Gerçekten günümüzde kalıpların gereksizce kullanıldığı çok durum karşımıza çıkıyor fakat bu kalıpların kötü bir fikir olduğu anlamına gelmemeli. Asıl sorulması gereken soru kalıpların nasıl kullanılacağına dair olmalı.

Bir teoriye göre basit tasarım ilkesini takip ederek sonuç olarak kalıplara ulaşmak mümkün deniyor. Çoğu zaman tekrar tasarım(refactoring) kodu bir kaliba uygun hale getirmek amacıyla kalıplara doğru yapılabiliyor. Ayrıca tasarım kalıpları hakkında bilginiz olmasa bile basitten karmaşığa doğru tekrar tasarım pratiğini uygulayarak ilerlediğinizde sonuçta bu kalıplara ulaşmak mümkün olabiliyor. Fakat kalıpları bilmeden ilerlemek gerçekten iyi bir yol olabilir mi? Tasarım kalıplarını bilerek ve referans bir kitap elinizin altında iken çalışmak daha akıllıca olur diye düşünüyorum. Bu şekilde bir kalıbın kullanılma ihtimali belirdiği zaman bunu farkedip GÖF ün kalıplar kitabına bakabilir ve bunu uygulayabilirsiniz. Etkili tasarım bence kalıpların maliyetlerinin de farkında olmalı. Kalıplara kodun evrim süreci içinde ulaşılmalı. Baştan sadece kalıplara uygulama amacıyla gerekmediği halde kalıplar kullanılıp maliyet ve kodun karmaşıklığı arttırılmamali. Bu açıdan bakıldığında XP kalıplara gereken önemi veriyor fakat çoğu tasarım sürecinin tersine XP de evrim süreci içinde bu kalıplara amaçlanıyor.

Buna rağmen bazı haber gruplarında insanların XP de kalıpların önemli olmadığı fikrine sahip olduklarını görüyorum. Bu biraz komik çünkü XP yi destekleyenlerin çoğu kalıplar konusunda da lider konumundalar. Bence kalıpların hayatı bir önemi var. XP yazılım geliştirme süreci olabilir fakat kalıplar tasarım bilgisinin belkemiğini oluşturuyor ki bu bilgi hangi süreç kullanılır olursa olsun eşit öneme sahip. Değişik süreçler kalıpları değişik şekillerde uygulayabilir. Bu açıdan XP kalıpların sadece gerekli olduğu hallerde kullanılmasını ve kalıplara doğru kodun evrimleşmesini savunuyor. Kalıplar hakkındaki bilgi XP içinde anahtar öneme sahip.

XP kullananlara kalıplar konusunda tavsiyelerim şu şekilde olacak

1. Kalıplar konusundaki bilginizi arttırın
2. Ne zaman kalıpları kullanacağınız konusunda yoğunlaşın(gerekliliğine emin olmadna çok erken kullanmayın)
3. Bir kalibi en basit şekliyle nasıl uygulayabileceğinizi ve daha sonra nasıl komplekslik ekleyebileceğiniz konusunda yoğunlaşın.
4. Bir kalibi uygular fakat daha sonra bunun gerçekten işleri kolaylaştırmadığını görürseniz kalibi çıkarmaktan korkmayın.

XP nin kalplar konusuna daha fazla vurgulaması gerektiğini düşünüyorum. Bunun XP pratikleri içine nasıl formüle edileceğini bilmiyorum fakat eminim Kent bununda bir yolunu bulacaktir.


Mimarının Evrimle Geliştirilmesi

Yazılım mimarisi ne anlama geliyor? Bana göre mimarı sistemin değiştirilmesi zor olan ve altyapıyı teşkil eden temel bileşenlerini ve bu bileşenlerin birbirleri arasındaki ilişkileri kapsıyor.

Evrimleşen tasarımda mimarının oynadığı rol nedir? XP ye karşı olanların bu konudaki savi XP nin mimarıyı unuttuğu yönünde.Aynı görüşe göre XP deki yöntem hızlı şekilde kodlamak ve tekrar tasarım pratiği sayesinde problemlerin çözüleceğine inanmak. İlginç olan bu konuda haklılık paylarının olması ve bu konunun XP nin zayıf noktalardan biri olması. Ron Jeffries , Kent Beck ve Bob Martin gibi XP nin en önemli savunucuları başlangıçtaki mimarı çalışmalarını önlemek için çok çalışıyorlar. Örneğin başlangıçta ihtiyacınız yoksa veritabanını kullanmayı erteleyin, normal dosyalarla çalışın ve kesin ihtiyaç belirince veritabanı kullanımına geçiş yapın ve bu geçiş için tekrar tasarım pratiğini kullanın diyorlar.

Ben her ne kadar öyle olmasamda çekingen bir XP çi olarak bilinirim. Bunun nedenlerinden biri başlangıç noktasında mimarı için kısada olsa bir çalışma yapılması gerektiğini düşünmem. Bu kısa çalışma esnasında uygulamanın hangi katmanlardan oluşacağı, veritabanı ve/veya web sunucusu ile nasıl iletişim kurulacağı gibi noktalar açıklığa kavuşturulabilir.

Mimari ile ilgili konulardaki kararların yıllar boyu deneyimlerimiz sonucunda artık mimarı kalıpları haline geldiğini düşünüyorum. Kalıplar hakkındaki bilginiz arttıkça , bu kalıpları uygulamadan önce kısa bir deneme çalışmasının gerektiğini bilirsiniz. Önemli olan başka bir konuda bu tür kalıp uygulamalarının geri dönüşü olmayan değişmez kararlar olarak görülmemesi gerektiğidir. Ekip bu kalıpları sistemden çıkarmaktan korkmamalıdır. Örneğin bana anlatılan bir hikayeye göre bir projede sonlara doğru ekip EJB ye ihtiyaç olmadığına karar verdi ve bunu kaldırdı. Bu oldukça büyük bir tekrar tasarım idi ve projenin son aşamalarına doğru yapılmıştı fakat XP deki pratikler sayesinde bunun altından kalkmak mümkün oldu ve sonuç başarılıydı.

Bunun tam tersi bir durumu düşünelim. Diyelim ki ilk başlarda EJB kullanmamaya karar verdiniz. Daha sonraları EJB yi kullanmaya geçmeniz ne kadar zor olabilir? Zor olmayacaksa EJB kullanmadan başlayıp daha sonra gerçekten ihtiyacını gördükten sonra EJB ye geçmeniz daha iyi bir yol olabilir mi? Bu sorunun cevabını belirlerken birçok faktörü gözönünde bulundurmak lazım. Karışık bir bileşen olmadan çalışmak basitliği ve işlerin daha hızlı yürümesini sağlayacaktır fakat zaman zaman bu tür bileşenleri sonradan sistemden çıkarmak , eklemeye çalışmaktan daha kolay olabilir.

Özetle benim tavsiyem ilk başta mimarının nasıl olabileceği konusunda bir çalışma yapılması şeklinde. Eğer çok fazla verinin ve kullanıcının olduğunu görürseniz veritabanını kullanmaya ilk gündeb başlayın. Eğer karışık bir iş modeli görürseniz, alan(domain) modeli oluşturun. Fakat YAGNI prensibine uymak açısından mimarının bir kısmının gerekmediğini anladığınız anda bunu mimariden çıkarmaktan çekinmeyin.

UML ve XP

XP konusunda bana yöneltilen sorulardan birçoğu UML çevresinde odaklanıyor. UML ve XP birbiri ile uyumsuz mu?

Uyumsuzluğun akla geldigi birkaç nokta var. XP diyagramlardan kaçınılmasını veya sadece çok gerekli olduğu durumlarda kullanılmasını istiyor. Gerçek XP çiler diyagram kullanmaz gibi söylemler mevcut. Kent Beck gibi insanlar diyagramlar çizmekten ve bunları kullanmaktan kaçınmaya çalışıyor.

Bence XP nin bu bakış açısının iki nedeni var. Birincisi bazı insanlar diyagramları yararlı bazıları ise yararsız buluyor. Burada tehlike bu iki ayrı düşüncenin kendisini diğer tarafa dikte ettirmeye çalışması. Bence bazı insanların diyagramları kullanacağını, bazılarının da kullanmayacağını kabul etmemiz gerekiyor.

İkinci nedende diyagramların ağır yazılım süreçleri ile birlikte anılır halde olmasından kaynaklanıyor. Bu tür süreçler diyagramları çizmek için çok fazla zaman harcıyor ve bu çizimler hem zaman kaybına hem de çoğu zaman yarar yerine zarar getiriyor. Bu nedenle bence insanların diyagramlar kullanırken bunları nasıl kullanışlı hazırlanacağı ve tuzaklardan nasıl kaçınılacağı konusunda eğitilmesi gerekiyor

Benim diyagramların nasıl kullanılacağı ile ilgili şu tavsiyelerim olacak :

1)Öncelikle diyagramları ne için hazırladığınızı sürekli aklınızda tutun. Diyagramın ilk amacı iletişimi kolaylaştırması. Etkili iletişim için önemli ögeleri seçmeli , önemsizleri ise boşvermelisiniz. Bu seçim UML in etkili kullanımı için şart. Bütün nesneleri UML çiziminizde göstermeyin. Çizim sadece önemli nesneleri içersin. Nesnelerde sadece önemli alan ve yöntemleri çizime koyun. Her durum için Sequence diyagramlarını çizmeyin ve bunlar gibi. Benim UML diyagramlarında dikkatimi çeken problem insanların diyagramları ayrıntılı ve kendini açıklayabilecek şekilde hazırlamaya çalışmaları. Kod ayrıntının ve asıl bilginin bulunduğu yer. Bu bilgiyi diyagramlarda sunmaya çalışmak diyagramları amaçından saptırıyor.

Diyagramların başlıca kullanım alanlarından biri kodlamaya başlamadan önce tasarımın yeterliliğini görmek. XP ye göre kodlama öncesi tasarımı bir çizimle ifade etmenin yanlış olduğu gibi önyargi var. Fakat tam tersine karmaşık bir ozelligin kodlanmasindan önce kısa bir tasarım çalışması yapmak çok yararlı. Bu çalışmanın özellikleri şunlar olmalı.

Kısa tutulmalı Bütün detayları çözmeye çalışmamalı ( sadece önemli olanlar üstüne yoğunlaşmalı) Sonuçtaki tasarım taslak vazifesi görmeli, son tasarım değil. Şondaki özelliği biraz daha acayim. İlk başta biraz tasarım yaptığınız zaman bu tasarımdaki hataların , yanlış varsayımların farkına daha sonraları özellikle kodlamaya başladığınız zaman varabilirsiniz. Bu problem olmayabilir çünkü tasarımı değiştirebilirsiniz. Fakat problem eğer insanların tasarım aşamasının bittiğine inandığı durumlarda ortaya çıkıyor çünkü bu tur durumlarda kodlamadan gelen geri beslenim bitmiş tasarıma etki edemiyor.

Tasarımı değiştirmek diyagramların değişeceği anlamına gelmeyebilir. Tasarım için taslak şeklinde bir diyagram hazırlayıp daha sonra bunu atabilirsiniz. Diyagram tasarımı anlamanız için yararlı olacaktır fakat bu aşamadan sonra önemli belgeler haline gelmemelidirler. En iyi diyagramlar bu şekilde kullanılmayan artifact haline gelmeyen diyagramlardır.

Birçok XP çi CRC kartları kulanır. Bu UML ile çelişkili bir durum değildir. Ben CRC ve UML kartlarını o anki durum için daha yararlı olanı seçerek kullanmışımdır.

UML diyagramlarının kullanım amaçlarından bir başkası da dokümantasyondur. Genel kullanımı ile diyagramlar bir case aracının içinde bulunur. Bu şekilde insanların çalışmasının kolaylaşacağı düşünülür fakat pratik bu düşüncenin tamamen yanlış olduğunu göstermektedir.

Case araçlarındaki diyagramların güncel tutulması için zaman harcamak gereklidir. Kısa zamanda diyagramlar ve kod arasındaki senkronizasyon bozulur.

Case aracında veya kalın bir klasörde bulunan çizimlere bakmaya çoğu zaman ihtiyaç duyulmaz.

Bu konudaki tavsiyem:

Sadece çok fazla zahmet gerekmeksizin güncel tutulabilecek diyagramlar kullanın. Diyagramları herkesin görebileceği bir yerde bulundurun. Örneğin bir duvara poster şeklinde aşın. Basit değişiklikler için insanların bu posteri kalemle değiştirmelerine izin verin. İnsanların bu diyagramları kullanmadığına kanaat getirirseniz diyagramları atın. Son olarak UML diyagramlarının iki ilgili grup arasında el değiştirdiği durumlardan bahsetmek istiyorum. XP de dokümantasyon oluşturmak müşteriye değer kattığı zaman tıpkı diğer hikayeler(story) gibi değerlendirilir. Bu durumda UML gene yararlıdır ve iletişimi kolaylaştırır. Bir diyagram binlerce kelimeye bedel olabilir fakat gene diyagramlar seçilerek önemli ögeleri içerecek şekilde hazırlanmalıdır. Kod ayrıntılı bilginin olduğu yegane yerdir. Diyagramlar kodun içerdiği bilginin özeti ve önemli noktalarını açığa çıkarmak açısından kullanılmalıdır.



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 : 7,188
Son Okunma : 2017-12-11 22:39:14
Kaynaklar : http://www.yazilimmimarlari.com

Tasarımın Sonumu Geldi (2)Tasarımın Sonumu Geldi? (3)Duvara Açılan Projeler
© [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 2 kişi çevirimiçi | Bugün =224 | Dün =174 | Bu Ay=2,007 | Günlük En Fazla=1,109 tekil ziyaretçi