Bilgisayar Mühendisleri Portalı

Martin FOWLER'dan XP Yorumları

Basitligin Degeri

XP’de en çok duyulan sloganlardan ikisi “Çalisabilecek en basit çözümü uygula” ve “Gelecekte ihtiyacin olmayacak” ( kisaltmasi YAGNI ) seklindedir. Bu iki sloganin temeli XP pratigi olan basit tasarima dayanir.

YAGNI prensibine göre gelecekte kullanilir düsüncesiyle önceden kod eklenmemelidir. Bu prensibe uymak kolay görünebilir fakat problem esnek çatilar(flexible frameworks), tekrar kullanilabilir bilesenler(reusable components) ve esnek tasarimlar gibi konular gündeme geldiginde ortaya çikar. Bu tür yapilari gelistirmek zordur ve gelecekte esnekligi saglayabilmek için baslangiçta büyük bir tasarim çalismasi gerektirir ve etkili yazilim tasariminin hedeflerinden biri esnekliktir.


Fakat XP’nin önerilerinden birisi esnek çatilar ve bilesenlerin hemen gelistirilmemesi yönündedir. Sadece o anki gereksinimleri karsilayacak sekilde bir yapinin gelistirilmesi önerilir. Bu yapi zamanla eklenen gereksinimlerle evrimlesir. Örnek vermek gerekirse bugün Para nesnesinde sadece Toplama islemine ihtiyacim varsa ve Çarpma islemi benim için bir ihtiyaç degilse sadece Toplama islemini koda eklemeliyim. Gelecek yinelemede (iteration) da Çarpma islemine ihtiyacim olacagini bilsem ve bunu eklemenin çok kolay olduguna 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 olmamasinin yaninda bir olasilikta Çarpma isleminin o an müsterinin istedigi sekilde yapilamamasi riskidir. Ne kadar emin olursak olalim detayli bilgimizin olmadigi bir konuda yanlis yapabiliriz. Yanlis bir çözüm üstünde çalismak daha büyük zaman kaybidir. XP uzmanlari bu tur durumlarda çogu zaman yanlis yapilacagina inanirlar ve bende bu fikirdeyim.

Ikinci neden ise kompleks tasarimin basit tasarima göre anlasilmasinin daha zor olmasidir. Eklenen her karmasiklikla beraber sistemde degisiklikler yapmak zorlasir. Degisiklikler gerçekten bu degisikliklere ihtiyaç duyulan zamandan önce yapilirsa bu durum diger yapilan çalismalari zorlastirabilir ve bu nedenle ek bir maliyet getirir.

Bu ögütler çogu insana saçmalik gibi gelebilir ve böyle düsünmelerinde hakli olabilirler çünkü alisilan biçimde yazilim gelistirmede XP nin buna olanak saglayan pratikleri mevcut degildir. YAGNI nin iyi bir pratik olmasi için XP pratiklerine ihtiyaç vardir.

Özetlemek gerekirse gelecekteki bir yineleme(iteration) için gerekli bir özelligi simdiden eklemeyin. Size hiç maliyeti yok gibi görünebilir fakat gene de sistemi daha kompleks haline getirecegi için sistemin kolayca degistirebilirligini etkiler. Basitlikten yana olursaniz ancak XP pratiklerini (tekrar tasarim, test, sürekli tümlesim) kullanarak basarili olabilirsiniz.

Basitlik de ne demek?

Evet yazdigimiz kod mümkün oldugu kadar basit olmali dedik. Bu tartisilacak bir konu degil gibi çünkü kimsenin karmasiklik pesinde oldugunu sanmiyorum. Fakat soru su olabilir “Basitlik tam olarak ne demek”?

XP de Kent basit bir sistem için 4 kriter veriyor. Önem sirasina göre (Ilki en önemli oldugu halde)
1. Bütün testleri basariyla çalistiran
2. Maksadini kolayca gösterebilen -anlasilabilir
3. Ayni kodun birkaç yerde karsimiza çikmadigi- kopya kodlarin olmadigi
4. En az nesne ve metodun oldugu


Bütün testleri basariyla çalistiriyor olmasi basit bir kriter. Kopya kodlarin olmamasi da ayni sekilde basit bir kriter fakat çogu yazilim gelistiriçin bunu gerçeklestirebilmesi için bir kilavuza ihtiyaci olabilir. “Maksadini kolayca gösterebilme-anlasibilir olma” kriterinin biraz açiklamaya ihtiyaci var. Bu tam olarak ne demek?


