[title = Yazlm Gelitirmede Faydal Uygulamalar]

Dnyada yazlm gelitirme projeleri, bundan yaklak 5-10 yl ncesine kadar en riskli projeler arasnda grlyordu. Yaplan istatistiklerde, bu projelerin ok byk yzdesinin, hedeflenen zaman ve bteler iinde tamamlanamad, byk bir blmnn ise tamamen kontrolden kp, iptal edildii ortaya kyordu.

Bunun sonucu olarak, uzun sredir dnyada yazlm gelitirme sreclerinde, projeleri kontrol altnda ve her zaman hedefe doru ilerliiyor tutmak amal eitli uygulama ve metodlar denenmekte. Bu almalar, zellikle 2000'lerin balarndan beri artk sonu vermekte ve dnyadaki hemen hemen btn byk yazlm gelitirme ekiplerince kullanlan, baz "Faydal Uygulamalar" ortaya karmakta. Bu yazmzda bu uygulamalardan birkan ksaca tantmaya alacaz. 

Bu uygulamalar yalnzca ekipler olarak deil, tamamen bireysel almalarda da kullanmaktan ok fayda salayabilirsiniz.
[b]
- Build makinesi

- Build otomasyonu

- Versiyon ynetimi

- Hata ve istek takibi

- Test otomasyonu
[/b]

Bu ok temel ve basit uygulamalar kullanmayan yazlm gruplarnn hala bu kadar yaygn olmasnn sebebini inann bilmiyoruz. Ama lkemizdeki en byk sebebin, bu konulardaki bilgi eksiklii olmas ihtimaline kar bu yazy hazrladk.

[b]AYRI BR BUILD MAKNES[/b]

Bunu duymak size garip gelebilir. Ama ekibinizde hibir gelitiricinin kullanmad bir bilgisayar olmas ok ie yarayacaktr. Bu makinenin tek amac, otomatik olarak, kod her deitiinde projeyi (birazdan bahsedeceimiz) Versiyon ynetim sunucusundan alp, build edip, test ederek, yaplan deiikliklerin bireyleri bozmadndan emin olmaktr.

Bunu yapabilmeniz iin, birazdan aklayacamz build otomasyonu ve test otomasyonu yaplarn da kullanmanz gerekmekte. Fakat bu makinenin neden ayr ve srf bu ie ayrlm bir makine olmas gerektiini aklayalm. 

Sk yaplan bir hata, gelitiricilerin kod yazmak iin kullandklar makinelerde ayn zamanda test de yapmalardr. Bu, pekok dezavantaj beraberinde getirir. Gelitirme yaplan makinede genellikle ide ve eitli destek ktphaneleri kuruludur. Ayrca kullanlan baz ktphanelerin normalde kullanlacak versiyonlar deil debug versiyonlar kurulu olabilir. Eer build ve test ilemlerini, yalnzca byle bir gelitirme makinesinde test ederseniz, yazdnz program gerekten alaca artlarda test etmiyorsunuz demektir.

Build makinesinde, dardan kullandnz btn ktphane veya run-time-environment dosyalar, sfrdan kurulmu olup onlar dnda hibirey olmamal.

[b]BUILD OTOMASYONU[/b]

Build ilemi, projeden projeye farkllklar gsterir. Deiik projelerde, deiik admlarn izlenmesi gerekebilir. rnein, projenizdeki C++ dosyalar compile edilip, baz ktphaneler oluturulup, ardndan bunlar baz baka dll dosyalar ile beraber bir klasr yapsna yerletirilip, ondan sonra eitli toollar aracl ile retilmi data dosyalar ayn klasr yapsnda ilgili yerlere yerletiriliyor olabilir.

Admlar ne olursa olsun, otomatize edilmelidir. Yani konsoldan tek satir girerek almal ve size build edilmi almaya hazr halde projenizi verebilmelidir. Yani projenizi build ederken, nce ideyi ap, oradaki build tuuna basp, kan exe dosyasn falanca yere kopyalayp, ardndan filanca ktphaneyi el ile unzip etmek gibi ilemler yapyorsanz, kendinize gereksiz yere eziyet ediyorsunuz demektir.

