RAD(Rapid Application Development) yani Hızlı Uygulama Geliştirme bir yazılım geliştirme yöntemidir. Çok fazla detaya girilmeden, hızlı şekilde çalışan bir uygulama oluşturma amacıyla benimsenen bu yöntem için kullanılan birçok araç ve kütüphane bulunmaktadır. Tabii ki olay sadece kullanılacak araç veya kütüphanede bitmiyor, ekibin bu yöntemi bilmesi, kullanılacak araçları yakından tanıması, hızlı çalışırken az hata yapması, hızlı geliştirmenin getirebileceği olumsuz durumlar(performans, güvenlik gibi) için dikkatli davranılması… gibi konulara hususlarında yine çok detaya girilmeden önemle ele alınması gerekir.

Bu yazıda RAD sürecinde geliştirdiğimiz yazılımın kalitesini arttırmak için alınabilecek bazı önlemleri anlatmaya çalışacağım. Bu önlemler hem kendi gözlemlerimden elde ettiğim, hem de okuduğum yabancı kaynaklardan öğrendiğim konulardır.

1. Etkili Hata İzleme

Bulduğumuz hataların listesini tutmak ve bunlardan bazılarını önemine göre işaretlemek yetmez. Bu hataları giderdikten sonra kesin olan şeyleri tanımlamamız lazım. Hataları giderdikten sonra şu soruları sormalıyız?.

• Problem tekrar edebilir mi?
• Yapılan düzeltme kalıcı mı yoksa sürekli kontrol altında mı tutulmalı?
• Hatanın temelinde yatan sebep nedir?
• Hatanın görülme sıklığı nedir?
• Hata en son görüldüğünde elimizdeki bilgiler nelerdi?

gibi sorunların cevapları, hata çıkma sıklığını azaltacaktır. Hatalara daha kalıcı çözümler bulmamıza olanak sağlayacaktır.

2. Alternatif Stabil Versiyonlar Belirlemek

Herhangi bir olumsuz durumda, yine ihtiyacı karşılayabilecek(daha az gelişmiş de olabilir), her yerde sorunsuz çalışabilen, daha stabil versiyonlar belirlenmeli. Böylece herhangi bir hata durumunda, diğer çalışan versiyonlara geçiş yapılabilir. Birden fazla ürün ortaya çıkacaktır ama olumsuz durumlarda müşteriler mağdur edilmeyecektir. Hatalar tam olarak giderilince, asıl geçilmek istenilen versiyona geçilebilir.

3. Riskli, Küçük Hatalar ve Stabil İşleri Birbirinden Ayırmak

Geliştirmelerin bazıları çok büyük algoritma ve akış değişikliği içeriyor olabilir. Bazıları ise küçük hata ayıklama işlemleri olabilir. Bazen de hata düzeltme yerine yeni özellikler ekleme şeklinde de olabilir. Tüm bu ayrı işleri, ayrı versiyonlarda yapmak, daha stabil bir ürün için yardımcı olacaktır.

4. Her Önemli Modül İçin Farklı Dal(Branch) Oluşturmak

Birbirini etkilemeyen her bir modül, kod versiyonlama aracında ayrı bir dalda(branch) geliştirilebilir. Böylece, birbirini etkilemeyen lokal modüller üzerinde çalışmak daha rahat olur. Birinde yapılacak olan hata düzeltme işlemi diğerinin versiyon çıkmasına engel olmaz.

Burada dikkat edilmesi gereken şey çok fazla dala ayrılan projenin yönetiminin karmaşıklaşması. Projeyi modüllere göre dallara ayırırken, modüllerin birbirinden ayrı çalıştığından ve çok fazla birbirlerini etkilemediğinden emin olunması gerekir.

5. Çıkacak Versiyon İçin Bir Yol Haritası Belirlemek

Çıkacak versiyon için yol haritası çizmek, geçmişte yapılan hataları, farklı hataların farklı versiyonları nasıl etkilediğini, en çok yapılan hataların neler olduğunu, gelecek versiyonda nelere dikkat edileceğini belirlemede çok büyük faydalar sağlar. TDD(Test Driven Development)’nin, versiyonlama karşılığı versiyon yol haritasıdır diyebiliriz.