Anlasilabilir olma burada kodun kolayca anlasilabilmesi anlamindadir. 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) tasarim kalibini(design pattern) kullanarak mevcut testlere ayni anda kullanim durumunda senkronizasyon(concurrency synchronization) ve topluca testlerin kurulabilmesi için kullaniyor. Bu tasarim kalibinin uygulanmis olmasi kodu daha anlasilabilir ve okunmasi kolay hale getiriyor.

Fakat kodun basit olup olmadigini göreceli bir durum. Bana göre basit olan bir durum baskalari için daha karmasik bulunabilir veya tam tersi. Kodun anlasilabilirligi koda bakan insanin deneyimine göre degisebilen bir durum. Deneyimli tasarimcilar için kodun anlasilmasi daha kolaydir.

Kod kopyalamalarinin engellenmesi XP nin (Sadece ve sadece bir kere – only and only once) ve Pragmatic Programmer in DRY (Kendini Tekrar Etme- Don’t Repeat YourSelf) in verdigi en iyi ögütlerden biri. Sadece bu tavsiyeyi uygulamaniz size çok yarar getirecektir. Fakat sadece bu hersey demek degildir ve basitlige ulasmak çok zor olabilir.

Geçenlerde fazlaca tasarlanmis(over-design) bir projede yeraldim. Tekrar tasarim(refactoring) uygulandi ve esnekligin bir kismi sistemden kaldirildi ve sistem basitlestirildi. Yazilim gelistiricilerden birinin dedigi gibi “Fazlaca tasarlanmis bir kodu tekrar tasarlamak ve iyilestirmek hiç tasarimin uygulanmadigi bir kodu tekrar tasarlamaktan daha kolay”. Gerekenden biraz daha basit olmak iyi fakat kompleks bir tasarim facia demek degil”. Yani fazla tasarimdan korkmamak gerekiyor.

Robert Martin den duydugum en iyi ögüt basit tasarim konusunda çok tutucu olmamak seklindeydi. Sonuçta tekrar tasarimin önemi neyin daha basit olduguna karar vermekten çok daha fazla ve tekrar tasarim sayesinde sistemi gelecekte basitlestirmek mümkün olabilir.

Tekrar Tasarim(refactoring) YAGNI prensibine aykiri mi?

Bu konu geçenlerde bir XP haber listesinde tartisildi. Bence burada bu konuyu irdelemekte yarar var. Basitçe soru söyle basliyor. Tekrar tasarim (refactoring) zaman aliyor fakat sisteme yeni özellikler eklemiyor. Fakat YAGNI prensibi sadece o an için tasarim yap dedigi için bu bir çeliski dogurmuyor mü? YAGNI deki ana nokta sistemi gelecekte ihtiyaç duyulabilecek özellikler için daha karmasik hale getirmemek.

Bu basit tasarim pratiginin bir parçasi. Tekrar tasarim ise mevcut kodu mümkün oldugunca basit tutmaya olanak saglayan bir pratik. Yani ikiside basitlige hizmet ediyor. Ne zaman kodunuzda bir iyilestirme imkani görseniz, bunu tekrar tasarim pratigiyle gerçeklestirmeniz gerekir.

Basit tasarimin uygulanabilmesi için test,sürekli tümlesim ve tekrar tasarim gibi XP pratiklerinin uygulaniyor olmasi lazim. Basit Tasarim ayni zamanda baska pratiklerin çalisabilmesi için de gerekli bir pratik.Yani XP pratikleri bir bütün teskil ediyor. Tasarimi basit tutmak degisim egrisini sabit tutmak için de gerekli. Gerekli olmayan kompleks özelliklerin eklenmesi sadece beklediginiz degisikliklerin gerçeklesmesi durumunda yararli olur. Beklentilerin çogu zaman gerçeklesmedigini düsünürsek bu eklentiler sistemi karisik hale getirmekten birseye yaramayacaktir. Böyle bir durumda tekrar tasarim ile basitlestirilmelidir.
Hedef : Basitlik...


***********************************************************


Kaliplar ve XP

JUnit örnegi ister istemez kaliplari akla getiriyor. XP ve kaliplar arasindaki iliski merak edilen ve hakkinda çok soru sorulan konulardan biri ve bence aralarindaki iliski oldukça ilginç. Joshua Kerievsky XP de kaliplarin gerektigince vurgulanmadigini öne sürüyor. Çogu insanda ayni fikirde gibi. XP kaliplarin kullanilmasiyla zit düsen özelliklere sahip gibi bir önyargi var.


