Archi
New member
- Katılım
- 22 Ocak 2006
- Mesajlar
- 15
- Reaction score
- 0
- Puanları
- 0
"GOTO İfadesi Zararlıdır" Edsger Dijkstra, 1968
Benim gibi siz de GOTO kullanarak yazılım dünyasına adım atanlardan mısınız bilmem ama 1968'den bu yana yazılım geliştirme süreçlerinde birçok yapısal gelişme olsa da herşeyi kuralına göre yapmanın da ne kadar zor olduğu açık bir gerçek. İşte bu yazımda size yazılım geliştirme aşamasında kullanabileceğiniz bir teknikten bahsetmek istiyorum: eXtreme Programlama.
Zaman "Çevik" Olma Zamanı
Internet merkezli çalışan yazılım projeleri 1992'lerde hayatımıza girmeye başlamıştır ve işin boyutu gerçekten değişmiştir. Bu tarih öncesine kadar ve hatta sonrasında yazılım projelerinde detaylı bir planlama için metodolojiler kullanılmış ama hepsi de sürekli değişen müşteri gereksinimleri, internetin akıl almaz hızlı değişime neden olması gibi sebeplerden dolayı tam olarak başarıyı sağlayamamıştır. Başarının sırrı hızlı olup, çabuk harekete geçebilmekte yani "çeviklik"te. İşte bu yüzden benim size aktaracağım XP'nin de temelinde yer alan ve Scrum, RUP, Cockburn's Crsytal Family gibi diğer çevik metotların da temel aldığı şu çeviklik bildirisi ortaya çıkmıştır:
XP nedir?
eXtreme Programlama kısaca XP; yazılım geliştirme süreçlerinde 4 temel yapıtaşı olan "Basitlik, İletişim, Geri Bildirim ve Cesaret" üzerine kurulu bir çevik metodolojidir. Çeviklik bildirisini temel alarak tasarlanan XP, 1990-1996 yılları arasında üç extremo olarak bilinen Ward Cunningham, Kent Beck, Ron Jeffries tarafından oluşturulmuştur.
Hangi Yazılım Değerlidir?
Düşünün elinizde bir yazılım var; çok karmaşık olarak düzenlenmiş, gerçekten büyük proje, içerisinde yok yok ama çok kompleks ve yönetimi de bir o kadar zor. Diğer tarafta ise basit olarak yazılmış, sadece istenilen işi yapan zarif bir kod var. Sizce hangi yazılım daha değerlidir? Şimdi şunu söyleyerek cevap cümlenize başlayabilirsiniz belki "Geleceği düşündüğümüzde...". Geleceği unutun, yok öyle birşey, henüz yazılmadı. Gelecekte lazım olur diye bu kadar hızlı değişen bir dünyada kod yazmanız hata olur. Bu yüzden XP basitlik üzerinde yoğun bir şekilde duruyor. Basitlik başlığına iletişim, cesaret ve geri beslemeyi de ekleyerek bize 12 tane pratik sunuyor.
XP'de planlama vardır, ama tahmin ettiğiniz kadar uzun uzadıya bir planlama değil. Müşteri ile biraraya gelinir ve bir planlama oyunu oynanır. Bu planlama oyununda amaç müşterinin asıl isteklerini tespit edebilmek ve bunu küçük hikaye kartlarına yazmaktır. Hikaye kartı dediğim bildiğiniz küçük kartlar, üzerine müşterinin istediği yazılımın çözmesi gereken problemleri yazıyor ve ardından bu çözüm için yazılması gereken kod çözümünden bahsediyorsunuz, bu kadar. Kartı müşteri yanında doldurduğunuz için müşterinin ayrıca bir onayına ihtiyaç duymadığınız için oldukça çevik bir yöntem ile planlamayı çözmüş oluyorsunuz. Ardından bu kartları isteklere göre bir sıraya sokup bir askıya asıyorsunuz. Askı dediğim şey aslında bize pek yabancı değil; ilkokulda hece fişlerini astığımız askı vardır ya, onun bir benzeri; artık büyüdük heceleri değil müşteriyle oluşturduğumuz hikaye kartlarını asıyoruz bu askıya.
Yapılan planlamada çıkan işler askıda yazılım gelişticileri bekliyor, yapıldıkça oradan alınıyor ve böylelikle ne kadar iş kaldığını kolayca görebiliyorsunuz.
Bir Elin Nesi Var, İki Elin Sesi Var
XP'nin en keyifli pratiklerinden biri ise eşle programlama (pair programming). İki yazılım geliştirici tek bir bilgisayar kullanıyorlar. İki ekran var ama tek bir klavye ve tek bir fare var. Bu yüzden biri yazarken diğeri arkada onu izliyor, en az 15 en fazla 45 dakika sonra yer değiştiriyorlar. Bu sefer az önce kod yazan izliyor, diğeri yazıyor. Şimdi düşünün bu sistemin faydalarını; önünüzde biri kod yazıyor ve siz onun yazdıklarını henüz yazım aşamasındayken görüyorsunuz; anında hata ayıklaması yapabilirsiniz, "Bu kodu neden böyle yazdın, şöyle yazsan daha iyi olmaz mıydı, sanki hatalı şuan?" Hatta daha da ileriye giderek: "Bence şunu yaparsan daha performanslı ve daha güvenli olmaz mı?". Önde oturup kod yazan kişi çıldırmamak için zor duruyor, arkasında biri sürekli onun yazdığı kodları izliyor ama 45 dakika geçmeden roller değişiyor. 45 dakikadır onun yazdığı kodda hata bulan kişi şimdi onun önünde ve aynı itinayı o da gösterip bir bir hataları buluyor. Eşle programlama XP'nin en önemli pratiklerinden, hata oranını azaltırken şirket içerisinde ortak bir kod mülkiyeti ortaya çıkarıyor. Çünkü artık kodu yazan ve bilen tek kişi yok, en az iki hatta birden fazla eşin çaprazlanmasıyla birçok kişi aynı koddan haberdar oluyor. Bu sayede yazılan kodlarda bir sorun çıktığında veya bir güncelleme yapılması gerektiğinde herkes bilgi sahibi olduğu için yine çevik bir aşama gerçekleştirilebiliyor.
Eşle programlamanın diğer güzel bir yanı ise yazılımcının verimini ve dolayısıyle firmanın verimliliğini arttırması. Şimdi gelelim XP'ye; sabah işe geldiniz ve arkanızda biri oturup sizin yaptıklarınızı izliyor; ne MSN, ne e.posta artık izleniyorsunuz, vakit kod yazma vaktidir. XP'de bulunan eşle programlama gerçekten yazılım geliştirme süreçlerinde verimliliği ve kaliteyi arttırır. Çünkü yazılan kod artık önce bir süzgeçten geçtiği için daha az yeniden yazılacak ve daha az hata verecektir.
Önce Test Kodu Sonra Program Kodu
XP'de önemli bir farklılık ise öncelikle test kodlarının yazılmasındadır. Çoğu zaman test program kodu yazıldıktan sonra yapılır bu yüzden testler uzun zaman alır ve yazılan kodlar tekrar tekrar elden geçirilir. Oysa XP'de öncelikle birim testleri (unit tests) için test kodları yazılır, böylece yazılımın ilerleyen aşamalarında bir değişiklik olduğunda hala eski kodun düzgün çalışıp çalışmadığı kolayca kontrol edilebilir. Ayrıca kabul edilebilirlik testleri ile de yapılan yazılımın uygunluğu sürekli kontrol edilir.
Çoğu projede müşteri derdini anlatır ama ürünü en sonunda görür. Özellikle şelale modelinin yaygın kullanıldığı projelerde müşteri en sonunda ürünü gördüğünde pek mutlu olmaz, çünkü istekleriyle uyuşmadığını görürse yapılan tüm iş çöpe gidebilir. Oysa XP'de geliştirmenin büyük bölümü müşteride yapılır; böylece müşteri takımın bir parçasıdır. Yazılan kodlar gün içerisinde ve gün sonunda küçük ara sürümler halinde bir test sunucusuna aktarılır, sürekli tümleştirme vardır, böylece hem müşteri çalışan yazılıma her zaman erişip durumu gözlemleyebilir hem de takımın tüm üyeleri yapılan işte nerede olduklarını fiziksel olarak kolayca görebilirler.
Basit Tasarla Ardından Yeniden Tasarla
Yazılım istekleri sürekli değiştiği için XP'de önce basit tasarlar ve ürünü ortaya çıkarırsınız. Bunu yapabilmek için eşle programlama ve müşterinin de takımın bir parçası olması sayesinde bir yazılım geliştirici 40 saat/hafta gibi verimli bir zamana ulaşacaktır. İlk sürümler ortaya çıktıktan sonra yeniden tasarım (refactoring) gerçekleşecektir. Yeni istekler, güncellemeler, eski sürümde bilinen ama kabul edilmiş hatalar artık bu yeniden tasarım sonrasında yapılacaktır. XP döngüsü yeniden başlar. Böylece bir sistem metaforu yazılım geliştirme aşamasında oluşmuş olacaktır. Sonucunda ortaya istekleri dinlendiği ve yapıldığı için mutlu bir müşteri; yazdığı kodlarda ortak kod mülkiyetiyle, daha az hatalı ve sistemli bir kod yazdığı için mutlu bir yazılım geliştirici; ve proje başarıyla bittiği için mutlu olan bir proje yöneticisi olacaktır.
Ne Zaman XP?
XP'yi her yazılım projesinde uygulamanızı tavsiye etmem. Özellikle gereksinimleri değişken problemlerde, firmanın ne istediğini bilmediği projelerde XP uygulamak mantıklı olacaktır. Ayrıca işlevselliğin birkaç ayda değiştiği projelerde XP uygulamak çevik kalmayı sağlayacaktır. Yazılım ekibiniz 2 - 10 kişi arasındaysa XP mantıklıdır, daha kalabalık ekiplerde XP uygulamak zorlaşacaktır.
Ayrıca XP risklerin yüksek olduğu projelerde uygulanmalıdır. Örneğin bir tarih kısıtlaması varsa, yazılacak proje yazılım ekibinin daha önce yazmadığı bir alanda ise veya yazılımın yapılacağı sektör için çok yeni bir yazılım projesi ise riskler yüksek olacağı için XP kullanmak çok doğru bir hareket olacaktır. Yazılım ekibinde müşteri ve yöneticiler de aktif yer aldığı için projenin kapsamı sürekli kontrol altında kalacaktır ve neler olduğundan herkes anında haberdar olacaktır. Testler sayesinde ise kalite artacak daha sonra yapılacak değişikliklerin maliyeti çok daha düşük olacaktır.
Eğer Bir Yerlerden başlamak istiyorsanız hadi başlayalım
Benim gibi siz de GOTO kullanarak yazılım dünyasına adım atanlardan mısınız bilmem ama 1968'den bu yana yazılım geliştirme süreçlerinde birçok yapısal gelişme olsa da herşeyi kuralına göre yapmanın da ne kadar zor olduğu açık bir gerçek. İşte bu yazımda size yazılım geliştirme aşamasında kullanabileceğiniz bir teknikten bahsetmek istiyorum: eXtreme Programlama.
Zaman "Çevik" Olma Zamanı
Internet merkezli çalışan yazılım projeleri 1992'lerde hayatımıza girmeye başlamıştır ve işin boyutu gerçekten değişmiştir. Bu tarih öncesine kadar ve hatta sonrasında yazılım projelerinde detaylı bir planlama için metodolojiler kullanılmış ama hepsi de sürekli değişen müşteri gereksinimleri, internetin akıl almaz hızlı değişime neden olması gibi sebeplerden dolayı tam olarak başarıyı sağlayamamıştır. Başarının sırrı hızlı olup, çabuk harekete geçebilmekte yani "çeviklik"te. İşte bu yüzden benim size aktaracağım XP'nin de temelinde yer alan ve Scrum, RUP, Cockburn's Crsytal Family gibi diğer çevik metotların da temel aldığı şu çeviklik bildirisi ortaya çıkmıştır:
Kod:
Çeviklik Bildirisi (Agile Manifesto):
- İşlevlerden ve araçlardan önce bireyler ve iletişim gelir.
- Detaylı dökümantasyondan önce çalışan yazılım gelir.
- Sözleşme görüşmelerinden önce müşteri etkileşimi gelir.
- Bir planı izlemekten önce değişikliklere cevap verebilmek gelir.eXtreme Programlama kısaca XP; yazılım geliştirme süreçlerinde 4 temel yapıtaşı olan "Basitlik, İletişim, Geri Bildirim ve Cesaret" üzerine kurulu bir çevik metodolojidir. Çeviklik bildirisini temel alarak tasarlanan XP, 1990-1996 yılları arasında üç extremo olarak bilinen Ward Cunningham, Kent Beck, Ron Jeffries tarafından oluşturulmuştur.
Hangi Yazılım Değerlidir?
Düşünün elinizde bir yazılım var; çok karmaşık olarak düzenlenmiş, gerçekten büyük proje, içerisinde yok yok ama çok kompleks ve yönetimi de bir o kadar zor. Diğer tarafta ise basit olarak yazılmış, sadece istenilen işi yapan zarif bir kod var. Sizce hangi yazılım daha değerlidir? Şimdi şunu söyleyerek cevap cümlenize başlayabilirsiniz belki "Geleceği düşündüğümüzde...". Geleceği unutun, yok öyle birşey, henüz yazılmadı. Gelecekte lazım olur diye bu kadar hızlı değişen bir dünyada kod yazmanız hata olur. Bu yüzden XP basitlik üzerinde yoğun bir şekilde duruyor. Basitlik başlığına iletişim, cesaret ve geri beslemeyi de ekleyerek bize 12 tane pratik sunuyor.
Kod:
[B]12 XP Pratiği:[/B]
- Planlama Oyunu
- Küçük ve kısa aralıklı sürümler
- Sistem metaforu
- Basit tasarım
- Test
- Yeniden tasarım
- Eşle Programlama
- Ortak Kod Sahipliği
- Sürekli Tümleştirme
- 40 saat/hafta
- Müşteride geliştirme
- Kodlama StandartlarıXP'de planlama vardır, ama tahmin ettiğiniz kadar uzun uzadıya bir planlama değil. Müşteri ile biraraya gelinir ve bir planlama oyunu oynanır. Bu planlama oyununda amaç müşterinin asıl isteklerini tespit edebilmek ve bunu küçük hikaye kartlarına yazmaktır. Hikaye kartı dediğim bildiğiniz küçük kartlar, üzerine müşterinin istediği yazılımın çözmesi gereken problemleri yazıyor ve ardından bu çözüm için yazılması gereken kod çözümünden bahsediyorsunuz, bu kadar. Kartı müşteri yanında doldurduğunuz için müşterinin ayrıca bir onayına ihtiyaç duymadığınız için oldukça çevik bir yöntem ile planlamayı çözmüş oluyorsunuz. Ardından bu kartları isteklere göre bir sıraya sokup bir askıya asıyorsunuz. Askı dediğim şey aslında bize pek yabancı değil; ilkokulda hece fişlerini astığımız askı vardır ya, onun bir benzeri; artık büyüdük heceleri değil müşteriyle oluşturduğumuz hikaye kartlarını asıyoruz bu askıya.
Yapılan planlamada çıkan işler askıda yazılım gelişticileri bekliyor, yapıldıkça oradan alınıyor ve böylelikle ne kadar iş kaldığını kolayca görebiliyorsunuz.
Bir Elin Nesi Var, İki Elin Sesi Var
XP'nin en keyifli pratiklerinden biri ise eşle programlama (pair programming). İki yazılım geliştirici tek bir bilgisayar kullanıyorlar. İki ekran var ama tek bir klavye ve tek bir fare var. Bu yüzden biri yazarken diğeri arkada onu izliyor, en az 15 en fazla 45 dakika sonra yer değiştiriyorlar. Bu sefer az önce kod yazan izliyor, diğeri yazıyor. Şimdi düşünün bu sistemin faydalarını; önünüzde biri kod yazıyor ve siz onun yazdıklarını henüz yazım aşamasındayken görüyorsunuz; anında hata ayıklaması yapabilirsiniz, "Bu kodu neden böyle yazdın, şöyle yazsan daha iyi olmaz mıydı, sanki hatalı şuan?" Hatta daha da ileriye giderek: "Bence şunu yaparsan daha performanslı ve daha güvenli olmaz mı?". Önde oturup kod yazan kişi çıldırmamak için zor duruyor, arkasında biri sürekli onun yazdığı kodları izliyor ama 45 dakika geçmeden roller değişiyor. 45 dakikadır onun yazdığı kodda hata bulan kişi şimdi onun önünde ve aynı itinayı o da gösterip bir bir hataları buluyor. Eşle programlama XP'nin en önemli pratiklerinden, hata oranını azaltırken şirket içerisinde ortak bir kod mülkiyeti ortaya çıkarıyor. Çünkü artık kodu yazan ve bilen tek kişi yok, en az iki hatta birden fazla eşin çaprazlanmasıyla birçok kişi aynı koddan haberdar oluyor. Bu sayede yazılan kodlarda bir sorun çıktığında veya bir güncelleme yapılması gerektiğinde herkes bilgi sahibi olduğu için yine çevik bir aşama gerçekleştirilebiliyor.
Eşle programlamanın diğer güzel bir yanı ise yazılımcının verimini ve dolayısıyle firmanın verimliliğini arttırması. Şimdi gelelim XP'ye; sabah işe geldiniz ve arkanızda biri oturup sizin yaptıklarınızı izliyor; ne MSN, ne e.posta artık izleniyorsunuz, vakit kod yazma vaktidir. XP'de bulunan eşle programlama gerçekten yazılım geliştirme süreçlerinde verimliliği ve kaliteyi arttırır. Çünkü yazılan kod artık önce bir süzgeçten geçtiği için daha az yeniden yazılacak ve daha az hata verecektir.
Önce Test Kodu Sonra Program Kodu
XP'de önemli bir farklılık ise öncelikle test kodlarının yazılmasındadır. Çoğu zaman test program kodu yazıldıktan sonra yapılır bu yüzden testler uzun zaman alır ve yazılan kodlar tekrar tekrar elden geçirilir. Oysa XP'de öncelikle birim testleri (unit tests) için test kodları yazılır, böylece yazılımın ilerleyen aşamalarında bir değişiklik olduğunda hala eski kodun düzgün çalışıp çalışmadığı kolayca kontrol edilebilir. Ayrıca kabul edilebilirlik testleri ile de yapılan yazılımın uygunluğu sürekli kontrol edilir.
Çoğu projede müşteri derdini anlatır ama ürünü en sonunda görür. Özellikle şelale modelinin yaygın kullanıldığı projelerde müşteri en sonunda ürünü gördüğünde pek mutlu olmaz, çünkü istekleriyle uyuşmadığını görürse yapılan tüm iş çöpe gidebilir. Oysa XP'de geliştirmenin büyük bölümü müşteride yapılır; böylece müşteri takımın bir parçasıdır. Yazılan kodlar gün içerisinde ve gün sonunda küçük ara sürümler halinde bir test sunucusuna aktarılır, sürekli tümleştirme vardır, böylece hem müşteri çalışan yazılıma her zaman erişip durumu gözlemleyebilir hem de takımın tüm üyeleri yapılan işte nerede olduklarını fiziksel olarak kolayca görebilirler.
Basit Tasarla Ardından Yeniden Tasarla
Yazılım istekleri sürekli değiştiği için XP'de önce basit tasarlar ve ürünü ortaya çıkarırsınız. Bunu yapabilmek için eşle programlama ve müşterinin de takımın bir parçası olması sayesinde bir yazılım geliştirici 40 saat/hafta gibi verimli bir zamana ulaşacaktır. İlk sürümler ortaya çıktıktan sonra yeniden tasarım (refactoring) gerçekleşecektir. Yeni istekler, güncellemeler, eski sürümde bilinen ama kabul edilmiş hatalar artık bu yeniden tasarım sonrasında yapılacaktır. XP döngüsü yeniden başlar. Böylece bir sistem metaforu yazılım geliştirme aşamasında oluşmuş olacaktır. Sonucunda ortaya istekleri dinlendiği ve yapıldığı için mutlu bir müşteri; yazdığı kodlarda ortak kod mülkiyetiyle, daha az hatalı ve sistemli bir kod yazdığı için mutlu bir yazılım geliştirici; ve proje başarıyla bittiği için mutlu olan bir proje yöneticisi olacaktır.
Ne Zaman XP?
XP'yi her yazılım projesinde uygulamanızı tavsiye etmem. Özellikle gereksinimleri değişken problemlerde, firmanın ne istediğini bilmediği projelerde XP uygulamak mantıklı olacaktır. Ayrıca işlevselliğin birkaç ayda değiştiği projelerde XP uygulamak çevik kalmayı sağlayacaktır. Yazılım ekibiniz 2 - 10 kişi arasındaysa XP mantıklıdır, daha kalabalık ekiplerde XP uygulamak zorlaşacaktır.
Ayrıca XP risklerin yüksek olduğu projelerde uygulanmalıdır. Örneğin bir tarih kısıtlaması varsa, yazılacak proje yazılım ekibinin daha önce yazmadığı bir alanda ise veya yazılımın yapılacağı sektör için çok yeni bir yazılım projesi ise riskler yüksek olacağı için XP kullanmak çok doğru bir hareket olacaktır. Yazılım ekibinde müşteri ve yöneticiler de aktif yer aldığı için projenin kapsamı sürekli kontrol altında kalacaktır ve neler olduğundan herkes anında haberdar olacaktır. Testler sayesinde ise kalite artacak daha sonra yapılacak değişikliklerin maliyeti çok daha düşük olacaktır.
Eğer Bir Yerlerden başlamak istiyorsanız hadi başlayalım