(Bu yazımın daha dertli toplu versiyonunu buradan okuyabilirsiniz)

Yarın akşam System Analysis And Design’s dersinde eXtreme Programming ile ilgili bir sunum yapıcağım. Bu akşam sunuma hazırlanırken kenara yazıcağım notları daha derli toplu şekilde buraya yazıp başka insanlarında faydalanmasının en iyisi olacağını düşündüm. Bu metadolojiye gerçekten çok inanıyorum. Umarım yazımı okuduktan sonra sizinde hoşunuza gider.

eXtreme Programming Nedir?

eXtreme Programming Kent Beck tarafından ilk defa 6 Mart 1996 yılında ortaya atılan bir Yazılım Geliştirme Metodolojisidir (Software Engineering Methodology). İsmine bakıldığında daha çok yazılımın kodlaması ile ilgili gözüksede (ekstrem şekilde kodlamak? tek eli kullanarak, işaret ve baş parmağı bant ile birbirine yapıştırmak fln gibi saçma ekstrem bir spor gibi) aslında tamamen mantık ve insan bağları üzerine kurulmuş tüm yazılım sürecini kapsayan bir metodolojidir.

eXtreme Programming, Çevik Yazılım Geliştirme(Agile Software Development) metadolojileri ailesindendir. Çevik metodlar ana konumuz olmasada kısaca değinmekte yarar var.

Klasik süreçlerde (waterfall vs.) genelde işler aşağıdaki sırada yürür

Gereksinimlerin çıkarılması Analiz Tasarımın yapılması Gerçekleştirim İmplementasyon Test Bakım/Sürdürme (Modelden modele sıralama değişmekte)

Yukarıda görünen adımlar sıra ile işletilir. İlk önce müşteri gereksinimleri çıkartır, analistler gereksinimleri detaylandırır, analizler yapar, muhtemel çözüm yöntemlerini düşünür arasından en iyisini seçerler, sonra seçilen yönteme göre yazılım tasarımını hazırlarlar sonra gerçekleştirimde kodlama yapılır vs vs.Yıllar önce yazılım istekleri daha küçük olduğu için, şuanki notepad yazılımı bile 10 yıl önce insanlar için bir nimetti, ihtiyaçlar daha limitli, hazırlanıcak dokümanlar daha anlamlı ve insanlar yazılım konusunda daha sabırlıydı. Fakat günümüzde teknoloji dünyası o kadar çok değiştiki, eskiden yazılım geliştirme donanım geliştirmesine göre daha hızlı iken, şimdi yazılımlar donanımların hızının gerisinde kalmaya başladı . Artık teknoloji o kadar hızlı ilerlemekteki, çok kısa aralıklarla donanımlar hızlanırken, yazılımlardan beklenen isteklerde gelişmeye başladı. Şu an gelinen noktada geleneksel modeller teknolojinin hızına ayak uyduramaz hale geldi ve insanlar daha hızlı yazılım geliştirme modelleri kullanmaya başladılar.

Çevik metadolojiler ise en önemli gerçeğin farkına vardılar : Klasik süreçlerde hazırlanan binlerce doküman, süreç adımları arasında alınan iyi/kötü kararlar müşteri için en ufak değeri olmayan saçma şeylerdir. Müşterinin tek değer verdiği şey istedikleri programın kendisidir ve başka hiçbirşeyi önemsemez. Klasik yaklaşımlarda ise adımlar arasında hazırlanan dokümantasyonlar sadece göz boyamalık, aslında kimsenin hiçbişey anlamadığı ama “öff süper olmuş bu grafik, Bu Use Case olmasa kesin hiç birşey anlamayacaktım” dedikleri çöplerden başka bişey değildir. Madem müşteri sadece programın kendisine değer biçiyor, o zaman bizde ona odaklanalım?

Temel Değerler

Ok konumu eXtreme Programminge geri dönelim. eXtreme Programming’nin temel değerleri aşağıdakilerdir :

• Basitlik (Simplicity)
• İletişim (Communication)
• Geri Bildirim (FeedBack)
• Cesaret (Courage)

Basitlik

