Bölüm 4) Test aşamasına geçiş
Geliştirme süreçlerinde özellikle yazılımın kodunun paylaşılması ve gözden geçirilmesi yazılımın kararlılığı açısından önemlidir, söz dizimi kurallarından, problemlerin çözümleri için izlenen yollara kadar, yazılımın gözden geçirilmesi gelişim sürecinin ve büyümenin bir parçasıdır. Özgür yazılımlar kamu'nun desteği ile bu problemleri geniş bir zamana yayarak geliştirme süreci ile aynı anda yapmaktadır, ancak eğer uygulamanız kamuya açık değil ise bu süreç için kaynak ve zaman ayırmalısınız. Bu ayrılan zaman gözünüzde zaman kaybı olarak görülebilir ancak hata tespiti ve düzeltmesi süreçlerini hızlandırdığı bir gerçektir, dolayısı ile zaman kaybı değil bir kazançdır.
Uygulamaların geliştiriciden çıkıp son kullanıcıya ulaşma süreci bir dizi işlemi de yanında getirir bunlar; test, bugfix, ve kurulum işlemleridir. Buradaki en zor işlem ise kaynak kodun "derlenerek" test veya ürün sistemine girmesidir. Genel olarak bu işlem 3 adım içermektedir, depodan testi yapılacak uygulamanın kaynak kodunun alınması, paketlenmesi, test sistemine kurulması.
En çok hata ise kurulum sırasında yaşanmaktadır. Tüm bu süreçleri otomatikleştirmek ve tek bir noktadan yönlendirmek, kaynak kodun ürün sistemine girerken kurulum aşamasında yaşanan problemlerin önüne geçecektir.
Geliştirilme yapılan deponun depo yöneticisi veya sürüm yöneticisi tarafından dondurulması sonrasında kaynak kod içerisinde yer alan derlenmesi gereken uygulamalar derlenmeli, oluşan kütüphane ve dosyalar paketlenmeli ardından test sistemine gönderilerek paketin kurulması işlemleri tek bir buton'a tıklama ile veya bir komut çalıştırılarak yapılabilmelidir.
Bu sistemin oluşturulması ve tasarlanması tamamen uygulamaya bağımlıdır, sadece web sayfası için, örneğin geliştiricilerin yazdıkları javascript dosyaları birleştirildikten sonra minifiy edilmesi, css dosyalarının minify edilmesi işlemleri gibi. Günümüz koşullarında bir web uygulaması basit bir web sayfası olmaktan çıkmış yüzlerce ve hatta binlerce bilgisayar tarafından işlenen verilerin biz kullanıcılara anlaşılır bir dil ile gösterilmesi haline dönüşmüştür. Bu noktada sadece web arayüzü için bir script dili değil, arka planda çalışan pek çok farklı dil ile hazırlanmış uygulama söz konusudur. Bu uygulamalarında derlenerek sırası ile paketlenmesi, test sistemine kurulması ve ardından ürün sistemine aktırılması gerekmektedir. Uygulamanın paketlenmesinden kastım, örneğin sisteminizde linux kullanıyor, dağıtım olarak ise debian seçmişseniz tüm kaynak kodun derlendikten sonra deb paketi haline getirilmesidir. Böylece kurulum öncesinde veya sonrasında yapılması gereken işlemler paket yönetim sistemi tarafından yapılacaktır. (örneğin kurulum sonrası cache sisteminin temizlenmesi)
Test ortamı üzerine kurulan yeni uygulama sadece hata düzeltmeleri içerebildiği gibi yeni özelliklerde içerebilir. Test takımı bu değişikliklerin neler olduğunu hata yönetim sistemi üzerinden bilgilendirildikten sonra test etmeli, bulunan hatalar hata takip sistemi üzerinden geliştiricilere bildirilmelidir. tespit edilen hatalar geliştirici takım tarafından düzeltildikten sonra tekrar test takımına teslim edilmeli ve her hangi bir hataya rastlanmamış ise ürün sistemine geçiş süreci başlatılmalıdır.
Uygulama geliştiricileri her ne kadar unit test yazmaktan pek fazla hoşlanmasa da, bu unit testler sayesinde uygulamanın test ortamından ürün ortamanına geçişini hızlandırabilirler, ve eğer bir geliştirici iseniz emin olun unit testler sayesinde proje lideriniz yazılım hataları konusunda başınızı ağrıtamayacaktır 
Bölüm 3) Hata takip sistemleri
Dökümantasyon ve kaynak kod yönetimi gibi problemler ekip içerisinde çeşitli araçlar ve yöntemler ile çözüldükten sonra bir başka sorun kendini göstermeye başlar, problemlerin takibi ve çözümü, kaynak kod ve proje büyüdükçe problemlerin tespiti ve giderilmesi bir kaç dakikadan saatlere, günlere ve hatta daha uzun süren bir zamana yayılmaktadır.
Geliştirici hangisini yapacağına tam olarak karar veremez ve işin hep en zevkli tarafını yani yeni özelliklerin eklenmesini tercih eder. Bu tercih ise geçmişte yaşanan problemlerin ve/veya çözümlerin unutulmasına ve daha büyük sorunların çıkmasına neden olur. Bu durumu önlemek için tavsiyem kaynak kod yönetim yazılımınız ile entegre çalışabilen bir hata takip sistemini devreye almanızdır.
mozilla tarafından geliştirilen bugzilla, edgewall grubu tarafından geliştirilen trac, tigris grubu taranfından geliştirilen mantis bu uygulamalardan sadece bir kaçıdır.
Bugzilla
mozilla tarafından geliştirilen bu yazılım perl kullanarak hazırlanmıştır, modüler yapısı sayesinde subversion ve cvs'in commit hooklarına eklenen ufak scriptler sayesinde her iki kaynak kod yönetim sistemi ile entegre çalışabilir.
Trac
edgewall tarafından özgür olarak geliştirilen ve modüler yapısı ile subversion'ı hedef alarak geliştirilmiş bir hata takip sistemidir, küçük ve orta ölçekli subversion kullanılan her proje içerisinde kullanılabilinir. Subversion ile entegrasyonu sayesinde commit mesajları ile her hangi bir hata kaydı kapatılabilinir. içerisinde dahili olarak subversion için web arabirimi, hata takip sistemi ve wiki hazır olarak gelmektedir böylece tüm projedeki gelişmeler tek bir adres ve arabirimden geliştiricilere, katkıcılara, testçilere ve hatta kullanıcılara ulaştırılabilinir.
Mantis
Php ile yazılmış bu hata takip sistemi sadece hata takibini sağlamak için geliştirilmiştir, subversion veya cvs için commit hook'larına eklenen ufak betikler sayesinde kaynak kod yönetim sistemleri ile entegrasyonu sağlanabilir.
Redmine
Pek çok farklı kaynak kod yönetim sistemi ile entegre çalışabilen ve ruby ile geliştirilmekte olan bir takip aracıdır, çoklu dil desteği, forum, wiki, hata izleme sistemi, takvim ve birden fazla proje için kullanılabilmesi ile dikkat çekmekte olan başarılı bir araçtır. Tıpkı trac gibi geliştiricilerin, katkıcıların tek bir adres üzerinden rss ile takibini mümkün kılmaktadır.
Zaman içerisinde sağlıklı ve kararlı bir büyüme gerçekleştirmek istiyor iseniz işe en başından projenizin yazılımsal kontrolünü elden bırakmadan yapmak zorundasınız. Uygulamanızın daha fazla kişi için erişilebilinir olması, uygulamanız, iş modeliniz, sermayeniz ve kullanılacak teknikler ile değişiklik gösterebilir, ancak kaynak kod yönetimi ve hata takip sistemi gibi "genel yapılar" geliştirme sürecinde değiştirilemez parçalarıdır. Bu neden ile bu başlıklar "ölçeklenebilir yazılım geliştirme" altında bulunmaktadır. Yukardaki uygulamalar irili ufaklı hemen hemen her projede kullanılması gereken, iş gücünün dağıtımını ve yönetimini başarı ile yapabilmenizi sağlayan araçlardır. Bir projenin büyümeyi planlayabilmesi için öncelikli olarak geliştiricilerine yukardaki araçları tanıyabilmesi ve kullanabilmesi için gerekli eğitim ve zamanı tanıması gerekmektedir.
Bölüm 1) Dökümantasyon
Türkiye'de özellikle yazılım üzerine eğitim almış kişiler, eğitim yöntemleri nedeni ile hep bireysel çalışmaya odaklılardır. Bunun sonucu olarak tek tabanca tüm yazılımı tamamlamak normal bir şey gibidir. Bu yüzden yazılımın dökümantasyonuyla ilgili pek fazla çalışma yapılmaz, bu nasıl yapılır, ne tür araçlar kullanılır bilinmez. Eğer bir startup için bir yazılımcı ile anlaşacaksanız sormanız gereken şeylerden biri kullanılacak olan dili'de dikkate alarak örn: PHPDoc, JavaDoc gibi yazılımın kaynak kodu üzerinden dökümantasyon çıkartmak için kullanılan söz dizimi hakkında bilgi sahibi olup olmadığı, daha önce bu tür bir şey yapıp yapmadığı olmalıdır. Bu söz dizimleri öğrenmesi oldukça kolay ve sadece 5 dk. alacak şeylerdir dolayısı ile bilip bilmemesi pek fazla sorun değil ancak bu sorumluluğunun farkında olması açısından önemli bir göstergedir.
Bir proje yaşadığı sürece pek çok farklı yazılımcı dahil olacak veya ayrılacaktır, ayrıldığında projenin devam edebilmesi ve yeni gelen yazılımcıların hızlıca projeye dahil olması açısından önemli bir ayrıntıdır aksi halde her yeni katılan yazılımcı tekerleği yeniden hazırlayacaktır. Aşağıda görebileceğiniz gibi kaynak kod üzerinden dökümantasyon oluşturmak aslında oldukça kolay bir işlemdir. Her ne kadar örnek PHP ve PHPDoc üzerinden verilmiş olsada hemen hemen her dil için benzeri araçları bulmak yada uygulamak mümkün.
Söz dizimi: /** * String sınıfı string işlemleri ile ilgili * doğrulama ve ayıklama işlevlerini yerine * getirmek amacı ile hazırlanmıştır. * @package projectname * @subpackage dogrulama */ class String { /** * parametre olarak verilen string içerisinde eğer var ise * 0-31 ascii kodu arasındaki kontrol karakterlerini siler * ve temizlenmiş string verisini geri döndürür. * {@source 3 1} * @param string $string kullanıcıdan gelen string veri * @return string kontrol karakterlerinden arındırılmış string veri * @access public */ static public function clearControlChars($string) { return preg_replace('#\p{C}#u', '', $string); } }
Projenin kod tabanındaki dökümantasyon proje büyüdükçe önem kazanmaktadır, yeni katılan geliştiricilerin başları sıkıştıkça bakabilecekleri bir kaynak bulunması geliştiricileri oldukça rahat hissettirecektir. Dökümante edilmemiş bir kod yığını içerisinde yeni bir geliştirici her hangi bir sorunun kaynağını ararken veya yeni bir geliştirmeyi eklerken kullanabileceği araçları tam olarak bilemeyeceğinden dolayı bunun için en kısa yol olan "bir bilene soralım" yolunu izleyecektir, bu durum daha tecrübeli olan geliştiriciyi çalışırken bölmek ve dikkatini dağıtmak anlamına gelmektedir, dikkati dağılan geliştirici tekrar konsantre olmak için bir süre oyalanacak ve ilerleyen zamanlarda bu durumun devam etmesi geliştirici üzerinde huzursuzluğa neden olacaktır. Diğer bir durum, yeni katılan geliştirici soru sormak yerine çözümü kaynak kod içerisinde aramayı denemesidir, ancak bu da çok fazla zaman alacaktır ki bir süre sonra ne aradığını hatta neden aradığını bile unutabilir. (kendimden biliyorum ) yukarıda bahsedilenler, dışarıdan bakıldığında gelişticinin suyu çıkıncaya kadar çalıştırılacağı veya çalıştırıldığı izlenimini verebilir ancak anlatılmak istenen, dikkat dağıtıcı unsurları azaltmak veya problemlerin cevaplarını kolayca bulmanın yolları var iken bunların görmezden gelinmemesidir. İyisimi siz dökümantasyona önem verin.
(Yazar) Sevgili günlük...
(Günlük) Sizin yolunuz pek sık düşer oldu, hayırdır?
(Yazar) Geçmi kalıyorum?
(Günlük) Geç kalmıyorsun, gitmesini, geçmesini bekliyorsun, bekleme...
yazılım geliştirme ve ölçeklenebilirlilik
Projeler ve yazılım ayrılamayan ikilidir, projeleri gerçekleştiren kişilerin kullandığı diller ve teknolojiler, projenin veya fikrin gerçekleştirilmesini sağlayan yazılımı oluştururken aynı zamanda projenin biçimlenmesinde kimi zaman olumsuz kimi zaman olumlu katkıda bulunurlar.
Türkiyede özellikle yoğun trafik yaşayan web projelerinin azlığı, yazılımcıların ilgi ve tecrübesinin olmamasını pek çok başarılı olabilecek projenin henüz daha doğmadan yok olmasına neden oluyor. Şöyle düşünün, dailymotion yada youtube daha henüz oluşturulmamış iken bir fikir sahibi olarak (teknik bir kişi olmadığınızı var sayarak) online video sitesi kurmak geldi ve çeşitli gelir modelleri belirlediniz, etrafınızdaki yazılımcılardan bu işin yapılabilinirliliği hakkında bilgi ve fiyat almak istediğinizde size bir kaç çözüm ile birlikte bir kaç fiyat çıkartılacaktır, sizde güvendiğiniz ve cebinize uygun fiyatı veren yazılımcı veya yazılımcı ekip ile yola çıktınız.
Projeniz bittiğinde ise aslında sizin elinizde olan sadece yapılacak iş için yapılabilirliliğine ait bir kanıt niteliğinde ürün oldu ancak siz henüz bunu fark etmediniz, fark etmenizi sağlayacak senaryo ise:
ilk haftada saniyede 100 request almaya başladınız, sisteminiz afalladı çünkü yazılımcılarınız ne yazıkkı ölçeklenebilirlik hakkında pek fazla bilgiye sahip değillerdi, dağıtık dosya sistemi için nfs kullanıldı çünkü daha bilinir ve daha kolay geldi, sabit içerikleri ayırmadınız, ön bellek sistemi dosya dizin seviyesinde kaldı, oturum yönetimi dosya dizin seviyesinde çalışıyor. veri tabanına yapılan sorgular önbelleklenmediği ve kimi update işlemleri için (gösterim arttırımı veya azaltımı) veri tabanına erişim yapılıyor. Tüm bu unsurların sonunda sisteminiz gelen trafiğe yanıt veremeyecek duruma gelebilir. Problemi aşmak için büyüme kaçınılmaz ancak nasıl?
Yeni çıkmış bir servisin birden bu duruma düşmesi oldukça kötü olacaktır, bu neden ile yazılım ekibinizin veya yazılımcınızın bu unsurları en başta düşünmesi ve tedbir alması gerekmektedir.
Bu unsurlara göre yazılım tasarımı nasıl olmalıdır? Kullanılabilinir araçlar, teknikler ve teknolojiler nelerdir? Büyüme problemleri, çözümleri ve maliyeti ile ilgili bir süre yazmak bir şeyler "zırvalamak" istiyorum, umarım faydalı olur.
(Yazar) Sevgili günlük...
(Günlük) beni hatırladığına sevindim, efendim?
(Yazar) Yanlış mı yapıyorum sürekli?
(Günlük) Hayatın içerisinde yapılanlar, yapıldıkları sırada yanlış değildir, bu yüzden şimdi düşünme ilerde düşünürsün.