Yazılım Geliştirmede Faydalı Uygulamalar

Dünyada yazılım geliştirme projeleri, bundan yaklaşık 5-10 yıl öncesine kadar en riskli projeler arasında görülüyordu. Yapılan istatistiklerde, bu projelerin çok büyük yüzdesinin, hedeflenen zaman ve bütçeler içinde tamamlanamadığı, büyük bir bölümünün ise tamamen kontrolden çıkıp, iptal edildiği ortaya çıkıyordu.

Bunun sonucu olarak, uzun süredir dünyada yazılım geliştirme süreçlerinde, projeleri kontrol altında ve her zaman hedefe doğru ilerliyor tutmak amaçlı çeşitli uygulama ve metodlar denenmekte. Bu çalışmalar, özellikle 2000'lerin başlarından beri artık sonuç vermekte ve dünyadaki hemen hemen bütün büyük yazılım geliştirme ekiplerince kullanılan, bazı "Faydalı Uygulamalar" ortaya çıkarmakta. Bu yazımızda bu uygulamalardan birkaçını kısaca tanıtmaya çalışacağız.

Bu uygulamaları yalnızca ekipler olarak değil, tamamen bireysel çalışmalarda da kullanmaktan çok fayda sağlayabilirsiniz.

- Build makinesi

- Build otomasyonu

- Versiyon yönetimi

- Hata ve istek takibi

- Test otomasyonu

Bu çok temel ve basit uygulamaları kullanmayan yazılım gruplarının hala bu kadar yaygın olmasının sebebini inanın bilmiyoruz. Ama ülkemizdeki en büyük sebebin, bu konulardaki bilgi eksikliği olması ihtimaline karşı bu yazıyı hazırladık.

AYRI BİR BUILD MAKİNESİ

Bunu duymak size garip gelebilir. Ama ekibinizde hiçbir geliştiricinin kullanmadığı bir bilgisayar olması çok işe yarayacaktır. Bu makinenin tek amacı, otomatik olarak, kod her değiştiğinde projeyi (birazdan bahsedeceğimiz) Versiyon yönetim sunucusundan alıp, build edip, test ederek, yapılan değişikliklerin bir şeyleri bozmadığından emin olmaktır.

Bunu yapabilmeniz için, birazdan açıklayacağımız build otomasyonu ve test otomasyonu yapılarını da kullanmanız gerekmekte. Fakat bu makinenin neden ayrı ve sırf bu işe ayrılmış bir makine olması gerektiğini açıklayalım.

Sık yapılan bir hata, geliştiricilerin kod yazmak için kullandıkları makinelerde aynı zamanda test de yapmalarıdır. Bu, pek çok dezavantajı beraberinde getirir. Geliştirme yapılan makinede genellikle IDE ve çeşitli destek kütüphaneleri kuruludur. Ayrıca kullanılan bazı kütüphanelerin normalde kullanılacak versiyonları değil debug versiyonları kurulu olabilir. Eğer build ve test işlemlerini, yalnızca böyle bir geliştirme makinesinde test ederseniz, yazdığınız programı gerçekten çalışacağı şartlarda test etmiyorsunuz demektir.

Build makinesinde, dışarıdan kullandığınız bütün kütüphane veya run-time-environment dosyaları, sıfırdan kurulmuş olup onlar dışında hiçbir şey olmamalı.

BUILD OTOMASYONU

Build işlemi, projeden projeye farklılıklar gösterir. Değişik projelerde, değişik adımların izlenmesi gerekebilir. Örneğin, projenizdeki C++ dosyaları compile edilip, bazı kütüphaneler oluşturulup, ardından bunlar bazı başka dll dosyaları ile beraber bir klasör yapısına yerleştirilip, ondan sonra çeşitli toollar aracılığı ile üretilmiş data dosyaları aynı klasör yapısında ilgili yerlere yerleştiriliyor olabilir.

Adımlar ne olursa olsun, otomatize edilmelidir. Yani konsoldan tek satır girerek çalışmalı ve size build edilmiş çalışmaya hazır halde projenizi verebilmelidir. Yani projenizi build ederken, önce IDE'yi açıp, oradaki build tuşuna basıp, çıkan exe dosyasını falanca yere kopyalayıp, ardından filanca kütüphaneyi el ile unzip etmek gibi işlemler yapıyorsanız, kendinize gereksiz yere eziyet ediyorsunuz demektir.