eXtreme Programming projesinin tamamı basitlik üzerine kurulmalıdır. Kodlama, mimari, dokümantasyon, iletişim herşey çok basit olmalıdır. Basit olmayan herşey projeyi yavaşlatır. Basit tasarlanan bir sistem gelişmelere daha rahat adapte olur. O yüzden program ilk başta olabildiğince basit yazılmalı, gelen yeni isteklerde aynı basitlik anlayışı ile sisteme eklenmeli.

İletişim

Klasik süreç yaklaşımlarında iletişim denen şey, süreçler ve kişiler arasında gidip gelen dokümantasyonlardan ibarettir. eXtreme Programming’e göre (ki buna itiraz etmek aptallık olur) yazılımın tüm süresince çalışan varlıklar insanlardır. İnsanlar normal hayatlarında iletişim kurabiliyorlarsa, neden yazılım yaparken bunu dokümanlar üzerinden yapsınlar. Sonuçta hepimiz insan olduğumuza ve aynı dili konuşabildiğimize göre herşeyi konuşarak çok daha hızlı ve verimli şekilde çözebiliriz.

Geri Bildirim

Geri bildirim, eXtreme Programming’de 3 şekilde olur

• Testlerden Geri Bildirim : Yazılımın kodlanması süresince ve sonrasında her zaman test yapılır (Testlere ileride değineceğim). Bu testlerden çıkan sonuçlar değerlendirilir.
• Müşteriden Geri Bildirim : Açıklamaya gerek yok…
• Yazılım Ekibinden Bildirim : Kodcular, analistler, testçiler vs. süreç içinde gerçekleştirime katkı sağlayan herkes söz sahibidir ve tüm fikirleri birbirleri ile paylaşarak yarar sağlayabilir.

Cesaret

Cesaret yanlış anlaşımlaya müsait bir ifade olsada açıkça anlatmak istediği anlam şudur : Programcılar tüm kodlar üzerinde hakimdirler. Kodları yazarken özgürce istedikleri değişiklikleri istedikleri yerde yapabilirler(tabiiki sistemi bozmadan). Gereksiz methodları, yazılmak için günlerce uğraşılsa bile, silerler. Sadece günün isteklerini karşılayacak kodlar yazarlar, yarını düşünerek kod yazıp hem boşuna zaman harcamazlar hemde müşterinin isteğinin dışına çıkmayıp konsantrasyonlarını dağıtmazlar.

XP Takımı

eXtreme Programming değerlerini anladıktan sonra bir eXtreme Programming projesindeki kişileri ve rollerini açıklamakta yarar var.

Müşteri (Customer)

Müşteri adındanda anlaşılacağı gibi projenin asıl sahibidir. Bu bazı projelerde yazılımı yaptıran olabilirken, bazı projelerde yazılımı yaptırmakla görevli kişide olabilir. Müşterinin 2 görevi vardır, birincisi gereksinimleri belirlemek ve tüm projenin kendi isteklerine göre şekillendiğini takip etmek, ikinci görevi ASLA yazılımcının işine karışmamak.

Müşteriler, projede işin sahibi olduğu için tüm gereksinimleri ve bu gereksinimlerin önceliğini belirlemek onun görevidir. User Story’leri belirler ve önceliklendirir (User Stories’i ileride anlatacağım)

Programcı

Programcının görevi analiz, tasarım, test, programlama ve entegrasyondur. Bir nevi aslında projeyi gerçekleştiren kişidir. Programcı müşteri tarafından iletilen User Story’leri incelemek ve istenenleri 1e1 yapmakla yükümlüdür. Programcı asla müşteri isteklerine karışamaz. Öneride tabiiki bulunabilir ama işin sahibi müşteridir. Hangi işin ne zaman ve ne için yapılacağınada müşteri karar verir. Programcı sadece istenen işlerin ne kadar zamanda ve nasıl yapılacağına karar verir ve müşteriyi bilgilendirir.

Yönetici (Manager)

