 |
|
Extreme Programming |
XP, yazılımın geliştirmede uyulması gereken bazı süreçleri,yöntemleri ortaya koyan
bir yaklaşımdır.Bir yazılım ekibi bu ilkelerin tamamına uyacak gibi bir kaide söz
konusu değildir.Kimi yazılımlar için bazı prensipler uygulanabileceği gibi bazılarında
başka prensipler uygulanabilir.Önemli olan burada,bizim yazılım projelerimizde,
aşağıdaki ilkelerin hangilerini uygulayabilirim sorusunun cevabını verebilmektedir.
-
XP takımı bütün bir takımdır.
Bir yazılımın başarılı bir şekilde sonuçlandırılabilmes,gereksinimlerin
doğru bir şekilde belirlenebilmesi için,projeye katkıda bulunan herkesin birlikte
çalışması gerekmektedir.Öyle ki, takım içerisinde bulunan yazılımcı,müşteri, yönetici,
takım lideri ve diğerleri aynı oda içerisinde bulunmalıdırlar ki,herkes herkesin
probleminden,isteğinden haberdar olabilsin.Özellikle müşteri ile yazılımcılar arasındaki
mesafe çok fazla olup,yüz yüze görüşmek yerine telefonla veya başka iletişim araçlarıyla
talepler alınır ise ortaya anlamsız gereksinimler yani istekler çıkabilecektir.Müşteri,
yazılımcının yapabileceklerinden haberdar olur ise,daha anlamlı ve tutarlı istekler
sunabilecektir.Zira müşteri,yazılımdan uzak biri olabilir. Velhasıl kelam projeye
bir şekilde dahil olan herkesin bir çatı altında,birlikte bulunması XP’de son derece
önemlidir. Eğer müşterinin yazılımcı ile birarada olması sağlanamıyor ise,bu durumda
müşteriyi temsil eden bir kişi belirlenip müşteri gibi davrandırılabilir.Tabi bu
kişi,müşteri konumundaki firmadan biri olabileceği gibi yazılım firması bünyesindeki
bir kişide olabilir.Bu kişi sanki müşteri gibi davranarak,müşteri ile yazılımcı
arasındaki köprüyü kurabilir.
- Kullanıcı Hikayeleri (User Stories)
Bir projede müşterinin talep edeceği pek çok senaryo mevcuttur.Biz
biliyoruz ki bir problemi, ne kadar anlamsal bütünlüğü olan parçalara bölebilirsek,problemimizi
çözmek o kadar kolay olur. Müşterinin sizden istediği yazılımın gerçekleştirmesi
gereken işleri, parçalara bölerek, kullanıcı hikayeleri(user story) oluşturulabilir.Bu
hikayeleri müşteri
 oluşturmaktadır.Yalnız burada önemli olan nokta bu hikayelerin