Bana göre kaliplar kas yapalim derken göz çikartilan baslica alanlardan biri. Günümüzde Design patterns - GOF kitabini okuduktan sonra 32 satir kodda 16 kalip kullanan birçok efsanevi programci mevcut. Gerçekten günümüzde kaliplarin gereksizce kullanildigi çok durum karsimiza çikiyor fakat bu kaliplarin kötü bir fikir oldugu anlamina gelmemeli. Asil sorulmasi gereken soru kaliplarin nasil kullanilacagina dair olmali.

Bir teoriye göre basit tasarim ilkesini takip ederek sonuç olarak kaliplara ulasmak mümkün deniyor. Çogu zaman tekrar tasarim(refactoring) kodu bir kaliba uygun hale getirmek amaciyla kaliplara dogru yapilabiliyor. Ayrica tasarim kaliplari hakkinda bilginiz olmasa bile basitten karmasiga dogru tekrar tasarim pratigini uygulayarak ilerlediginizde sonuçta bu kaliplara ulasmak mümkün olabiliyor. Fakat kaliplari bilmeden ilerlemek gerçekten iyi bir yol olabilir mi? Tasarim kaliplarini bilerek ve referans bir kitap elinizin altinda iken çalismak daha akillica olur diye düsünüyorum. Bu sekilde bir kalibin kullanilma ihtimali belirdigi zaman bunu farkedip GÖF ün kaliplar kitabina bakabilir ve bunu uygulayabilirsiniz. Etkili tasarim bence kaliplarin maliyetlerinin de farkinda olmali. Kaliplara kodun evrim süreci içinde ulasilmali. Bastan sadece kaliplara uygulama amaciyla gerekmedigi halde kaliplar kullanilip maliyet ve kodun karmasikligi arttirilmamali. Bu açidan bakildiginda XP kaliplara gereken önemi veriyor fakat çogu tasarim sürecinin tersine XP de evrim süreci içinde bu kaliplara amaçlaniyor.

Buna ragmen bazi haber gruplarinda insanlarin XP de kaliplarin önemli olmadigi fikrine sahip olduklarini görüyorum. Bu biraz komik çünkü XP yi destekleyenlerin çogu kaliplar konusunda da lider konumundalar. Bence kaliplarin hayati bir önemi var. XP yazilim gelistirme süreci olabilir fakat kaliplar tasarim bilgisinin belkemigini olusturuyor ki bu bilgi hangi süreç kullanilir olursa olsun esit öneme sahip. Degisik süreçler kaliplari degisik sekillerde uygulayabilir. Bu açidan XP kaliplarin sadece gerekli oldugu hallerde kullanilmasini ve kaliplara dogru kodun evrimlesmesini savunuyor. Kaliplar hakkindaki bilgi XP içinde anahtar öneme sahip.

XP kullananlara kaliplar konusunda tavsiyelerim su sekilde olacak

1. Kaliplar konusundaki bilginizi arttirin
2. Ne zaman kaliplari kullanacaginiz konusunda yogunlasin(gerekliligine emin olmadan çok erken kullanmayin)
3. Bir kalibi en basit sekliyle nasil uygulayabileceginizi ve daha sonra nasil komplekslik ekleyebileceginiz konusunda yogunlasin.
4. Bir kalibi uygular fakat daha sonra bunun gerçekten isleri kolaylastirmadigini görürseniz kalibi çikarmaktan korkmayin.

XP nin kalplar konusuna daha fazla vurgulamasi gerektigini düsünüyorum. Bunun XP pratikleri içine nasil formüle edilecegini bilmiyorum fakat eminim Kent bununda bir yolunu bulacaktir.


Mimarinin Evrimle Gelistirilmesi

Yazilim mimarisi ne anlama geliyor? Bana göre mimari sistemin degistirilmesi zor olan ve altyapiyi teskil eden temel bilesenlerini ve bu bilesenlerin birbirleri arasindaki iliskileri kapsiyor.

Evrimlesen tasarimda mimarinin oynadigi rol nedir? XP ye karsi olanlarin bu konudaki savi XP nin mimariyi unuttugu yönünde.Ayni görüse göre XP deki yöntem hizli sekilde kodlamak ve tekrar tasarim pratigi sayesinde problemlerin çözülecegine inanmak. Ilginç olan bu konuda haklilik paylarinin olmasi ve bu konunun XP nin zayif noktalardan biri olmasi. Ron Jeffries , Kent Beck ve Bob Martin gibi XP nin en önemli savunuculari baslangiçtaki mimari çalismalarini önlemek için çok çalisiyorlar. Örnegin baslangiçta ihtiyaciniz yoksa veritabanini kullanmayi erteleyin, normal dosyalarla çalisin ve kesin ihtiyaç belirince veritabani kullanimina geçis yapin ve bu geçis için tekrar tasarim pratigini kullanin diyorlar.