Her şey konsoldan tek komutla çalışıyor olmalı. Aynı konsol komutu IDE'nizin içindeki bir butona da bağlı olabilir, bunda yanlış olan bir şey yok. Fakat build işlemini otomatize etmelisiniz ki başında insan beklemeyen bilgisayarlar tarafından projeniz otomatik olarak test edilebilsin.

Bunun için pek çok araç var. İlk akla gelen Gnu Make ve türevleri (nmake vs..) Java'da Ant sık kullanılır. Basit shell scriptleri de kullanılabilir. Visual Studio kullanıcıları da projelerini konsoldan tek komutla build edebilir. VS bunun için hazır scriptlere sahiptir.

VERSİYON YÖNETİMİ

Versiyon yönetim sistemleri, bir grup dosyanın zaman içinde değişen bütün versiyonlarını depolayan, dosyalardan birbiriyle uyumlu olanları etiketleyebilen ve istendiğinde dosyaların eski versiyonlarını verebilen sistemlerdir. Aynı zamanda o dosyalar üzerinde çalışan kişilere değişik erişim hakları verebilir, dosyalardaki her bir değişikliğin kimler tarafından yapıldığını takip edebilirler. En önemli faydalarından biri de aynı dosya üzerinde aynı anda değişiklik yapan birden fazla kişinin değişikliklerini yönetebilmeleridir.

Versiyon yönetimi konusu, maalesef böyle bir yazıda tamamen açıklanamayacak bir konudur. Fakat eğer versiyon yönetimi sistemlerini kullanmayı öğrenmezseniz, belli bir büyüklüğün üstündeki (mesela 20000 satırdan büyük) projeleri kolay kolay bitiremezsiniz. Sadece küçük projeler yapıyorsanız bile, son eklediğiniz class'tan sonra ortaya çıkan bir bug'ı çözmeye çalışırken, bir önceki versiyonu bir komutla alıp karşılaştırdığınız zaman, versiyon yönetimi ile tanışmadan önceki hayatınıza acıma ile bakacaksınız.