çok detaylı olmamasıdır.Kabataslak bir hikaye müşteri tarafından hazırlanır ve yazılımcı
bu hikaye üzerinde çalıştıktan sonra,gerçekleştirim için yaklaşık bir süre belirler.Ne
zaman ki yazılımcı hikayeyi kod düzeyinde gerçekleştirmek ister,işte o zaman yazılımcı
ile müşteri bir araya gelerek, hikayede konusu geçen herşeyin teknik detayları konuşulur.Bizler
biliyoruz ki bir müşterinin, projenin başında söylediği bir şey sonunda değişebilir,
ki bu değişikliğin sebeplerinden biri,müşterinin yazılım ile yapılabileceklerin
bir kısmından haberdar olmamasıdır.Müşteri ortaya konan ürünü gördükçe,başlangıçta
böyle olsun dediği şeyi,hayır şimdi şöyle olsun diyebilmektedir.Bir XP takımı sürekli
değişime hazır olmalıdır.İşte bu yüzden kullanıcı hikayeleri(user stories) az detaya
sahip bir biçimde ortaya konulur.
İdeal yazılım geliştirmede bu kullanıcı hikayelerinin süreleri 1,2
veya 3 hafta olarak öngörülmüştür. Eğer bir kullanıcı hikayesi bu süreleri geçer
veya altında kalırsa,hikayeleri bölebilir veya bir kaçını birleştirebilirsiniz.
Kullanıcı hikayelerinden yola çıkarak yazılım geliştirmenin bir güzel tarafıda,bu
hikayeleri kullanarak proje süresinin yaklaşık olarak hesaplanabilinmesidir.Zira
bir yazılım ekibi bir kullanıcı senaryosunu 2 haftada bitiriyor ve toplamda 200
tane kullanıcı senaryosu var ise,projenin yaklaşık olarak 400 haftada bitebileceği
öngörüsü yapılabilir.Böylelikle kullanıcıya belli aralıklarla projenin çalışan tarafları
gösterilip,düzenli bir takvim oluşturulabilinir.
- Belli aralıklarla yazılım yayınlanır.
Projemizde kullanıcı hikayelerinin olduğundan bahsettik. müşteri ,kullanıcı
hikayelerine öncelik belirler.Bu öncelikler göz önüne alınarak 1 ile 3 hafta arasında
değişen periyodlarda, gerçekleştirilen kullanıcı hikayeleri tamamlanır ve yayınlanır.Burada
önemli olan nokta şudur;Örneğin projemizde 3 haftayı yayınlama süresi olarak belirledik(Iteration).Bu
durumda önceliği olan kullanıcı hikayeleri bu sürede bitirilir ve yayına geçirilir.Yalnız
bu süre içerisinde detayları konuşulmuş olan kullanıcı hikayeleri kesinlikle müşteri
tarafından değiştirilemez.XP,müşteri isteklerinin değişmesini taban alan bir yaklaşımdır
yalnız iteration’ı bozmamak adına bu süre başlangıcından bitimine kadar kullanıcı
hikayelerinin değiştirilmesi kabul edilemez. 1-2 haftalık aralıklarla projenin ufak
parçaları yayınlanırken daha uzun süreler için Release plan hesaplanır.Bu sürede
3 ay civarındadır.Her 3 ay da bir projenin çalışır kısımları müşteri ortamına kurulur
ve müşterinin kullanması ve eksiklikleri görmesi sağlanır.Böylelikle müşteriden
sürekli geri dönüşüm alınmış olur.Tabi Release Plan’ı belirlerken,release plan’da
gerçekleştirilmesi gereken kullanıcı hikayelerinin neler olacağı müşterinin önceliklerine
göre belirlenir.Müşteri için en önemli kullanıcı hikayeleri,ilk release plan’larda
gerçekleştirilmiş olur.
- Kodun kabulü için kabul testleri esas alınır.
Belirlenmiş kullanıcı hikayeleri için,bir taraftan kod gerçekleştirilirken
bir taraftan da test senaryoları hazırlanır.Bu senaryolar müşteri tarafından da
hazırlanabilir,yazılım firması bünyesindeki tester’lar tarafından da.Önemli olan
nokta bu testlere bağlı kalınarak kullanıcı hikayelerinin(user story) başarılı olup
olmadığının belirlenmesidir.User story belirlendi,test belirlendi ve user story
kod düzeyinde gerçekleşti.Eğer yazılan kod,belirlenen test senaryolarını geçiyor
ise bu kullanıcı hikayesi başarılıdır denir ve bir daha başarısızmış gibi davranılamaz.
- İki kişilik ekiplerle yazılım gerçekleştirilir. (Pair Programming)
Pair programming kavramı bir bilgisayar başında iki kişinin bulunması
demektir.Evet biraz ilginç geliyor ama doğru.Bir
 masa,bir bilgisayar,bir klavye,bir