Yöneticinin görevi programcı ile müşteri arasında liderlik yapmaktır. Bu iki tarafı biraraya getirir, iki tarafıda gidişattan bilgilendirir (eXtreme Programming kesinlikle saydam bir projedir. Herkes birbirine karşı dürüst olmalı, iyi yada kötü hiçbirşeyi birbirinden saklamamalıdır). Yönetici projeyi kuş bakışı izler. Programcıların User Story’leri paylaşmasına yardımcı olur(yardımcı olur, asla delege etmez), müşteri istekleri yetişmeyecekse nasıl bir aksiyon alınacağına karar vermede liderlik yapar.

Projenin Aşamaları

Basitçe, XP projesinde müşteri iş gereksinimlerini karşılamak için yapılması gerekenleri User Stories (Özellikle Türkçeye çevirmedim, Kullanıcı Hikayeleri komik duruyor), olarak orta boy kağıtlara ayrı ayrı yazarak ortaya koyar. Bu kağıtlar üzerinde müşterinin ayrı ayrı programda nelerin olmasını istediği yazmaktadır. Programcılar bu kağıtları inceleyerek, her kağıda o işi ne kadar zamanda tahminen bitirebileceklerini yazarlar. Daha sonra gene tüm ekip(müşteri + yönetici + yazılımcılar) bu story’lerin üstünden geçerek bir sonraki iterasyonda(tam olarak kolay bir türkçe bulamadım) hangi story’lerin gerçekleştirilmesi gerektiğine karar verir. Burda karar verici kişi müşteridir. İşlerin önceliğini ve önemini sadece o bilebilir. Yazılımcı sadece tahmini zaman vermekle yükümlüdür.  Sonuç olarak ortaya çıkan denklem şudur : Müşteri işleri belirler, yazılımı işi gerçekleştirir.

XP projelerinde kullanılan yazılımda çok fazla yenileme (iterasyon/iteration) olur. Buda aslında Çevik metodların asıl amacıdır. Madem müşteri program görmek istiyor, bizde onlara en kısa periodik aralıklarla istediklerini verelim. Bu iterasyon aralıkları tamamen projeye ve duruma göre değişebilmektedir. Önerilen 1-3 hafta aralıklarıdır. Her iterasyonda yeniden planlama yapılır, müşteri yeni storyler ortaya koyar, programcılar tahmini süre verir, iterasyona sığabilecek storylere müşteri karar verir, programcı storyleri gerçekleştirir. Iterasyon bittikten sonra müşteri kabul testi (Acceptance Test) yapılır(Kodlama testi zaten yapılmıştı, ileride anlatacağım). Müşteri istedikleri ile yapılanın aynı olduğunu kabul eder ve iterasyon tamamlanıp işler kapatılır. Iterasyonlar tamamlandıkça program için Releaselerde yapılır. Releaseler ile kastım müşterinin kullanabileceği programlardır. Klasik süreçlerde ki gibi tüm projenin tamamlanması beklenmediğ için, sık aralıklarla yapılan releaselerde müşteri ağaçtan meyvayı yemeye başlar.

User Stories

User Stories(Kullanıcı Hikayeleri) müşteriler tarafından yazılan, herhangi bir zorunlu şablonu olmayan, oldukça basitçe ve anlaşılır şekilde yazılmış kağıt parçacıklarıdır. XP’de user stories, klasik süreçlerdeki gereksinim ve analiz dokümanlarının yerini almıştır. Ama klasik süreçlerdeki gibi günlerce haftalarca belki aylarca bu dokümanları hazırlamaya gerek yoktur. Herkesin bulunduğu bir toplantı yapılır, müşteri isteklerini ayrı ayrı kağıtlara yazar(user story) ve herkese okutur. Çok fazla detaya inmesine gerek yoktur. Sadece programcının genel olarak anlayıp, tahmini bir süre verebilmesi yeterlidir. User storylerle ilgili en önemli kural, isteğin mümkün olabildiğince basit ve yalın olmasıdır. Eğer bir istek yazılımcı tarafından 3 haftadan uzun sürecek şekilde çözülebilecekse, bu işte bir sorun vardır. Çünkü muhtemelen o bahsedilen istek, aslında tek bir istek değil birçok isteğin birleşmiş halidir. O zaman yazılımcı o kağıdı geri verir ve isteği parçalayıp daha küçük user storyler halinde vermesini ister. Böylece kavram karmaşası minimuma iner ve istekler netleşir. Böylece çıktıda daha sağlıklı olur. Tekrar altını çizmekte yarar var : User Storyler asla detay bilgi (teknik, yazılımsal, veritabanı vs.) içermezler. Genel hatları ile isteğin ne olduğu bir kaç cümle ile anlatılır.