Versiyon yönetimi için dünyadaki ana standart CVS'tir. Dünyanın en büyük yazılım firmalarından tutun da en büyük open source sitelerine kadar herkes (belki birkaç istisna hariç) CVS kullanmıştır. Son yıllarda CVS arayüzünü aynen kullanan ve CVS'teki bazı eski problemleri de gideren (örneğin CVS'te text tabanlı olmayan dosyalar saklamak biraz verimsizdir) yeni bir araç daha ortaya çıktı. Subversion isimli bu araç şu an yüz binlerce projeye ev sahipliği yapan SourceForge sitesince kullanılıyor. Kısacası versiyon yönetim sistemi olarak CVS ve Subversion dışında sistemlere bakmak için yanıp tutuşmuyorsanız, bu ikisinden birini gönül rahatlığıyla seçip kullanmaya başlayın.

Versiyon yönetim sistemi için ayrı bir sunucu makine ayırmanızı şiddetle öneririz. Geliştirme makinelerinin (ve bazen build makinesinin) aksine versiyon yönetim sunucunuzun çok güçlü bir makine olmasına gerek yoktur. Sadece hard diski yeterince büyük olsun ve siz bu makineyi sık sık yedekleyin yeter.

HATA VE İSTEK TAKİBİ

Projeyi yapıyorken, sizden istenen şeyleri ve ortaya çıkan hataları bir listede tutmak çok da uzun açıklama gerektirmeyen bir gereklilik. Basit bir deftere not alabilirsiniz elbet, ama bu iş için geliştirilmiş bazı sistemleri kullanarak, yalnızca liste oluşturmak değil, listedeki maddelere öncelik sırası vermek, bu maddeleri geliştiricilere paylaştırmak veya bug sayısının proje zamanına grafiğini çıkarmak gibi çeşitli yönetimsel amaçlı uygulamaları hayata geçirebilirsiniz.

Ayrıca geliştiricilerin ve testçilerin ayrı gruplar olarak çalıştığı durumlarda, hatanın girilişi, geliştiricinin uğraşmaya başlaması, hatanın tamir edilmesi ve son olarak hatanın tamir edildiğinin görülerek hata kaydının kapatılması gibi, bir hata kaydının geçtiği bütün evreler bu sistemlerde takip edilebilir.

Bunun için incelenebilecek çok araç var. Başlangıç olarak bunlardan en popülerlerinden olan Bugzilla'ya bakmanızı öneririz.

TEST OTOMASYONU

Test konusu, çoğu zaman projelerde en az zaman ve kaynak ayrılan konudur. Dünyada bu kadar çok projenin başarısız olması bu yüzdendir.

Programı çalıştırıp menülere girip çıkmak, tuşlara rastgele basmak vs. test demek değildir. Test hayli kompleks bir yazılım aktivitesidir.

Yazılan her kod anlamlı birimlere bölünüp test edilmelidir. Bu birimler çoğu zaman class metodları veya fonksiyonlar olabilir. Yani programınızda 50 class ve bu class'larda toplam 500 metod varsa, ideal olarak bu 500 methodu da test eden kodlar yazmalısınız.

Çoğu zaman ideal durum mümkün olmadığı için, test edilecek şeyler arasından en kritik olanlarının seçilmesi ve gerçekleştirilmesi hayati önem taşır.

Ama çok derin bir konu olan test senaryosu yaratma konusuna girmeyeceğiz. Bizim burada değineceğimiz konu, test otomasyonu.

Yazılan her test senaryosu, bir test senaryo kümesinde biriktirilmeli (Buna "Test Harness" deniyor) ve her test sonuç olarak "Geçti" veya "Kaldı: XXXX hatası oluştu" şeklinde bir sonuç vermelidir.

Test otomasyon sisteminizle Test Harness içindeki senaryolardan istediklerinizi arka arkaya çalıştırabilmeli ve hepsinden dönen sonuçları otomatik olarak raporlayabilmelisiniz. Bu raporun sonunda:

"12740

test senaryosu çalıştırıldı. 12203 tanesi geçti. 537 tanesi kaldı.

gibi bir satır bulunmalı.

İşte bu otomasyon sayesinde daha önce belirttiğimiz build makineniz her gece siz uyurken versiyon yönetim sisteminden projenin son versiyonunu çekip, Test Harness'ı çalıştırarak, sürekli olarak kodun sağlamlığının geriye gitmediğinden emin olur. Bu sayede geliştiricilerden biri bir hatayı çözmek için yaptığı değişiklik ile eskiden çözülen bir bug'ı tekrar sisteme sokarsa, bunu hemen fark edebilirsiniz.

Test otomasyon sistemi olarak XUnit serisine bakmanızı öneririz (Java için JUnit, C++ için CppUnit).

Eğer PC dışı bir platformda test otomasyonu kurmanız gerekirse, kullandığınız sistemin giriş çıkışlarına bakmalısınız. Örneğin emülatör kullanıyorsanız, emülatörden sisteme olan çıkış yollarına bakıp, emülatörde çalışan programın bir şeyleri PC sistemine raporlayabilmesini sağlayıp, bunu da otomatik test scriptleri ile kontrol edebilirsiniz. Mesela C64 emülatörü VICE'ın user port emülasyonu sayesinde, yazdığımız bir C64 programının, user port üzerinden PC hard diskinde bir dosyaya baytlar göndermesini sağlayabiliriz. Sonra da bu baytların beklenen baytlar olup olmadığını PC'de kontrol edip (tabii ki otomatize edilmiş halde), Test Senaryosu için geçti veya kaldı sonucunu üretebiliriz.

SONUÇ

Daha önceden bu kavramlarla karşılaşmamış programcılar için bu anlattıklarımız çok abartılı gelebilir. Fakat bu uygulamalar, dünyada giderek karmaşıklaşan yazılım projelerini kontrol altına almakta ne kadar başarılı ise, kişilerin tek başlarına yaptıkları projelerde de bir o kadar işe yarayacaktır. Bu sistemleri kurmak, başta biraz efor gerektirse de, bir kere hayata geçirdikten sonra fazla fazla zaman kazandıracaklardır. Ayrıca düşen donanım fiyatları sayesinde, geliştirme makinesinden başka versiyon yönetim ve hata takip için bir makine ve build makinesi olarak bir diğer makine bulundurmak bugün artık öğrenciler için dahi gayet mümkündür. Çünkü ikinci ve üçüncü makineler olarak çoğu zaman 150-200 YTL'ye temin edilebilecek ikinci el makineler olabilir. Bir başka yol da, internette CVS veya Bugzilla servisi veren sitelerden faydalanıp, proje dosyalarınızı web'de saklamak olabilir. Bu zaten farklı yerlerde çalışan insanların projede kolaylıkla yer alabilmesini de sağlar.

Konuyla ilgili soru ve yorumlarınız için soru@nightnetwork.org adresinden bize ulaşabilirsiniz.

Nightlord