Forum
Aktif konular
Üyeler
Kurallar
Arama
Extreme Programlama Nedir? Extreme Programlama Nedir?
-
Extreme programlama basitlik, komünikasyon, feedback ve cesaretlendirme(gaza getirme) değerleri üzerine kurulmuş bir yazılım geliştirme disiplinidir. Bu disiplinde bir takım çalışması söz konusudur(iletişim değerleri). Takımın her bir üyesi ufak tefek işler yapar(basitlik değerleri). Bu takıma yeterli bir feedback sağlanmasıyla da takım kendi çalışmasının nerede olduğunu görebilir(feedback değerleri) ve hızlarını duruma uygun olarak ayarlayabilir.
Tüm takım
Extreme programlamada, projeye katkısı olan her birey takımın bir parçası sayılır. Takım “Müşteri” nin çevresindeki ve etkileşimde bulunduğu bireylerden oluşur. Müşteri takım ile birlikte günaşırı çalışır.
Planlama, Küçük Release’ ler, Müşteri Testleri
Extreme programlama nelerin yapıldığı ve nelerin yapılacağı ile ilgili basit bir planlama ve takip sistemi kullanır. Temel işler üzerine odaklanılarak, takım, müşterinin tanımladığı tüm testlerden geçen tamamen sistemle entegre ufak release’ ler ortaya koyar.
Basit tasarım, Eşli programlama, Test-tabanlı geliştirme, Tasarım iyileştirme
Extreme programcıları bir grup halinde ya da ikişerli gruplar halinde çalışırlar. Basitten karmaşık tasarıma doğru zaman içinde testler yapılarak gidilir. İhtiyaçlara göre tasarım zaman geçtikçe iyileştirilir.
Devamlı entagrasyon, Kollektif kod sahipliği, Kodlama standardı
Extreme programlama sistemi entegre tutarak devamlı çalışmasını muhafaza eder. Programcılar tüm kodları çiftler halinde yazarlar, tüm işleri hep beraber yaparlar. Kodlama yaparken belli bir düzene uyarlar. Dolayısıyla takımın her bir üyesi her kodu anlama ve geliştirme olanağına sahiptir.
Sağlam Hız, Ortak Vizyon
Extreme programlamada takım sistemin ileride neye benzeyeceği ile ilgili olarak genel bir görüş orataya koyar. Herkes belirsiz olarak korunan bir hızda çalışır.
Temel Kavramlar
Tüm takım
XP projelerine katkısı olan herkes takımın birer üyesidir ve birlikte çalışırlar. Bu takımda bir iş temsilcisi--Müşteri olmalıdır. Bu iş temsilcisi namı diğer müşteri gereksinimleri otaya koyar, öncelikleri tanımlar ve projeyi yönetir. Müşteri olayı ne kadar iyi bilirse o kadar iyi olur. Takımda tabii ki programcılarda olacaktır. Bu takımda tester’lar olabilir. Bu testerlar müşteri ile geçilmesi veya aşılması gereken testleri belirler. Analistler müşteri’ ye gereksinimleri belirlemek noktasında yardım ederler. Genel olarak takımda bir koç vardır. Bu koç projenin takibini yapar ve hangi işlerin yapılması gerektiğini ortaya koyar. Ayrıca bir yönetici olabilir. Bu yönetici kaynakları temin eder, irtibat kurulması gerekli işleri yapar, aktivitelerin koordinasyonunu gerçekleştiririr. Aslında bu işlerin hiç birisi bir kişinin tek başına yapması zorunlu işler değildir. XP takımında yer alan her kişi yapabildikleri ölçüsünde birşeyler yapar. En iyi takımda uzman hiç yoktur, sadece özel yetenekleri olan kişiler vardır.
Oyunu Planlama
XP’ de planlama, yazılım geliştirmede çok önemli iki unsur üzerine göre şekillenir. Bunlar nelerin hangi tarihle bitirileceğini tahmin etmek ve ondan sonra hangi işlerin yapılması gerektiğine karar vermektir. Planlamada önemli olan projenin plana bağlı olarak yürümesidir. Ancak bu planlamadaki herşey gerçeğe uymayabilir. Çünkü neye ihtiyacımız olacağı ve ne kadar zaman alabileceğini kestirmek gerçekten güçtür. XP’ de planlama yaparken bu iki soruya cevap aranarak plan oluşturulur.
Plan oluşturma, müşterinin isteklerini programcıya sunduğu ve programcıların da onların zorluk derecelerini belirlediği bir aktivitedir. Elde bulunan maliyet tahminleri ve geliştirilecek programın özelliklerinin önem dereceleri bilgileri ile, müşteri proje planını şekillendirir. İlk başta elde edilen planlar gerçekten çok etksizdirler. Çünkü işe gerçek manada başlayana kadar işlerin öncelikleri ve maliyetleri ile ilgili bilgiler tam olarak belli değildir. Ancak buna rağmen oluşturulan ilk plan bazı kararları vermek için yeterli sayılabilir. Bundan sonrada belirli peryotlarla da plan güncel tutulur.
İteratif planlama, takımın her 2 haftada bir yeni bir şey üzerinde çalışması üzerine kurulu bir planlamadır. XP takımları iki haftalık peryotlarla programı build(compile) ederler. Sonuç olarak iki haftada bir yeni özellikler eklenmiş faydalı programlar elde edilir. İteratif planlamada müşteri her zaman bir sonraki 2 haftalık peryotta neler yapılması gerektiğini belirtir. Belirtilen bu isteklere göre programcılar görevleri ve alt görevleri oluştururlar ve onların maliyetlerini tahmin ederler. Bu son özellik Plan oluşturma’ da söylenenlerden bir parça daha ayrıntılıdır. Bir önceki iterasyonda ne kadar bir başarı sağlanmış olduğuna bakılarak, takım hangi işlerin bu iterasyonda yapılması gerektiğine karar verir.
Bu planlar çok basit olmalarına rağmen müşterilerin sağladıkları bilgiler ve projeyi mükemmel bir şekilde yönetmeleri(sürdürmeleri) yönüyle çok iyidirler. Her iki haftada bir yapılan işler herkes tarafından kolay görülebilir, anlaşılabilir durumdadır. XP’ de “yüzde doksanı tamam” diye bir tabir yoktur. İstenen özellik ya yapılmıştır ya da yapılmamıştır. Meselelerin herkes tarafından görülebilmesi anlaşılması bazı paradokslara neden olur. Bir yanda, bu mesele iyi gerçekleştirilmiştir ve müşteri işin yeterli olmadığını bu yüzden anlayabilirse projeyi iptal edebilir. Bir yanda da iş herkes tarafından çok iyi anlaşılmıştır, bir sonraki zaman diliminde yani namı diğer 2 haftalık peryotta neler yapılacağı belirlidir. Bu yüzden de XP projeleri daha az stres ve baskı ile ihtiyaç duyulandan çok fazlasını sunabilecektir.
Müşteri Testleri
Müşteri istediği her özelliği belirtmekle aslında bir takım testleri de ortaya koymuş oluyor. Bu testlere müşteri kabul testleri adını verebiliriz. Çünkü müşteri programda olması gereken bir özelliği dile getiriyor bizler de bu özelliğin yerine gelip gelmediğini bunun testini gerçekleştirerek karar veriyoruz. Bu testler hem geliştiricileri hem de müşterilerin onayından geçiyor. Otomasyon içinde yaşadığımız zaman baskılı ortamda önemli bir meseledir. Bu yüzden manuel olarak test yapmaktansa bu şekilde işleri otomatikleştirerek test yapmak çok daha hızlı sonuç almamızı sağlar. Bu gece en karanlık noktasına ulaştığında ışıkları kapatmaya benzer.
En iyi XP takımları testleri kendileri hazırladıkları gibi onların çalıştırılmasını da kendileri gerçekleştirir. Takım, test çalışmaya başlayınca sonuç alınıncaya kadar testin doğru çalıştırılmasından sorumludur.
Küçük Release’ler (Versiyonlar)
XP takımları iki yolla küçük relese’ ler elde eder.
Birincisi, takım herbir iterasyonda müşteri tarafından seçilen değerlere ve özelliklere göre test edilmiş, çalışan release’ ler oluşturur. Müşteri oluşturulan evaluation(deneme sürümü) ya da son kullanıcılara yönelik bu yazılımı herhangi bir amaç için kullanabilir. Burada en önemli şey, yazılımın her iterasyon sonunda oluşturulan bu release’ lerinin müşteri tarafından kolay anlaşılabilir olmasıdır. Müşterinin herhangi bir release ile ilgili olarak kafasında en ufak bir soru işareti bulunmamalıdır. Bu özellik her şeyin açık ve meselelerin kolay handle edilebilmesini sağlar.
İkincisi, XP takımları, son kullanıcılara ellerinden geldiği kadar sık aralıklarla release oluştururlar. XP web projelerinin günlük bazda release’ i oluşturulur, daha kapsamlı projelerde ise aylık ya da daha kısa aralıklarla release oluşturulabilir. Bunlardan daha küçük yapılı projelerde bile en azından üç ayda bir release oluşturulmalıdır. Yani projenin önem derecesi ve büyüklüğü arttıkça relese oluşturma sıklığı doğru orantılı bir şekilde artmaktadır. Ne kadar büyük proje o kadar çok release demek oluyor bir bakıma.
İyi versiyonlar oluşturmak imkansız görülebilir. Ancak meseleye şu açıdan bakılırsa daha iyi bir yorum getirilebilir. XP takımlarındaki herkes aynı zaman diliminde bununla uğraşmaktadırlar. Yani XP takımında yer alan bir birey bir işi sadece kendi takımının uğraşmadığının bilinci içerisindedir. Dolaysıyla ümütsizliğe kapılmaz. Ayrıca bu şekilde her zaman versiyon oluşturulacağının da bilinci içerisindedir. Dolayısıyla bu versiyon belki kötü olabilir ama bundan sonraki versiyon “İnşallah” daha iyi olacaktır diyerek meseleye bakabilir. Bu konu hakkında daha detaylı bilgi için “Devamlı Entegrasyon” bölümüne gözatabilirsiniz. Şunu unutmayın: Oluşturulan bu ufak versiyonlar ya da release’ ler her zaman müşteri testlerinden(test tabanlı yazılım geliştirme) geçtikleri için, XP takımı bu release’ leri sürekli güvenilir olarak kabul edecektir.
Basit Tasarım
XP takımları projeleri gerçekleştirirken basit tasarımlar kullanır. Basit bir tasarımla işe başlanır ve çeşitli programcı testlerinden ve tasarım geliştirmeden sonra da bu basit tasarım korunur. XP takımı tasarımı sadece ihiyaç duyulan özelliklere göre şekillendirir. Eğer daha sonra olması istenen bir özellik varsa onun tasarımı daha sonra yapılır. Hiçbir şekilde boşa atılmış bir adım yoktur. İhtiyaçlar neyse tasarımda o şekildedir. Yazılım her zaman bir sonraki yapılandırılma ya da versiyon değişimi için hazırdır.
XP’ de tasarım sadece bir kez yapılıp bir köşede saklanmaz. Yazılım geliştirildiği müddetçe tasarımda geliştirilir. Release planlama’ da ve iteratif planlama’ da tasarım adımları belirlenir. Ancak bu plana rağmen takım hızlı tasarım çalışmaları yapar ve tasarım gözden geçirmeleri ile ilgili toplantılar yapar. Extreme programlama gibi artımlı ve iteratif yazılım geliştirme metodolojilerinde iyi tasarım her zaman gereklidir. İşte bu nedenden dolayı XP’ de tüm yazılım geliştirme sürecinde tasarım yapılır ya da daha doğrusu vardır.
Eşli Programlama
XP’ de tüm yazılım eşli(aynı makine karşısında yan yana oturan iki kişi) gruplar halinde yapılır. Bu yaklaşım yazılan her kodun başka kodu yazan kişinin dışında başka birisi tarafından da kontrol edilmesini sağlar. Ve sonuç olarak daha iyi tasarım, daha iyi test etme ve daha iyi kod ortaya çıkar.
İki kişinin, bir programcının yapması gereken bir işle uğraşması belki verimsiz gibi görünebilir ama bu doğru değildir. Aslında bu daha verimlidir. Bu konuda yapılan akademik çalışmalarda bir kodun iki kişi tarafından yazılmasının, bir kişi tarafından yazılmasından daha iyi sonuçlar ortaya çıkardığını göstermiştir. Gerçekten şu söz çok doğrudur: 2 düşünen baş bir düşünen baştan daha iyidir.
Bazı programcılar hiç denemeden eşli programlamaya karşı çıkarlar. Aslında bu çalışmayı birkaç hafta denerlerse sonuçlarını göreceklerdir. Eşli programlamayı öğrenen programcıların %90’ ı bu şekilde çalışmayı terecih etmektedirler.
Eşli programlama daha iyi kod yazımını sağladığı gibi takım içerisindeki iletişimi de geliştirir. Eşler arasında değiş-tokuş ta bir kişini diğer kişilerin bilgi birikiminden yararlanmasını sağlar. Programcılar yeni şeyler öğrenirler, yeteneklerini geliştirirler ve artık takım için değerli bir eleman olurlar. Eşli kod yazma herkes için büyük bir kazançtır.
Test Tabanlı Geliştirme
Extreme programlamanın en büyük özelliklerinden birisi de feedback ‘ in iyi sağlanmasıdır. Ancak biliyoruz ki iyi feedback ancak iyi testlerle elde edilen bir sonuçtur. İyi XP takımları test tabanlı yaklaşımı seçerler. Bu yaklaşımda yeni testler kısa çalışmların ardından hazırlanır ve çalıştırılır. Hemen hemen kodun yüzde yüzüne yakın bir kısmı fazla efor sarfetmeden test edilir.
Testleri yazmak yeterli değildir: Onları çalıştırmakta zorundasınız. İşte bu extreme programlamanın gerçekten extreme(aşırı) olduğunu gösteren bir uygulamadır. Bu programcı testleri ve birim testleri bir araya getirilerek, her bir yeni release oluşturulduğunda, programcıların oluşturduğu her bir testin çalıştırılması sağlanır. Tüm testlerin %100’ ü gerçekleştirilir. Bu şu anlama gelir : programcıların yaptıkları iş ile ilgili tüm feedback’ lerin anında alınması sağlanır. Ek olarak bu testlerin gerçekleştirilmesi tasarımın geliştirilmesine katkı sağlamaz.
Tasarım Geliştirme
Extreme programlama gerçekleştirilen her bir iterasyonun iş açısından önemli bir değer(iş açısından yeni özellikler eklenmiş, performansı iyileştirilmiş vb. Bunun gibi değerler) taşımasını sağlar. Bunu gerçekleştirebilmek için ise yazılımın iyi tasarlanmış olması gerekir. Bunun alternatifi belki biraz daha yavaş ve sizi sonuca götürmeyecek yapıda olabilir. Bundan dolayı da XP devamlı tasarım iyileştirmesi anlamına gelen ve Martin Fowler’ ın “Refactoring: Improving the Design of Existing Code” adlı kitabında geçen “Refactoring” yapısını kullanır. Refactoring süreci kod tekrarlarını oratadan kaldırmayı, modül için bağlılığı(kohezyon) güçlendirip, modüller arası bağlılığı(coupling) zayıflatma üzerine odaklanır. Yüksek cohesion ve zayıf coupling son 30 yıldır iyi tasarımın göstergelerinden en önemlileri olarak kabul edilmektedir. Sonuç olarak, Xp takımları iyi ve basit bir tasarımla işe başlarlar ve her zaman tasarımın yazılım için basit ve iyi olmasını sağlarlar. Bu onların hızının istikrarlı olarak korunmasını sağlar, hatta ve hatta proje ilerledikçe hızın artışını bile sağlarlar.
Refactoring, tabii ki, zaman ilerledikçe tasarım değiştikçe hiç bir şeyin sonradan bir zarara yol açmaması için , güçlü testlerle desteklenir. Müşteri testleri ve programcı testleri aşılması gereken en önemli testlerdir. XP çalışmaları her birisini destekler: onların ayrı ayrı incelenmesi, test edilmesi, birlikte test edilmesinden daha az etkilidir, bunu unutmamak gerekir. Yani müşteri testleri ile programcı testleri birlikte değerlendirilirse sinerji oluştururlar.
Devamlı Entegrasyon
Extreme programlama takımları sistemin her zaman bir bütün(fully-Integrated) olmasını sağlar. Bu yüzden belki günde 1 kez gerçekleştirilen build’ ler bile yetersiz olabilir. Gün içinde birkaç kez bunu yapmak gerekebilir. Şöyle bir örnek verebiliriz : 40 kişilik bir XP takımı günde en az 8 ya da 10 kez build yapar.
Bu şekilde çalışmayan proje geliştirmelerinde haftalarca sistem entegre edilememiştir. Sonra da hep beraber derler “haydi arkadaşlar build yapalım. Yeni bir versiyon çıkaralım”. Sorunlarda bundan sonra başlar. Sistem build edilemez ve kimse nedenini de anlayamaz. İşte XP’ deki bu çalışmanın en büyük yararlarından birisi de bu tarz sorunların yaşanmasını engellemektir.
Seyrek aralıklarla yapılan entegrasyon=bütünleştirme çalışmaları yazılım projesi üzerinde çeşitli problemlere neden olurlar. Bunlardan ilki, kritik önem taşımasına rağmen bütünleştirme çalışması son ana kadar yapılmamıştır ve takım bu konuda hiç bir tecrübeye sahip olmadan ya da pratik yapmadan böyle bir çalışmanın içine girmiştir. Bu işin son anda yapılabilme olasılığı gerçekten çok azdır. İkincisi, seyrek aralıklarla birleştirilen kodlar – genellikle olduğunu söyleyebilirim - daha fazla hata içerir. Problemler tasarım zamanında entegre olmayan sistemin test edilmemesinden dolayı bulunamaz ve sisteme sessizce yerleşirler. Üçüncüsü, zayıf entegrasyon süreci uzun süre “kod değişmemezliği”ne neden olur. Kod değişmemezliği kısaca şöyle açıklanabilir. Uzun bir süre gerçekten uygulamanız açısından kritik öneme haiz program özellikleri üzerinde çalıştınız ve bitirdiniz diyelim ama en sonunda bu özelliği sisteme entegre etmeniz ve diğer modüllerle birlikte uyum içinde çalıştırımasını sağlamanız gerekir. Bu da ek zaman gerektirir. Sonuç olarak, pazardaki ya da son kullanıcılarınızla olan konumunuz zayıflar.
Kollektif Kod Sahipliği
Bir extreme programlama projesinde yer alan herhangi bir programcı herhangi birisinin yazdığı kodu her zaman geliştirebilir. Bu yazılan her kodun herkesin dikkatini çekmesini ve sonuç olarak daha kaliteli ve daha az hatalı kod üretilmesi anlamına gelir. Diğer bir önemli yarar : her kodun bir sahibi olduğunu düşünelim. Bu durumda kullanıcılardan birisi bir kod yazarken başka birisinin sorumluluğunda olan bir yerin yapılmasını bekleyebilir. Bu bekleme zamanı içerisinde de belki hiç birşey yapılmayabilir. İşte böyle durumlarda XP’ nin önerdiği yapı bize beklememeyi, istenen ya da gereksinim duyulan bir şey hazır değilse ve orası da senin sorumluluğunda değilse bile senin hazır olmayan yapıyla ilgili kod yazma serbestliğini verir. Böyle olmasaydı, o kodu hazırmış gibi düşünüp kendi sorumluluk alanımıza ekleseydik, bu sefer de birden fazla aynı kodun kopyası olacaktı. Bakım zorlaşacaktı. Modül içi bağlılık (cohesion) az olacaktı.
Bu tarz kod yazımında dikkat edilmesi gereken en önemli noktalardan birisi de anlamadığınız kod üzerinde değişiklikleri körü körüne yapmamanızdır. XP, bu problemin ortaya çıkmaması için iki teknik üzerinde odaklanır: Programcı testleri hataları yakalayabilir ve eşli programlama ‘ da tanıdık olmayan kodların biraz daha anlaşılmasını sağlar. Ek olarak söylemek gerekirse, ihiyaç duyulan değişiklikleri gerçekleştirmenin iyi olup olmayacağını sağlamak için bu pratik çalışma şekli takım arasında iyici benimsenmelidir.
Kodlama Standardı
XP takımları genel bir kodlama standardını uygularlar. Böylece sistemdeki tüm kodlar tek elden çıkmış gibi görülür. Standardın ayrıntıları önemli değildir. Önemli olan kodun tek elden çıkmış gibi görülmesidir.
Ortak Vizyon
Extreme programlama takımları programın nasıl işleyeceği ile ilgili genel, ortak bir vizyona sahiptir. Biz buna metaphor diyoruz. Metaphor en iyi hali ile programın nasıl işlediği ile ilgili bir tariftir. Ajan-tabanlı sistemde arı kovanı örneği için tarif vermek gerekirse “polen toplamaya git ve topladığın polenleri kovana getir ” gibi bir tarifini örnek olarak verebiliriz.
Bazı zamanlar yeterli bir metaphor ortaya konamayabilir. Her ne durum olursa olsun, güçlü bir bakış açısı olsun ya da olmasın, XP takımları sistemin nasıl işlediği ile ilgili herkesin anlayabileceği isimleri kullanırlar. Eğer bir yere bir fonksiyon konacaksa herkes için anlamlı bir yerde olmalıdır.
Sağlam Hız
Extreme programlama takımları uzun dönem çalışmayı düşünürler. Bu dönem içerisinde tarif edilemez(= tam olarak anlatılamayacak şekilde) bir şekilde hızlı ve sıkı çalışırlar. Bazen XP takımları etkili ve verimli oldukları zaman normalden daha çok çalışarak diğer zamanlardaki yavaşlıklarını telafi ederler. Başarısız projelerin birçok kişi tarafından da ortaya konan en önemli eksiklikleri hem yazılım yönüyle kaliteyi sağlamaması hem de üretim sürecinin uzun olmasıdır. XP takımları başarmaya kendilerini adamışlardır, başarısızlığa değil.
Sonuç
Extreme programlama basitlik, iletişim, feedback ve cesaretlendirme(gaza getirme) değerleri üzerine kurulu bir yazılım geliştirme disiplinidir. Bu disiplin takımı basit işler çerçevesinde bir araya getirir ve yeterli feedback ile de takım üyelerinin kendilerini yola sokmasına(ortama ayak uydurmaya) katkı sağlar.
XP ile ilgili genel sorular ve değişiklikler için bir makalemiz vardır. Bu konuda sorularınız ya da sorunlarınız olursa lütfen bize yazın. Sizin yazdıklarınız çerçevesinde de bu makaleyi güncelleyelim.Kayanak: Tahribat Araştırma geliştirme.. Google.com amca
Kısayol
Şikayet
Özel Mesaj
Alıntı yap
Cevapla