Herey konsoldan tek komutla alyor olmal. Ayn konsol komutu idenizin iindeki bir butona da bal olabilir, bunda yanl olan birey yok. Fakat build ilemini otomatize etmelisiniz ki banda insan beklemeyen bilgisayarlar tarafndan projeniz otomatik olarak test edilebilsin.

Bunun iin pekok ara var. lk akla gelen Gnu Make ve trevleri (nmake vs..) java da Ant sk kullanlr. Basit shell scriptleri de kullanlabilir. Visual Studio kullanclar da projelerini konsoldan tek komutla build edebilir. VS bunun iin hazr scriptlere sahiptir.

[b]VERSYON YNETM[/b]

Versiyon ynetim sistemleri, bir grup dosyann zaman iinde deien btn versiyonlarn depolayan, dosyalardan birbiriyle uyumlu olanlar etiketleyebilen, ve istendiinde dosyalarn eski versiyonlarn verebilen sistemlerdir. Ayn zamanda o dosyalar zerinde alan kiilere deiik eriim haklar verebilir, dosyalardaki her bir deiikliin kimler tarafndan yapldn takip edebilirler. En nemli faydalarndan biri de ayn dosya zerinde ayn anda deiiklik yapan birden fazla kiinin deiikliklerini ynetebilmeleridir.

Versiyon ynetimi konusu, maalesef byle bir yazda tamamen aklanamayacak bir konudur. Fakat eer versiyon ynetimi sistemlerini kullanmay renmezseniz, belli bir bykln stndeki (mesela 20000 satrdan byk) projeleri kolay kolay bitiremezsiniz. Sadece kk projeler yapyorsanz bile, son eklediiniz classtan sonra ortaya kan bir bug' zmeye alrken, bir nceki versiyonu bir komutla alp karlatrdnz zaman, versiyon ynetimi ile tanmadan nceki hayatnza acma ile bakacaksnz.

Versiyon ynetimi iin dnyadaki ana standard CVS'tir. Dnyann en byk yazlm firmalarndan tutun da en byk open source sitelerine kadar herkes (belki birka istisna hari) CVS kullanmtr. Son yllarda CVS arayzn aynen kullanan ve CVSteki baz eski problemleri de gideren (rnein cvs'te text tabanl olmayan dosyalar saklamak biraz verimsizdir) yeni bir ara daha ortaya kt. Subversion isimli bu ara u an yzbinlerce projeye ev sahiplii yapan SourceForge sitesince kullanlyor. Ksacas versiyon ynetim sistemi olarak cvs ve subversion dnda sistemlere bakmak iin yanp tutumuyorsanz, bu ikisinden birini gnl rahatlyla seip kullanmaya balayn.

Versiyon ynetim sistemi iin ayr bir sunucu makine ayrmanz iddetle neririz. Gelitirme makinelerinin (ve bazen build makinesinin) aksine Versiyon ynetim sunucunuzun ok gl bir makine olmasna gerek yoktur. Sadece harddiski yeterince byk olsun ve siz bu makineyi sk sk yedekleyin yeter.

[b]HATA VE STEK TAKB[/b]

Projeyi yapyorken, sizden istenen eyleri ve ortaya kan hatalar bir listede tutmak ok da uzun aklama gerektirmeyen bir gereklilik. Basit bir deftere not alabilirsiniz elbet, ama bu i iin gelitirilmi baz sistemleri kullanarak, yalnzca liste oluturmak deil, listedeki maddelere ncelik sras vermek, bu maddeleri gelitiricilere paylatrmak veya bug saysnn proje zamanna grafiini karmak gibi eitli ynetimsel amal uygulamalar hayata geirebilirsiniz.

Ayrca gelitiricilerin ve testilerin ayr gruplar olarak alt durumlarda, hatann girilii, gelitiricinin uramaya balamas, hatann tamir edilmesi, ve son olarak hatann tamir edildiinin grlerek hata kaydnn kapatlmas gibi, bir hata kaydnn getii btn evreler bu sistemlerde takip edilebilir.

Bunun iin incelenebilecek ok ara var. Balang olarak bunlardan en populerlerinden olan Bugzilla'ya bakmanz neririz.

[b]TEST OTOMASYONU[/b]

