Bu sayfadaki yazılar
Sayfanın metni
Sayfa 130
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ı.
Klavyeyle gezinmek için ← ve → tuşları.
Sayfa 131
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.