Ben her ne kadar öyle olmasamda çekingen bir XP çi olarak bilinirim. Bunun nedenlerinden biri baslangiç noktasinda mimari için kisada olsa bir çalisma yapilmasi gerektigini düsünmem. Bu kisa çalisma esnasinda uygulamanin hangi katmanlardan olusacagi, veritabani ve/veya web sunucusu ile nasil iletisim kurulacagi gibi noktalar açikliga kavusturulabilir.

Mimari ile ilgili konulardaki kararlarin yillar boyu deneyimlerimiz sonucunda artik mimari kaliplari haline geldigini düsünüyorum. Kaliplar hakkindaki bilginiz arttikça , bu kaliplari uygulamadan önce kisa bir deneme çalismasinin gerektigini bilirsiniz. Önemli olan baska bir konuda bu tür kalip uygulamalarinin geri dönüsü olmayan degismez kararlar olarak görülmemesi gerektigidir. Ekip bu kaliplari sistemden çikarmaktan korkmamalidir. Örnegin bana anlatilan bir hikayeye göre bir projede sonlara dogru ekip EJB ye ihtiyaç olmadigina karar verdi ve bunu kaldirdi. Bu oldukça büyük bir tekrar tasarim idi ve projenin son asamalarina dogru yapilmisti fakat XP deki pratikler sayesinde bunun altindan kalkmak mümkün oldu ve sonuç basariliydi.

Bunun tam tersi bir durumu düsünelim. Diyelim ki ilk baslarda EJB kullanmamaya karar verdiniz. Daha sonralari EJB yi kullanmaya geçmeniz ne kadar zor olabilir? Zor olmayacaksa EJB kullanmadan baslayip daha sonra gerçekten ihtiyacini gördükten sonra EJB ye geçmeniz daha iyi bir yol olabilir mi? Bu sorunun cevabini belirlerken birçok faktörü gözönünde bulundurmak lazim. Karisik bir bilesen olmadan çalismak basitligi ve islerin daha hizli yürümesini saglayacaktir fakat zaman zaman bu tür bilesenleri sonradan sistemden çikarmak , eklemeye çalismaktan daha kolay olabilir.

Özetle benim tavsiyem ilk basta mimarinin nasil olabilecegi konusunda bir çalisma yapilmasi seklinde. Eger çok fazla verinin ve kullanicinin oldugunu görürseniz veritabanini kullanmaya ilk günden baslayin. Eger karisik bir is modeli görürseniz, alan(domain) modeli olusturun. Fakat YAGNI prensibine uymak açisindan mimarinin bir kisminin gerekmedigini anladiginiz anda bunu mimariden çikarmaktan çekinmeyin.

UML ve XP

XP konusunda bana yöneltilen sorulardan birçogu UML çevresinde odaklaniyor. UML ve XP birbiri ile uyumsuz mu?

Uyumsuzlugun akla geldigi birkaç nokta var. XP diyagramlardan kaçinilmasini veya sadece çok gerekli oldugu durumlarda kullanilmasini istiyor. Gerçek XP çiler diyagram kullanmaz gibi söylemler mevcut. Kent Beck gibi insanlar diyagramlar çizmekten ve bunlari kullanmaktan kaçinmaya çalisiyor.

Bence XP nin bu bakis açisinin iki nedeni var. Birincisi bazi insanlar diyagramlari yararli bazilari ise yararsiz buluyor. Burada tehlike bu iki ayri düsüncenin kendisini diger tarafa dikte ettirmeye çalismasi. Bence bazi insanlarin diyagramlari kullanacagini, bazilarinin da kullanmayacagini kabul etmemiz gerekiyor.

Ikinci nedende diyagramlarin agir yazilim süreçleri ile birlikte anilir halde olmasindan kaynaklaniyor. Bu tür süreçler diyagramlari çizmek için çok fazla zaman harciyor ve bu çizimler hem zaman kaybina hem de çogu zaman yarar yerine zarar getiriyor. Bu nedenle bence insanlarin diyagramlar kullanirken bunlari nasil kullanisli hazirlanacagi ve tuzaklardan nasil kaçinilacagi konusunda egitilmesi gerekiyor

