2004 senesinin sonlarına yaklaştığımız bu günlerde XP teknikleri ülkemizde sıkça gündeme gelmeye başladı. Artık birçok şirkette bu teknikler tartışılıyor, bilgi alışverişinde bulunmak üzere bu konu yaz kamplarında gündeme taşınıyor. İnsanların akıllarındaki başlıca sorular ise: Gerçekten XP pratikleri uygulanabilir mi? Acaba çok mu uçucu fikirler bu pratikler? Beklenen sonuçlar sadece hayal mi?
Bu pratiklerden biride ‘önce testini yaz sonra işlevi kodla’. Bu pratik hakkında biraz kitap karıştırıp, yayınlanan önemli yazıları okuduktan sonra yararlı bir metot olabileceğine ikna oluyorsunuz. Özellikle yazılımlarınız en kritik işlevlerini geliştirirken bu metodun kullanılması gerektiğini düşünüyorsunuz. İşlevin önce testini yazmak için işlevin kendisi ile ilgili detaylı düşünmek gerektiğinden, bu metot sizi kodlarınız üzerinde daha fazla düşünmeye zorluyor. Bir diğer önemli nokta ise; bu metot, son durumda yazılımın doğrulayamadığı hiçbir test adımı kalmaması temeline dayanır ve yazılan tüm testler başarılı olana kadar devam eder. Ortaya çıkan son ürünün başlangıçta belirlenen gereklerin tamamını karşıladığından bu metot ile emin olabiliriz. Bu da müşteri tarafından sağlanması istenen en önemli noktadır.
Geçtiğimiz yaz aylarında TurkTech e-posta grubunda bu konuda bence gayet verimli geçen bir bilgi paylaşımı yaşadık. Üzerinde durduğumuz noktalar:
Bu metodun Türkçe karşılığı ne olmalıdır?
Şu anda aktif olarak işlettiğimiz yazılım geliştirme sürecinde bu metodu
nereye yerleştirebiliriz?
Bu yeni süreçteki roller nasıl olabilir?
Metodun Türkçe karşılığı ile ilgili çeşitli öneriler ortaya çıktı.
Bunlardan bazıları; ‘Test Tarafından Yönlendirilen’, ‘Teste Yönelik’, ‘Test Odaklı’, ‘Test’ yerine ‘Sınama’ kullanılması, ‘Test Güdümlü’ idi. Bu nokta için oyum Türkçe karşılık olarak ‘Sınamaya Yönelik Yazılım Geliştirme Metodu’ kullanılmasına gidiyor.
Bu metot tasarım, kodlama ve sınama adımlarının tümünü içerisinde barındırmaktadır. XP pratikleri ile ilgili belki de en önemli tartışma buradan çıkmaktadır. Acaba ‘tasarım evresi hafifletiliyor mu?’ ve ‘bu hafifletmenin kazandırdıkları ve/veya kaybettirdikleri neler?’ Bu konudaki tartışmalar devam etmektedir. XP hakkında yazıları ile tanıdığımız Martin Fowler, bu konuda diğer XP savunucularından farklı olarak ayrıntılı tasarımın değil ama mimari tasarımın süreç içerisinde kodlama aşamasına geçilmeden yapılmasını savunmakta ve tasarımın XP içerisinde yok sayılmadığını vurgulamaktadır. Aslında bu konu metot içerisinde açık bir nokta gibi duruyor, sizin yorumunuza bağlı olarak değişik şekillerde uygulanabilir. Bu metodu uygulama esnasında tasarımınız tamamen evrimsel bir şekilde gelişiyor. Birim testi sonuçlarına göre tasarımda sürekli bir iyileştirmeye gidiyorsunuz. Bunun iyileştirmeler için metot içerisinde yer alan ‘yeniden yapılandırma (refactoring)’ safhasını kullanabiliriz. XP’nin kendine özgü bir süreci olmasına karşın eğer yerleşik klasik bir süreciniz var ise, bu metodu analiz safhası ile sistem entegrasyonu safhası arası yerleştirmeniz en iyisi olacaktır. Bununla beraber, çok daha katı bir sürece sahipseniz, tasarım gözden geçirmeleri yapıp onaylıyor, bu iş ürününü baz alıp kod geliştiriyorsanız, bu metodun organizasyonunuza en büyük katkısı geliştirdiğiniz yazılımın tüm testlerden başarı ile geçtiğinden emin olabilmeniz olacaktır.

Bu metodun başarılı bir uygulaması ülkemizde Sn. Orhan Kalaycı tarafından bir holdingin bilgi işlem şirketi olan BİMAR AŞ’de geçen kış aylarında gerçekleştirildi. Bu uygulamada, müşteri ile konuşmaya başlanılan ilk anda test gündeme gelmiş. İlk önce, müşteri ne istediğini ‘müşteri kartlarına’ yazıyor ve daha sonra da müşteriden ‘test senaryosu kartı’nı doldurması isteniyor. Burada amaç, müşterinin isteklerin nasıl test edileceği konusunda etraflıca düşünmesini sağlamak. Böylelikle, XP’nin temel bileşenlerinden müşterinin mümkün olduğunca geliştirme sürecinde etkin rol oynaması sağlanmış oluyor.
Üzerinde durduğumuz bir diğer nokta ise bu metot içerisindeki rollerin nasıl olabileceği idi. XP uygulanma sürecinde tasarımcı ve programcı diye ayrı roller bulunmamaktadır. Eğer klasik organizasyon yapısına sahip iseniz, bu metot için en ideal çözümün tasarımcı ve programcınızın aynı kişi olmasıdır diye düşünüyorum. Eğer tasarımcınız ile programcınız farklı ise çözüm olarak yine XP pratiklerinden ‘çiftli programlama (pair programming)’ kullanılabilir. Fakat, tasarımcınız birden fazla proje ile ilgileniyor ise kendisini projeler arasında anahtarlaması zor olacaktır.

Bilgi paylaşımına katkılarından dolayı Cenk Civici, Orhan Kalaycı, Levent Aksu, Bora Güngören, Güliz Gököz ve Alper Özel’e teşekkür ederim. Bu sıralar birçok şirketin bu konuda çekinceleri var, danışmanlık firmaları ise bu çekinceleri ortadan kaldırmak için çeşitli seminerler, çalıştaylar düzenliyorlar. Bazı şirketler ise kendi içlerinde pilot projelerde bu türden pratikleri hayata geçirip, sonuçlarını gözlemlemeye çalışıyorlar.
Görüşlerinizi ve düşüncelerinizi merakla bekliyorum.
En iyi dileklerimle,