6. Birkaç Müşteri İçin Özel Versiyon Çıkarmak

Bazen bazı müşteriler birkaç özellik isteyebilir. Bu müşteriler için ayrı bir versiyon yapılır ve diğer çalışan versiyona dokunulmaz. Yeni çıkan bu versiyon stabil bir hal aldığında, istenildiği taktirde genel çalışan versiyon bu versiyona yükseltilebilir. Genelde, müşterilerin çoğunluğu bu geçişi ister.

7. Regresyon Testi

Regresyon geriye dönmek anlamına geliyor. Yapılan bir değişiklikte sistem eski haline getirilerek tekrardan, yapılan değişikliğin bir yeri etkileyip etkilemediği kontrol ediliyor. Sistemin eski haline gelmesi demek, mesela çalışan eski versiyondaki verilere geri dönerek, yeni eklenen özelliklerle test edilmesi anlamında da olabilir. Yani değişen versiyon ile eski versiyonun testinin aynı şartlarda yapılması gibi.

8. Duraklat & Gözden Geçir

Sürekli hızlı geliştirme yöntemiyle geliştirilen yazılımların, arada bir duraklatılması ve bakımının yapılması gerekir. Hızlı geliştirmeler, hızlı çözümler üretmeyi gerektirir ve bazen hızlı çözümler, modüler ve kalıcı yöntemler yerine, o an o sorunu çözebilecek basit ve geçici yöntemlerle çözülmek istenebilir. Bu gibi durumlarda kodlar gittikçe kötüleşmeye başlar. Kötü olan yöntem üzerine devam eden geliştirmeler, işi içinden çıkılmaz hale getirir (Big ball of mud).

Yazılımın kalitesini sürekli kılmak için, proje durdurulmalı ve kodlar gözden geçirilmelidir. Daha efektif, güncel ve modüler kodlar ile güncelleme yapmak gerekir.

9. Yapılan İşlerin Farklı Geliştiriciler Arasında Kaydırılması

Farklı modüllerin sürekli başkaları tarafından yazılması, hem code-review için, hemde tüm sistemin akışının daha iyi anlaşılması için çok büyük faydalar sağlar. İlk başta biraz zaman kaybı olacaktır. Ama bu işin sürekli yapılması durumunda, tüm geliştiriciler, tüm modüllere ve sistemin geneline hakim olmaya başlar. Ayrıca birbirlerinin kodlarını görüp, daha kaliteli hale gelmesi için müdahale etmelerine de olanak sağlar. Geliştiriciler birbirlerinin kodlarının gelişmesine yardımcı olurlar.

10. Baştan Tasarımın Olabildiğince İyi Yapılması

Yapılacak olan geliştirmenin, baştan iyi bir şekilde tasarlanması, bu geliştirmenin gerekirse çizimlerle desteklenmesi, akış diyagramlarının hazırlanması gibi süreçler versiyon kalitesini artıran faktörlerdir.

Yapılacak olan işlerin, yapılma zamanlarının belirlenmesi ve bunların hangi aşamada olduğunun izlenmesi de yazılımın kalitesini artıracaktır.

NOT : Yukarıda yazdıklarımın bazıları tecrübelerimden, bazıları ise araştırmalarımdan derlediğim maddeler. Bunlar, zamanla ve kullanımla(tecrübe etmekle) standartlaşan yöntemler. Bundan dolayıda bu maddeler her ekibe uymayabilir veya daha iyi yöntemler, alternatifler olabilir. Bundan dolayı da, katılıp/katılmadığınız maddeler, dezavantajı/avantajı olan maddeler, eklemek istediğiniz yöntemler varsa, yorumlarınızla katkıda bulunabilirsiniz. Bu yazıları okuyanlar arasında gerçekten yüksek tecrübeli insanlar var. Onların fikirlerini duymak da ufkumuzu açacaktır.

Kaynaklar:
– http://martinfowler.com/articles/continuousIntegration.html
– http://www.kurumsaljava.com/2009/03/03/yazilimda-degisik-test-turleri/
– http://www.seapine.com/papers/best-practices-for-effective-defect-tracking
– http://www.laputan.org/mud/mud.html#BigBallOfMud