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:

Ö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
Yazılım Mühendisi