Test konusu, ou zaman projelerde en az zaman ve kaynak ayrlan konudur. Dnyada bu kadar ok projenin baarsz olmas bu yzdendir.

Program altrp menlere girip kmak, tulara rastgele basmak vs test demek deildir. Test hayli kompleks bir yazlm aktivitesidir. 

Yazlan her kod anlaml birimlere blnp test edilmelidir. Bu birimler ou zaman class metodlar veya fonksiyonlar olabilir. Yani programnzda 50 class ve bu classlarda toplam 500 metod varsa, ideal olarak bu 500 methodu da test eden kodlar yazmalsnz. 

ou zaman ideal durum mmkn olmad iin, test edilecek eyler arasndan en kritik olanlarnn seilmesi ve gerekletirilmesi hayati nem tar.

Ama ok derin bir konu olan test senaryosu yaratma konusuna girmeyeceiz. Bizim burada deineceimiz konu, Test otomasyonu. 

Yazlan her test senaryosu, bir test senaryo kmesinde biriktirilmeli (Buna "Test Harness" deniyor) ve her test sonu olarak "Geti" veya "Kald: XXXX hatas olutu" eklinde bir sonu vermelidir.

Test otomasyon sisteminizle Test Harness iindeki senaryolardan istediklerinizi arka arkaya altrabilmeli ve hepsinden dnen sonular otomatik olarak raporlayabilmelisiniz. Bu raporun sonunda:

[b]"12740 test senaryosu altrld. 12203 tanesi geti. 537 tanesi kald"[/b]

gibi bir satr bulunmal. 

te bu otomasyon sayesinde daha nce belirttiimiz build makineniz her gece siz uyurken Versiyon ynetim sisteminden projenin son versiyonunu ekip, Test Harness ' altrarak, srekli olarak kodun salamlnn geriye gitmediinden emin olur. Bu sayede gelitiricilerden biri bir hatay zmek iin yapt deiiklik ile eskiden zlen bir bug' tekrar sisteme sokarsa, bunu hemen farkedebilirsiniz.

Test otomasyon sistemi olarak XUnit serisine bakmanz neririz (Java iin JUnit, C++ iin CppUnit)

Eer PC d bir platformda test otomasyonu kurmanz gerekirse, kullandnz sistemin giri klarna bakmalsnz. rnein emlatr kullanyorsanz, emlatrden sisteme olan k yollarna bakp, emulatrde alan programn bireyleri PC sistemine raporlayabilmesini salayp, bunu da otomatik test scriptleri ile kontrol edebilirsiniz. Mesela C64 emlatr VICE'n user port emulasyonu sayesinde, yazdmz bir c64 programnn, user port zerinden PC harddiskinde bir dosyaya baytlar gndermesini salayabiliriz. Sonra da bu baytlarn beklenen baytlar olup olmadn PC'de kontrol edip (tabii ki otomatize edilmi halde), Test Senaryosu iin geti veya kald sonucunu retebiliriz.


[b]SONU[/b]

Daha nceden bu kavramlarla karlamam programclar iin bu anlattklarmz ok abartl gelebilir. Fakat bu uygulamalar, dnyada giderek karmaklaan yazlm projelerini kontrol altna almakta ne kadar baarl ise, kiilerin tek balarna yaptklar projelerde de bir o kadar ie yarayacaktr. Bu sistemleri kurmak, bata biraz efor gerektirse de, bir kere hayata geirdikten sonra fazla fazla zaman kazandracaklardr. Ayrca den donanm fiyatlar sayesinde, gelitirme makinasndan baka Versiyon ynetim ve hata takip iin bir makine, ve build makinesi olarak bir dier makine bulundurmak bugn artk renciler iin dahi gayet mmkndr. nk ikinci ve nc makineler olarak ou zaman 150 - 200 YTL'ye temin edilebilecek ikinci el makineler olabilir. Bir baka yol da, internette CVS veya bugzilla servisi veren sitelerden faydalanp, proje dosyalarnz web de saklamak olabilir. Bu zaten farkl yerlerde alan insanlarn projede kolaylkla yer alabilmesini de salar.

Konuyla ilgili soru ve yorumlarnz iin soru@nightnetwork.org adresinden bize ulaabilirsiniz.

[b]Nightlord[/b]