Programcı tahmini süre verdikten ve iterasyon planı yapıldıktan sonra programcılar oturup tüm kağıtları(istekleri) paylaşırlar. Bu paylaşma işinde gönül esaslı olunması önemlidir. Yani programcılar istedikleri işleri yapmakta özgürdürler. Tabiiki müşterinin hiçbir isteği ortada bırakılamayacağı için, tüm işler iyi yada kötü paylaşılmalıdır. Paylaşım yapıldıktan ve programcılar gerçekleştirime başladıklarında tüm süreç boyunca müşteri ile direk iletişim kurabilirler. İşle ilgili soru sorabilir, onay alabilirler vs.. Ama iletişim asla kopmaz.

User Storyler, müşteri kabul testlerinde de kullanılır. Müşteriler kabul testlerinde, user story kağıtlarını kullanarak işlerin istendiği gibi yapılıp yapılmadını denetleyebilirler.

Süre Tahmini

Müşteri tarafından yazılan her user story, programcılar tarafından tahmini bir süre ile değerlendirilmelidir. Böylece istekler bir şekilde takvimlendirilebilir. Bu takvimlendirme baz alınarak iterasyon ve release tarihlerine göre hangi işlerin öncelik alacağı yada yapılmayacağı müşteri tarafından belirlenir. Süre tahmini yaparken programcılar daha önce yaptıkları benzer işleri baz alarak karar vermeye çalışırlar. Eğer bir iş zor gözüküyorsa o iş farklı user storylere parçalanarak daha basit küçük işlere bölünmelidir. Böylece süre tahmini yapmakta kolaylaşır. Eğer istenen iş daha önce yapılmadı ise, burda bir kaç farklı şey yapılabilir. Spike adı verilen minik denemeler yapılabilir. Yani şöyle düşünün, size bir iş geliyor, işin nasıl yapılabileceği konusunda fikriniz yok. İşi alıp bilgisayarınızın karşısına geçip herhangi bir kurala uymadan aklınıza gelen kod fikirlerini deneyip, sorunu nasıl çözebileceğinizi denersiniz. Denemeler sonucunda bir çözüme karar kılıp, tekrar tahmini süre verebilirsiniz. (Süre verilirken, birim testlerininde (unit testing) dahil edilmesi gerekmektedir. XP’de birim testi olmayan kod, kod değildir. )

Süre tahmini oldukça zor ve riskli bir işlemdir. Programcılar genelde süre tahmini yaparken, sadece o işe ayırılmış kafanın rahat olduğu, bilgisayarlarının kitlenmediğini, internetlerinin yavaşlamadığını, sevgililerinin telefon açıp kafa karıştırmadığı günleri baz alarak gün verirler. Ne yazıkki gerçek hayatta asla bu kadar izole bir çalışma ortamı olmuyor. Murphy’nin Kanunları yazılım projelerinin arkasını aslaaa bırakmaz… Bu yüzden proje yöneticisi İterasyon ve Release planlanlaması yaparken programcıların verdiği süreleri gerçekçi olacak şekilde güncellemelidir.

Planlama

Release Planning

Release planning’in iki farklı şekli vardır. Zamana göre, kapsama(scope) göre. Biz zaten süre tahminini yaptık ve her işin ne kadar sürebileceğini biliyoruz. Bundan sonra yapılması gereken, müşterinin zamana karşımı yarıştığı yoksa çıkan işlere göre hedefler mi belirlediğidir. Eğer belli bir zaman kısıtı var ise, müşteri deadline’a kadar çıkması gereken işleri belirler. Tabiiki bu işlerin toplam tahmini zamanı deadlineı geçmemelidir. Hangi işlerin seçileceği hangilerinin seçilmeyeceği tamamen müşterinin isteğine göre seçilir. Programcı yada yönetici bu konuda karar vermez. Bir çok projede olduğu gibi XP projelerinde de kısıtlı süre içine, olabileceğinden fazla iş sığdırılmaya çalışılır. Programcı ve yöneticilerin bunu asla kabul etmemesi gerekmektedir. Çünkü zaten biz dürüst olarak o işin ne kadar sürede biteceğini söyledik ve iş o kadar sürede bitirilecek. XP’de fazla mesai, stressli çalışma ortamı asla kabul edilemez. Bu nedenle kimse boşuna işleri sıkıştırmak için çabalamasın…

