• hayvan programlama metodolojisi*.

    keywords: basit dizayn, devamli test, tek kod - birden cok programci.
  • extreme coder kendine programcı dedirtmez bile...
    o coder'dır ki, jelly vector'leri rüyasında tasarlar,
    ve yaptığı optimized blit algoritmalarını zoom ile birleştirerek deli demolar yapar.
    o coder'dır ki, scripting language'lerinin hiçbirini kod olarak görmez,
    yazdığı koddan 2 byte tasarruf etmek için cpu'ya amuda kalkmayı bile öğretir.
  • extreme programcilik bir yazilim gelistirme disiplinidir. buna gore yazilima katkisi olan herkes bir ekip halinde kodun tum gelistirilme asamalarina katilir. urunu kullanacak kisileri temsilen disaridan biri* de ekibin bir parcasidir ve her asamada kodun test edilmesi icin durumlari yaratir. kod kucuk parcalar halinde ve anlasilabilir aciklikla gelistirilir. her parca itina ile test edilir ve tasarimin optimasyonu, gelistirilmesi saglanir. butun halinde kod gelistirildiginden kod ile ilgili herkes*** urun hakkinda tam bir fikre sahip olur ve kendi kismini bu yonde eksiksiz tamamlar. sonucta mukkemmel calisan bir yapi ve siyirmis yazilim guruhu ortaya cikar..
  • bir baska extreme programcilik ornegi de elinizde notebook ile skydiving yaparken ya da "operation swordfish" filmindeki gibi biri size oral seks yaparken*** muhasebe departmani icin raporlama konsolu tasarlamak olabilir..
  • bbg yapimciligi. aslinda yapimcilik yanlis bir soylem bu programla ilgili. yapamadik, bu cikti desek daha dogru olur.
  • (bkz: swordfish)
  • yazilim mimarisi ba$tan tasarlanmaz, zamanla eklenen ozelliklerle $ekil bulur,sabah ak$am test yapilir, dokumantasyon yapilmaz.
    programci yazilim geli$tirdigi i$ dunyasinin alanlariyla ilgili kendince karar alamaz, i$ dunyasindan da kimse teknik konularda fikir veremez.siz i$inizi yapin ben de i$imi yapiyim tarzinda bir yakla$imdir.
  • önce test et sonra kodla mantığıyla çalışır. yani girdisi, çıktısı belli olan metod içeriğini yazmadan, önce test kodu yazılır, sonra içi doldurulur.
    (bkz: test driven development)
  • extreme programming (xp diyelim bundan sonra) 3 ila 9 kişilik geliştiricileri olan projelere adapte edilebilir bir programlama paradigmasıdır (diğerlerine de uyarlanabilir fakat 10 kişiyi aştığınızda gerçekten xp dışına çıkmaya başkar çalışma yöntemleri zaten).. bu paradigma aslında "yazılım projelerinin her zaman geç kalıyor olması" problemini aşmak için ortaya atılmıştır (ortaya atılması da at gözlüklü kapalı kaynak kodlu yazılım geliştiricilerinin at gözlüklerini çıkarıp bu gnu'cular ne yapıyor bir de onlar gibi düşünelim demesi ile gerçekleşmiştir. kendisi 2000'li yılların ortalarında belirmeye başlamış olmasına rağmen çeşitli özgür yazılım projelerinde 90'lı yılların başlarından beri kullanıldığı bilinmektedir [aslında bu da diğer bir çok konu gibi özgür yazılımcıların bir şeyleri "ortaya atma" yöntemlerinin zavallılığına dayanmaktadır, bizde de hata yok değil yani]).

    xp genellikle özgür yazılım projelerinin doğası gereği izlenen "çabuk çıkar, sık güncelle" mantığına yakın bir işleyişi tavsiye eder. bu yöntem değişen requirement'lar için uygulamanın her zaman maksimum flexibility'ye sahip olmasını beraberinde getirir, çünkü ürün olarak sunulan ve geliştirilmesine devam eden yani bir son ürün haline gelmemiş bir uygulama için değişen beklentiler son ürün haline gelmiş bir uygulamaya nazaran daha uyarlanabilirdir.

    xp'yi benimsemiş yazılım projelerinde genellikle architect, designer, programmer, tester, quality officer gibi sınıflara ayrılmaz insanlar, herkes her işten bir miktar anladığı için kritik kararlar dışında herkes her şeyi yapabilir.. kritik kararlar da genelde o konunun uzmanının yönlendirmesine başvurulduktan sonra verilir (örneğin birisi xml konusunda deneyimlidir "burda xml kullanmazsak protokol overhead'den yırtarız ama yarın bir gün küsküyü yeriz, genişleyecek hep buralar" der, diğeri db konusunda deneyimlidir "transaction takibi ile başınız belaya girmesin berkeley db kullanın" der filan, fakat işleri diğerleri de götürebilirler bundan sonra kimse "o zaman burayı sen yap" demeyecek kadar biliyordur zaten). herkesin her işle ilgilenmesi proje içindeki insanların çok hızlı şekilde kendilerinden nispeten uzak mevzulara aşina olabilmesi ve üretime katılabilmesini beraberinde getirir. tabi xp projelerindeki insanlar genelde programlama ile ilgili bir çok konuda deneyimli ve bilgili insanlar olurlar, her biri kendi çapında pastadır.

    orta ölçekli bir yazılım projesinin (code size'ı şöyle 40k satırın üzerinde olan bir şey diyelim) en büyük sıkıntısı projedeki herkesin uygulamanın herhangi bir t anındaki durumunun ne olduğunu tam olarak bilememesidir, bu kimi zaman modülleri birbirinden bağımsız geliştiren kişilerin birbirlerini uzun süre beklemelerine neden olacak durumların ortaya çıkmasına da sebebiyet verebilmektedir.. fakat xp'de kimsenin katı olarak tanımlanmış ve sınırları çizilmiş bir görevi olmadığından herhangi bir geliştirici zor durumda olan geliştiriciye yardım edebilecek kadar onun yaptığı iş ile ilgili background bilgisine sahiptir. hemen ikisi yan yana oturur, aslan gibi o sorunu çözerler. birisi kendi yazdığı modül için hazırladığı unit test'i sınarken diğer modülde bir sorun bulursa ona el atar, bir başkası diğer birisinin kütüphanesini refactor eder, o sırada başka bir modülün yazarı da diğer geliştiricinin yazdığı unit test'i günceller filan. yeri gelir bir anda bütün ekip tek bir spesifik probleme eğilir, hep beraber onun için kafa patlatıp beraberce prototoip çözümü kodlar denerler.

    xp'de dökümantasyon çok önemlidir, özellikle geliştiricilerin kendi yaptıkları işle ilgili dökümantasyonları diğer geliştiricilerin adım atarken hangi yöne doğru gitmelerinin ilerde başlarını belaya sokacaklarını önceden hissetmelerini sağlar. +, dökümanlar sayesinde herkesin kafasındaki mimari ortak bir paydada buluşur, eksikler zamanında tartışılır ve netleştirilir, kafa karışıklıkları ortadan kalkar.

    xp içerisinde geçen extreme kelimesi aslında ilk duyulduğu anlamda bir sıradışılık değildir.. xp gayet basittir ve aslında bu işin akademik popoları bir kenara bırakırsanız standardı da budur. elbette bazı riskleri vardır, fakat bu risklerin gerçekleşme ihtimali projede çalışan kişilerin deneyimleri ile orantılıdır, en başta yapılan design'ın yanlış olma ihtimali ya da değişen müşteri requirement'ları bu tip projeleri diğer projeleri batırdığı gibi batırmaz.

    ayrıca xp projeleri içerisindeki insan ilişkileri de çok önemlidir, birbirini sevmeyen adamları bir arada çalıştırmak bu ciddi interaction ihtiyacı nedeni ile mümkün değildir.. bence şöyle de bir şey vardır, hiç bir projeye bu bir xp implementasyonu olacak diye başlayamazsınız, doğru adamları bir araya getirmeyi başarırsanız bu zaten otomatikman oluşacak bir şeydir, yanlış adamlar ise ağızları ile kuş tutsalar da xp havasını yakalayamazlar..
hesabın var mı? giriş yap