|
|
|
|
 |
| yusuf.boyacigil@mynet.com |
Bu makalede Ekstrem Programlama diye çevirebileceğim (daha güzel bir çeviri bulanlar olursa alternatiflerden haberdar olmak isterim.) yazılım geliştirme metodundan bahsede ceğim. Devamında Ekstrem Programlama yerine kısaca "XP" kullanacağımdan dolayı şimdiden uyarırım ki "Windows XP" ile bu yazının herhangi bir ilişkisi yoktur. Windows XP Microsoft'un tescilli bir ürünüdür.
Herhangi bir yazılım projesinin yöneticisi olduğunuzu bir düşleyin. (Öyleyseniz okumaya devam edin.) Projeniz ile ilgili asıl kaygınız nedir? Zaman ve bütçeyi aşmadan, sadece ve sadece müşterinin isteklerini gerçekleştirmek! Bunu nasıl başaracaksınız? Analitik düşünce yapısına sahip bir kişi olarak, önce karşınıza çıkan veya çıkabilecek engelleri çözmek için onları anlamak, sonra bir yol veya ``metod`` bulmanız gerekecek. Ya da daha önce sizinle aynı kaderi paylaşmış ve sonunda bir çıkış yolu bulmuş olanların yaptıklarına başvurmanız gerekecek. Hangisini tercih edersiniz? 'Ben kendi metodumu kendim bulurum, ötekiler gölge etmesin yeter!' mi dediniz? O zaman size kolay gelsin, makalenin bundan sonraki kısmı size sadece vakit kaybettirecek.
Hımm, okumaya devam ettiğinize göre ya ikinciyi tercih ediyorsunuz, ya da merakınıza engel olamadınız. (Başka etkenler de olabilir ama onlar şu anda beni ilgilendirmiyor.) Öncekilerin bulduğu metodlardan birini kullanacaksanız, tercihinizi, az sonra açıklayacağım sebeplerden dolayı XP'den yana kullanmanızı öneririm. Ama önce, XP ile alakalı biraz ansiklopedik bilgi vererek başlayayım.
XP, kendileri, "Three Extremos" diye adlandırılan 3 kişi tarafından ortaya atılmış: Ward Cunningham, Kent Beck, Ron Jeffries. Burada başka bir metod olan Rational Unified Process'i (RUP) geliştiren ve "Three Amigos" olarak adlandırılan üçlüye nazire yapılmıştır.
XP'yi bulanlar onu şöyle tanımlıyorlar: XP basitlik, haberleşme, geribildirim ve cesaret temelleri üzerine kurulmuş olan bir yazılım geliştirme disiplinidir veya metodudur. Tüm takım üyeleri XP tarafından önerilen basit pratikleri , yani nelerin nasıl yapılması gerektiğini, kullanırlar. Yeterli geribildirim ile, ki bu direkt müşteriden, takım üyelerinden ve testlerden alınır, takım işin neresinde olduğunu görür. Pratikleri kendisine uygun bir şekilde ayarlamaya çalışır. Buradan anlaşıldığı kadarıyla XP'nin önerdiği pratikler mutlaka uyulması gereken kurallar değil; sizin de kendinizden bir şeyler katacağınız pratiklerdir.
Şimdi, XP nin üzerine oturduğu bu dört temelden bahsederek bitirmeyi düşünüyorum.
Üretilen yazılımın her aşamasında herşeyi mümkün olduğunca basit yapmaya çalışın. Tasarım yapıyorsanız basit olsun. Kod yazıyorsanız basit yazın. Niye? Herşeyden önce insanız da ondan. Kapasitemiz sınırlı. Basit ve modellenebilir olan şeylerin üstesinden ancak gelebiliyoruz da ondan. Peki XP bunu nasıl sağlayacak? Birkaç XP pratiği anlatarak özetleyeyim:
İyi tasarım nasıl yapılır? sorusuna dev yazılımcılar cevap aramışlar. Fakat ortaya bir şey çıkmamış ve şunu söyleyip işin içinden sıyrılmışlar: İstekleri tam olarak karşılayan yazılımı çıkarabiliyorsanız, iyi tasarım yapmışsınız demektir. Baştan herşeyi tasarlamanız mümkün olmadığına göre önce işe yarayacak bir tasarımla başlayın. Daha sonra yaptığınız testler le tasarımı düzeltmeye devam edersiniz. XP'de tasarım, öyle aylarca çalıştıktan sonra bir defada ortaya çıkan bir şey olmaktan ziyade devamlı olarak yapılan bir aktivitedir.
XP'ye göre tasarıma şöyle başlanır: Önce test kodları yazılır. Programa ne gireceksiniz, o size bunun sonucunda ne verecek. Sonra test kodlarını çalıştıracaksınız ve çalışmadığını göreceksiniz! Bundan sonra testlerin çalışmasını sağlamak için programın asıl kısımını yazmanız gerekecek. Böylelikle sadece sizden isteneni tasarlamaya başlayacaksınız.
Kod yazarlarına XP tavsiye eder ki: Yazdığınız kod çalışabilecek en basit kod olsun. Taklalar atmayın. Onu sizden daha iyi yapanlara bırakın: Güvercinler!
O anda işinize yaramayacak olan ve sizin ben bunu daha sonra bir yerde kullanırım dediğiniz hiç bir kod parçasını yazmayın. Sadece o anı düşünün. Gelecekte ne olacağını kim bilebilir ki?
"Refactoring", "Çöpe atmak" olarak tanımlanabilir. XP'de "refactoring" yazılımı geliştirmek için yapılan bir aktivitedir. Yazılımda gereksiz olduğunu düşündüğünüz kısımları düzenli olarak atmanız önerilir. Bu konuda da acımasız olmalısınız. Çünkü ellerinizle var ettiğiniz herhangi bir şeyi bir kalemde yok etmeniz zor bir iştir. "Refactoring" daha fazla atacak birşey kalmadığında bitmiş demektir.
XP tüm takım üyelerinin bir araya gelip çalışarak herbirinin kendi uzmanlık alanlarında yapacağı katkılarla yazılımı geliştirmeyi önermektedir. Takım üyeleri kimlerden oluşur? Sadece programcılardan değil! Müşteri de takımın bir parçası olarak kabul edilir. Müşteri isterlerin oluşturulması ve bunların önceliklerinin belirlenmesi, ortaya çıkacak yazılımda hangi özelliklerin olması gerektiği hususunda takımı bilgilendirir. Analistler müşteriye isterlerin ortaya çıkmasında yardımcı olur. Aynı zamanda yazılımın tam olarak nasıl çalışması gerektiği hususunda, bir son kullanıcının deneyimlerinden yararlanılması için takıma alınması iyi olur. Takım test uzmanlarını da içerebilir. Test uzmanları müşterinin kabul testlerini belirlemesinde aktif rol oynar. Tabii ki proje yöneticisi takımın bir parçasıdır ve ekibin doğru yolda olup olmadığını kontrol eder, koordinasyonu sağlar. Son olarak, harici yöneticiler de takım içerisine alınabilir. Onlar da projeye kaynak sağlar, finansörleri gelişimden haberdar eder. XP yazılımı geliştiren takım üyelerinin biraraya gelerek "yüzyüze" haberleşmelerini önerir. Bunun sebebi şudur: Takım üyeleri insanlardan oluştuğundan ve insanlar sosyal birer varlık olduklarından yüzyüze konuşarak haberleşmeleri en uygun olanıdır.
Yazılan kod önemli bir haberleşme aracıdır, XP'ye göre. Kod yazılırken herkes gerek format, gerekse isimlendirme konusunda daha önceden belirlenen kurallara uyarlar. Böylece biri diğerinin yazdığı kodu rahatlıkla okuyup, anlayabilir.
Dokümanlar da bir haberleşme aracıdır. Yalnız XP dokumantasyona biraz çekinceli yaklaşır. Dokümantasyon burokratiktir ve XP'nin önem verdiği "yüzyüze" olan haberleşmeye engeldir. İnsanlar bürokrasiden hoşlanmadıklarından dokümanlardan da hoşlanmazlar.
Dokümanlarla ilgili en büyük sorun devamlı geliştirilen bir yazılımda dokümanların da devamlı elden geçmek zorunda olmasıdır ki bu ekstra iş demektir. Hele ki bu dokümanlar programcı için hazırlanıyorsa bunların hem yazılması hem de takip edilmesi zor bir iştir. Programın kaynak kodu zaten bu görevi yerine getirmektedir.(XP ile yazılan bir kod hem basit hem de okunabilir olduğundan bu konuda çekinceye gerek bulunmamaktadır.)
XP dokümantasyona tamamen karşı bir tutum takınmaz. Mesela: Finansörleri bilgilendirmek, yazılıma ait el kitabı hazırlamak için dokümana ihtiyaç vardır.
XP için en önemli geri bildirim aracı testlerdir. Yazılan en ufak kod parçasını dahi test ederek daha işin başında nelerin doğru nelerin yanlış gittiğini anlayabilirsiniz ki bunlara "Unit Test" (Birim testi) denmektedir. Daha sonra birimleri bir arada çalıştıracağınız için onları birleşik olarak test etmeniz gerekir bu da "Integration Test" dir. (Birleştirme Testi) Birleştirdiğiniz birimler bir arada sistemi oluşturur ki onu da test edersiniz. Böylece "Sistem Test"ini de yaparsınız. Özellikle birim testleri çok önemlidir ve XP bu testlerin muhakkak yapılmasını öğütler.
Bir başka geribildirim aracı bizzat yazdığınız koddur. XP'de şöyle bir pratik vardır: "CodeSmell" (Kod koklama). Bu, yazdığınız kod ile alakalı bir problem varsa, izleri takip ederek, yani kodu inceleyerek, problemi bulmak için başvurabileceğiniz bir yöntemdir. Bu işi en iyi yapanların usta yazılımcılar olduğu söylenir. Onlar kodun mantığına girmeden, onu satır satır incelemeden problemi sezebilirler. Hatta onların, çok düşünmeden kolayca iyi tasarımlar yaptıkları ve bunu bir "UnconsciousCompetency" (BilinçdışıUstalık) la yaptıkları da söylenir.
Aslına bakılırsa, yukarıda bahsedilen üç temel, XP'nin yeteri kadar cesaret içerdiğini kanıtlıyor. XP'de geliştirdiğiniz sistemi, daha iyi çalışması için, bir parçasını rahatlıkla değiştirebilirsiniz. Korkmadan! Çünkü sağlam sistem testleriniz var. Ya da birşeyleri tamamladıktan sonra eğer ondan memnun olmazsanız, yaptıklarınızı çöpe atıp tekrar başlayabilirsiniz. Bunun geliştirdiğiniz sistemi tehdit eden bir davranış olmadığını bilmeniz, size güven vereceği gibi, bu güven ileri doğru çabuk adım atmanızı da sağlayacaktır.
Siteler:
Kitaplar:
|
|