XP’ye göre bir projede Release planlaması yapılırken 4 ana değişken vardır.

• Kapsam (Scope)  (Ne kadar iş yapılacağı)
• Kaynak (Resource)  (Kaç çalışanın bu projeye dahil olacağı)
• Zaman (Time)  (Deadline)
• Kalite (Quality)  (Yazılım ve Test Kalitesi)

Bu 4 değişkeni göz önüne alınarak planlama yapılır. XP’ye göre hiçbir insan evladı bu 4 değişkenide aynı anda maksimize edemez. Tüm değişkenler birbirini etkilemektedir(kaliteyi arttırırsanız zaman ihtiyacınız artar. Kapsam artar, zaman sabit kalırsa, kalite düşer vs). Ayrıca bazı projelerde bazı değişkenler sabitlenmiş olabilir (Ör. Zaman müşteri tarafından net olarak belirlidir). Bu değişkenler arasında karar kılmak tüm proje ekibinin görevidir ve ne yazıkki gerçek bir doğrusu yoktur.

Iteration Planning

Iterasyon için tam bir Türkçe karşılık bulamamakta inat ediyorum(eğer siz bulursanız lütfen banada bildirin). Release planlaması yapıldıktan sonra o releasede yapılacaklara göre iterasyonlar planlanır. Iterasyon tüm bir release deadline’ı içinde kaç kez bir dur diyip “bak abi şu storyler bitti sende bi göz at istersen” dediğiniz zamanlardır. Iterasyonların 1 ile 3 hafta arasında olması önerilir. Release planlaması yaptıktan sonra ilk Iterasyonda hangi isteklerin (user story) yapılacağına müşteri tarafından karar verilir(Her iterasyonda ne kadar story seçilebileceği zaten süreye göre limitlidir). Bitirilmesi gereken işlere karar verildikten sonra tüm işlere göre Görev kağıtları (Task) hazırlanır. Görev kağıtları User storyler gibidir fakat yazılımcıya hitap eder(user story müşteriye hitap ediyordu).  Tüm taskler oluşturulduktan sonra dublike olanlar aradan çıkarılır ve programcıların seçilmesi için meydana dizilir. Her programcı çifti(opss daha Pair Programmingden bahsetmedim, XP’de programcılar yanlız çalışmaz çift çift çalışır ) istediği işe talip olur ve onu yapmaya başlar. XP’de dürüstlük ve cesaret ön plandadır. Tabiiki işler tahmin edildiği süreden uzun sürebilir(bazen kısada sürebilir?). Böyle durumlarda müşteri ve yönetici her zaman durumdan haberdar edilmelidir.

Her Iterasyon bitişinde bir sonraki iterasyonda yapılması gereken işlere karar verilir. Ayrıca biten iterasyonda tamamlanan işler müşteri tarafından kullanıcı kabul testinden geçirilir. Eğer kabul testinden geçemeyen işler olursa bir sonraki iterasyona eklenir.

XP’de Yazılım Geliştirme

XP’de yazılım geliştirme(kodlama/gerçekleştirim) adımlarında uygulanması gereken bazı kurallar vardır. Bu kurallar çevik güncellemeleri sağlarken, kodun kalitesini düşürmemek ve hem müşteri hemde programcının memnun olmasını sağlamak için ortaya konmuştur.

Pair Programming (Çift Olarak Programlama)