Benim diyagramlarin nasil kullanilacagi ile ilgili su tavsiyelerim olacak :

1)Öncelikle diyagramlari ne için hazirladiginizi sürekli aklinizda tutun. Diyagramin ilk amaci iletisimi kolaylastirmasi. Etkili iletisim için önemli ögeleri seçmeli , önemsizleri ise bosvermelisiniz. Bu seçim UML in etkili kullanimi için sart. 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 diyagramlarini çizmeyin ve bunlar gibi. Benim UML diyagramlarinda dikkatimi çeken problem insanlarin diyagramlari ayrintili ve kendini açiklayabilecek sekilde hazirlamaya çalismalari. Kod ayrintinin ve asil bilginin bulundugu yer. Bu bilgiyi diyagramlarda sunmaya çalismak diyagramlari amaçindan saptiriyor.

Diyagramlarin baslica kullanim alanlarindan biri kodlamaya baslamadan önce tasarimin yeterliligini görmek. XP ye göre kodlama öncesi tasarimi bir çizimle ifade etmenin yanlis oldugu gibi önyargi var. Fakat tam tersine karmasik bir ozelligin kodlanmasindan önce kisa bir tasarim çalismasi yapmak çok yararli. Bu çalismanin özellikleri sunlar olmali.

Kisa tutulmali Bütün detaylari çözmeye çalismamali ( sadece önemli olanlar üstüne yogunlasmali) Sonuçtaki tasarim taslak vazifesi görmeli, son tasarim degil. Sondaki özelligi biraz daha acayim. Ilk basta biraz tasarim yaptiginiz zaman bu tasarimdaki hatalarin , yanlis varsayimlarin farkina daha sonralari özellikle kodlamaya basladiginiz zaman varabilirsiniz. Bu problem olmayabilir çünkü tasarimi degistirebilirsiniz. Fakat problem eger insanlarin tasarim asamasinin bittigine inandigi durumlarda ortaya çikiyor çünkü bu tur durumlarda kodlamadan gelen geri beslenim bitmis tasarima etki edemiyor.

Tasarimi degistirmek diyagramlarin degisecegi anlamina gelmeyebilir. Tasarim için taslak seklinde bir diyagram hazirlayip daha sonra bunu atabilirsiniz. Diyagram tasarimi anlamaniz için yararli olacaktir fakat bu asamadan sonra önemli belgeler haline gelmemelidirler. En iyi diyagramlar bu sekilde kullanilmayan artifact haline gelmeyen diyagramlardir.

Birçok XP çi CRC kartlari kulanir. Bu UML ile çeliskili bir durum degildir. Ben CRC ve UML kartlarini o anki durum için daha yararli olani seçerek kullanmisimdir.

UML diyagramlarinin kullanim amaçlarindan bir baskasi da dokümantasyondur. Genel kullanimi ile diyagramlar bir case aracinin içinde bulunur. Bu sekilde insanlarin çalismasinin kolaylasacagi düsünülür fakat pratik bu düsüncenin tamamen yanlis oldugunu göstermektedir.

Case araçlarindaki diyagramlarin güncel tutulmasi için zaman harcamak gereklidir. Kisa zamanda diyagramlar ve kod arasindaki senkronizasyon bozulur.

Case aracinda veya kalin bir klasörde bulunan çizimlere bakmaya çogu zaman ihtiyaç duyulmaz.

Bu konudaki tavsiyem:

Sadece çok fazla zahmet gerekmeksizin güncel tutulabilecek diyagramlar kullanin. Diyagramlari herkesin görebilecegi bir yerde bulundurun. Örnegin bir duvara poster seklinde asin. Basit degisiklikler için insanlarin bu posteri kalemle degistirmelerine izin verin. Insanlarin bu diyagramlari kullanmadigina kanaat getirirseniz diyagramlari atin. Son olarak UML diyagramlarinin iki ilgili grup arasinda el degistirdigi durumlardan bahsetmek istiyorum. XP de dokümantasyon olusturmak müsteriye deger kattigi zaman tipki diger hikayeler(story) gibi degerlendirilir. Bu durumda UML gene yararlidir ve iletisimi kolaylastirir. Bir diyagram binlerce kelimeye bedel olabilir fakat gene diyagramlar seçilerek önemli ögeleri içerecek sekilde hazirlanmalidir. Kod ayrintili bilginin oldugu yegane yerdir. Diyagramlar kodun içerdigi bilginin özeti ve önemli noktalarini açiga çikarmak açisindan kullanilmalidir.

Cenk Çivici
Yazilim Mühendisi