mouse ve iki sandalye,iki yazılımcı.Biri kod yazarken öbürü diğerini kontrol edecek,daha
sonra diğeri, kalk bakim şimdi de biraz ben yazayım diyecek ve bu sefer diğeri kontrol
etmeye başlayacak.Biri yazacak biri bakacak.Beraber düşünecekler, beraber çözecekler,kaynaşacaklar
vs.Her ne kadar iki yazılımcının,bir iş yapması gibi gözüksede zaman içerisinde
oluşabilecek hataları azalttığı, kodun kalitesini arttırdığı için tercih edilen
bir yöntemdir.Tabi bu iki kişilik ekip sürekli değişmektedir. Değişken bir yapısı
olduğu için,her yazılımcının,yazılımın hemen her yerinde parmağı bulunmaktadır.Her
yazılımcı, takım içerisindeki arkadaşlarıyla sıkı sıkıya bir ilişki içerisindedir.Her
ne kadar bazı kimseler,bazı konularda uzman olsada,bu kural değişmemektedir. Yine
iş,uzmanına verilmektedir yalnız genel anlamda iş dağılımı yapılmakta, böylelikle
herkesin, yazılımın her parçasından anlaması durumu sözkonusudur.Bu özellikle işten
ayrılma durumlarında firmayı daha az zoru sokacak hemde,takım içerisindeki kaynaşmadan
dolayı, huzursuzluktan kaynaklabilecek işten ayrılmalar muhakkak azalacaktır.
- Test-Driven Development (TDD)
XP’de uygulamalar şu şekilde gerçekleştirilir.Bir modül yazdığımızı
düşünün,ilk olarak yazılacak olan kodları için test kodları yazılır.(Unit Test kullanabilirsiniz.).Doğal
olarak henüz herhangi bir kod yazılmadığından dolayı,yazılan test kodları hata verecektir.Zaman
içerisinde kodları geliştirmeye başladıkta test kodları doğru sonuçlar üretmeye
başlayacaktır.Bir yandan kod yazarken bir yandan da test kodları yazmayı sürdüreceğiz.Yalnız
öncelik test’lere ait olacaktır.Örneğin modülümüzde bir geliştirme yapacağız,öncelikle
test kodları yapıp ardından kodlamaya geçeceğiz.Her ne kadar ilk bakışta zahmetli
gibi gözüksede, kodlarımızın hata olasılığını azaltacağı gibi,sürekli parça parça
denemeler yapacağımızda dolayı refactoring’i geliştirecektir.(Örneğin,uzun bir metod
yazıp test etmek zor olacağı için,bu metodu parçalara ayırıp,ayrı ayrı test etmek
daha kolay olacaktır.Bu durumda yazdığımız kod üzerinde sürekli refactoring yapmak
zorunda kalacağız)
- Takım içi işbirliği sağlanır.
Bir yazılım projesinin pek çok ayağı vardır.Bir yazılımda aynı anda
Windows Forms uygulamaları,web sevice uygulamaları,data access layer veya arayüzler,karmaşık
algoritmalar,veri tabanı sql komutları vs. bulunabilir.XP’de Ahmet, Windows uygulamalarında
harikadır o yüzden windows uygulamalarını Ahmet’e verelim,Veli, Data Access konusunda
uzmandır o yüzden bu işi o yapsın gibi bir yaklaşım sözkonusu değildir.Herkes,yazılım
bütün parçalarına müdahele eder ve geliştirme yapar.Her ne kadar örneğin Web Sevic
e konusunda uzman biri var ve bu kişi web service uygulamaları konusunda daha fazla
söz sahibi olsa da,Bu,diğer yazılımcıların web service’le ilgilenmeyeceği, veyahut
web service ile uğraşan kişinin karışık algoritmalara elini sürmeyeceği anlamına
gelmez.Kısaca özetlersek,bütün yazımlıcılar,yazılımın her aşamasında bulunurlar.
- Yazılım parçaları sürekli entegre biçimde tutulur.
Bir .NET yazılımında Visual Source Safe kullanıyor isek,ilgilendiğimiz
bir formu,dosyayı,kodu check out ettikten sonra, üzerinde değişiklikler yapıp,test
kodlarını yazıp derleriz.Eğer sorunsuz bir şekilde çalıştığından emin olduğumuzda
check in eder,test server’a yükleriz.Tabi bu web uygulamaları için geçerlidir.Böylelikle
proje sürekli genişleyen ve bütünleşik bir yapıya sahip olur.Bir musluktan damla
damla su akar gibi kodlar client yazılımcılardan server’a sürekli akar böylelikle
sürekli bütünleşme sağlanır.Belli ve sık aralıklarla projenin tamamı derlenir,çalıştırılır
ve test edilir.Bir web uygulaması ise server’a projemizin tamamını yükleyebileceğimiz
gibi,Windows Forms uygumaları ise bu durumda da Setup dosyası veya bir CD’ye proje
aktarılmalıdır.
- Yazılım, hızlı değil güvenli ve emin adımlarla gerçekleştirilir.
Bir yazılım projesinde yazılımcıların yarınki enerjileri bugünden
çalınmamalıdır.Yazılımcılar yarış atları gibi hızlı bir şekilde koşturulmamalıdır.Hızlı
bir şekilde giden yazılımcının yazacağı kodlar hata üretmeye çok müsaittir.Hatanında
yanında karmaşık ve anlaşılması çok zor olan kodlar ortaya çıkması muhtemeldir.Hızlı
ve uzun süreli bir şekilde yazılım yapmak yerine emin adımlarla,olması gereken düzeyde
yazılıma devam edilmelidir.Böyle yapılan yazılımlar üzerinde sakin kafayla,uzun
uzun düşünülen,tutarlı ve sağlam olmaktadırlar.Yazılım yöneticileri yazılımcıların
geceli gündüzlü çalışarak daha çabuk bir şekilde proje ortaya çıkarabileceklerini
düşünseler de,yazılım ortaya erken çıksa da,uzun süreçte o yazılımın başarısız olma
ihtimali çok yüksektir.Hatta zamanında bitirilmesi çok kolay olan yazılımlarda bile,
hızlı gidildiğinden dolayı aceleye gelen,yanlış yazılan, silinip silinip tekrardan
yazılan yazılımlar ortaya çıkmakta, bu da teslim süresini uzatmakta, kaliteyi azaltmaktadır.
- XP takımı aynı fiziksel ortamda bulunur.
Yazılımcılar ayrı ayrı odalarda değil,hepsi bir odada ve birbirlerini
görecek ve duyacak mesafede olmalıdırlar.Böylelikle hem takım içerisindeki bütünleşme
sağlanmış olur hemde bir kişinin diğer tüm takım arkadaşlarından haberdar olması
sağlanır.Biri, bir problemle karşılaştığı an vakit kaybetmeden bunu takım arkadaşlarıyla
paylaşabilirler.Bizler biliyoruz ki,birlikte yapılan işlerde motivasyon son derece
artmaktadır.Böyle bir ortamda,kendini yazılıma vermiş ekibin,birlik olarak her türlü
işin üstesinden gelebileceğine inanıyorum. Tabi böyle bir ortamda,yazılım ekibindeki
herkes diğer arkadaşlarına karşı saygılı olmalı ve onları rahatsız edici tutumlardan
kaçınmalıdırlar.Yazılımda müzik dinlemek bazı kişileri motive ediyor olsada, diğer
takım arkadaşlarını sürekli duyabilmesi ve ilgilenebilmesi açısından müzik dinlenecekse
bile beraber dinlenmesi gerektiğine inanıyorum.
- XP takımı kendine kod standartları belirler.
Bütün yazılım ekibinin kullandığı ortak bir kodlama standardı olmalıdır.XP’ye
göre takım içerisindeki herkes,diğer arkadaşlarının kodlarına müdahele edebileceği
için,diğer arkadaşların yazdığı kodları rahat bir şekilde anlayabilmeli,üzerinde
bir değişiklik yaptığında,kodu ilk yazan kişi,yeni kodu anlamakta zorlanmamalıdır.Bu
son derece önemlidir.Bu yüzden takım içerisinde her bir şey(değişken,sınıf,metod
vs. isimlendirmeleri,dökümantasyon yazma biçimi vs) için bir kod standardı yerleştirilmelidir.
- Tasarım olabildiğince basit tutulmalıdır.
XP projelerinde o an üzerinde çalışılan kullanıcı hikayelerine(user
stories) odaklanılır.İleride şöyle bir şeye ihtiyacımız olabilir,şurda şöyle bir
kod yazalım ki ileride zorluk çekmeyelim gibi düşünceler XP’de yer bulamaz.XP takımı
o an elinde bulunan işlere odaklanır,ileriyi düşünmez ve işini gören en basit kodu
yazar.Belki bir işi reflection yöntemiyle yapmak ileride örneğin 100 satır kod yazmamızı
engelleyecek olsa bile, bu yapılmaz onun yerine modüler olmayan en basit kod yazılır.İhtiyaç
duyuldukça kod üzerinde düzenlemeler yapılır.Bu durumda Refactoring, XP projelerinin
vazgeçilmez bir parçası haline gelir.Kısacası kod en basit haliyle sadece üzerinde
düşündüğümüz gereksinim üzerinden yazılır ve ilerisi düşünülmez.Olurda ileride benzer
kodlar yazmamız gerektiğinde bir düzenleme yapıp, kodlarımızı bir metod içerisine
alabiliriz veya bir sınıf içerisine alabiliriz.İlk bakışta ilginç ve yararsız bir
yöntem gibi gözüksede refactoring ile birleştiğinde anlamlı olabileceğini düşünüyorum.
XP projelerinin kod tekrarına tahammülü yoktur.Eğer bir kod tekrarı mevcut ise bu
durumda hemen refactoring ile kod düzenlenmeli ve bir defa yazılır hale getirilmelidir.
- XP’de Refactoring çok önemli bir yere sahiptir.
Özellikle büyük ve uzun süreli projelerde zaman içerisinde belkide
milyonlarca satır kod yazılmaktadır. Her ne kadar tecrübeli kişiler tarafından yazılıyor
olsada,kodların çoğalmasıyla birlikte kodların zaman içerisinde okunabilirliği azalmakta
karmaşıklığı artmaktadır.Bu durumda da,projeye yeni bir şey eklemek,problemi çözmek,
bakım yapmak zorlaşmaktadır.İşte tam bu noktada karşımıza refactoring kavramı çıkmaktadır.Bir
yazılımcı her an refactoring yaparak kod üzerinde düzenlemeler yaparak kodu iyileştirir.böylelikle
kodun kalitesi arttırılmaktadır. Tabi refactoring yaparken bir yandan da kodlar
sürekli test edilmektedir.Refactoring, yazılan kodun işleyişinde herhangi bir değişiklik
meydana getirmemelidir, sadece yapısal olarak düzenleme getirmelidir.
|
|
|