XP’de sanırım insana en garip gelebilecek ve “nasıl yani?” sorusunun en çok sorulacağı konu Pair Programmingdir. XP’de programcılar çiftler halinde çalışırlar. Yani 2 programcı tek bilgisayarda çalışır. Programcının biri klavye başında kod yazarken diğeri de hem kodu kontrol eder hemde tüm sürece hakim olmaya çalışır. Programcı algoritmayı çözmeye çalışırken, diğeri sisteme bağlı kalan kod yazıldığından emin olur. İki programcının birlikte çalışması birbirlerini “gazlamaları” konusunda da yardımcı olur. Programcı tek başına çalışırken kafası dağılıp işten uzaklaşabilir. Ama pair programlamada programcılar birbirlerini durmadan “uyanık” tuttukları ve işe birlikte odaklandıkları için ortaya daha kaliteli ve hızlı yazılmış bir kod çıkar. Hata sayısı daha az olur. Çiftler kendi içlerinde kısa aralıklarla durmadan görev değişimi yaparlar. Biri klavyenin başına geçer diğeri yönetime. Böylece iki tarafında gönlü hoş tutulur . Ayrıca sık sık çiftlerde değişir, her zaman aynı kişilerin çift olması herkesin tüm sisteme hakimiyetini düşürür.

Pair programming XP’de en saldırıya açık konudur. Belki iki programcının ayrı ayrı çalışarak daha fazla işi daha kısa zamanda tamamlanabileceğini düşünebiliriz. Fakat yazılımlarda bir kodun hızla yazılmasından çok, kaliteli yazılması daha önemlidir. Çünkü hızlı yazılan kod hataya daha açıktır ve genelde programlardaki hataları ayıklamak, bazen kodu baştan yazmaktan daha fazla zaman alabilir. Ama pair programming ile kod kalitesi arttığından, bakım ve destek masrafları azalır.

Diğer bir sorun da (ki aslında Türkiye’de eminim çok rastlanıyordur), programcılar yalnız çalışmayı seven şahsiyetlerdir. Bilgisayarları ile başbaşa kalıp sessiz bir ortamda kod yazmayı severler. Pair programming ise sosyal bir olgudur. İki programcının kişisel egolarını geride bırakıp, işe ortak bir şekilde odaklanıp çalışması gerekmektedir. Bu hissiyatı sağlamak biraz zaman alabilir ama XP’ye göre pair programming eğer başarılırsa, projenin gerçekleştirilmesinde çok kritik bir detaydır.

Birim Testleri (Unit Testing)

Unit testing XP için olmazsa olmaz kuralların başında gelir. XP’ye göre bir kod eğer testi var ve tüm testlerden %100 başarı ile geçiyor ise tamamlanmıştır. Bu test sonuçlarının asla istisnası olamaz. Programcı kod yazmadan önce unit test kodları yazar. Böylece programın nasıl çalışacağına kafa yormadan, programın hangi inputlarla hangi outputları oluşturacağına karar vermiş olur. Daha sonra testlerini hepsi %100 doğru çalışana kadar kodlarını günceller. Birim testleri otomatik çalışacak şekilde olmalıdır. Bunun için kullanılan bir sürü unit testing frameworkü bulunmakta(c# için csUnit, Java için jUnit, PHP için phpUnit gibi). Projeye başlamadan önce unit test frameworkünüzü seçip kurmanızda yarar var.

Peki test kodları neleri içermelidir. XP ye göre kural basit olsa da yüklediği anlam karışıktır : “Hata yapabilecek herşey test edilmelidir”. Bir modül yazılırken modüle ilişkin sorun çıkarması muhtemel herşey için test kodları yazılır. Nelerin sorun çıkarabileceğini programcı olarak zaten biz az çok tahmin edebiliriz ve bu konularda test yazmalıyız. Eğer bir bölümde hata çıkma ihtimali olup olmadığında kararsızsak fazla düşünmeye gerek yok gene test kodu yazarız.

Birim testleri kodun kalitesini arttırır ve programcıya rahatlık sağlar. XP’de çok fazla kod değişimi (Refactoring) yapılır ve yapılmalıdır. Bu kod değişiklikleri unit testing olmadan çok ciddi bir risk oluşturabilir. Ama yaptığımız değişikliklerden sonra tüm testleri çalıştırıp %100 ifadesini aldığımız sürece sistemin hala istendiği gibi çalıştığını görerek içimizi rahatlatırız. Ayrıca test kodları diğer programcıların sizin kodunuzu anlamaları içinde yardımcı olur. Kodun hangi işlemleri yaptığını test kodlarına bakarak rahatlıkla çözebilirler.

Birim testlerin önemi özellikle proje büyüdükçe ortaya çıkar. Yazdığınız her kod için test kodları yazdığınız için zamanla çok büyük bir test kodunuz oluşur. Bu iyidir çünkü tüm sistemin çalışmasını tek tuşa basarak ve tüm testleri çalıştırarak kontrol edebilirsiniz. Yazdığınız yeni kodlarda veya eskileri değiştirdiğinizde tekrar tüm testleri çalıştırarak sorunları takip edebilirsiniz. Eğer alakasız bir yerde sorun yaşarsanız biliyorsunzuki aslında sorunun kaynağı orası değil son yazdığım yer. Çünkü biraz önce testler çalışıyordu. Demekki yeni yazdığım kod bişeyleri bozuyor…

Refactoring

Refactoring için gene tam bir Türkçe kelime bulamasamda şöyle açıklayayım : Refactoring yazılımcının kodlarını ara ara okuyup düzenlemesidir. Bunu şöyle düşünelim. Bu akşam deadline’ı olan bir işiniz var. Testlerinizi yazdınız, iyi-kötü kodu bitirdiniz ve testlerden %100′ü aldınız (%100 almadan zaten bitmiş sayılmaz) ve işi teslim ettiniz. Ama içinizde bir sıkıntı var çünkü ASD methodunu çokta iyi bir şekilde kodlamadınız. Kod çalışıyor herhangi bir bug yada performans kaybı yok ama sanki daha düzgün şekilde yazabilirsiniz. İşte tüm proje boyunca, daha önceden yazılmış ve çalışan kodları tekrar gözden geçirip değişiklikler yapmaya Refactoring diyoruz.

XP projesinde refactoring çok sık olarak yapılan bir eylem. Refactoring sayesinde kodun kalitesi herzaman maksimumda tutulmaya çalışılır.

YAGNI(You Ain’t Gonna Need It): YAGNI’yi belki daha önce duymuşsunuzdur. XP’de Refactoring yaparkende bu ilke geçerlidir. Eğer bir method (yazması günlerce sürse bile) artık kullanılmayacaksa, uçurun… Eğer bir class yaparken o an kullanılmayacak bir method yazıcaksanız, yazmayın çünkü şuan kullanmayacaksınız. XP’de yarını düşünerek kod yazılmaz. Var olan talepleri karşılamaya yeticek kadar kod yazılır. Unutmayın Çevik olmak durumundasınız. Kullanılmayan method ve classlar kalabalık ve karışıklıktan başka birşey yaratmaz.

XP kodlamasında tüm methodlar olabildiğince basit ve anlaşılır olmalıdır. Eğer bir method yeterince basit değilse, daha basit parçalara bölünmeli ve anlaşılır olmalıdır(Aynen user storylerde yaptığımız gibi). Eğer bir methodun kodları scroll yapmadan ekranda tek bir seferde okunamıyorsa o method olması gerektiğinden uzundur ve kısaltılmalıdır. Unutmayın herşey olabildiğince basit olmalı.

Kod Sahipliği

XP’de diğer süreçlerde olduğu gibi kod sahipliği yoktur. Herkes ihtiyacı olduğu HER kodu değiştirebilir. Bu konuda hiç bir kısıt yoktur. Zaten tüm kodların test kodları olduğu için, bir kişi herhangi bir kodda değişiklik yaptıktan sonra testler hala %100 çalışıyorsa kimse için sorun çıkmayacaktır. Kimse “abi senin şu core.cs dosyasında ki 322. satırdaki if bloğuna şunu eklesene” cümleleri kurmayacaktır. Kimin neye ihtiyacı varsa yazacak, gerekirse yeni testler oluşturacak, tüm testlerin %100 çalıştığını kontrol ettiği sürece arkasına asla bakmayacaktır. Böylece tüm süreç daha hızlı ve etkin olarak işleyecektir.