Çarşamba, Ağustos 17, 2011

Açık Kaynak Projeler Nasıl Geliştirilmeli?

Biz programcı milleti kod yazmaktan ve kod üzerine muhabbet etmekten çok hoşlanırız. Birbirini daha önce hiç tanımayan iki programcı yan yana geldiklerinde çok kısa zaman içinde kaynaşırlar ve hemen dillerden, araçlardan, çalışma yöntemlerinden falan konuşmaya başlarlar. Bu nedenle internet üzerinde programcıların en iyi sosyalleşebildiği ortamlar açık kaynak projelerdir. Ortada herkesin ilgi duyduğu bir proje varken muhakkak konuşacak birşeyler çıkar.

Ben her programcıya konusu ne olursa olsun bir açık kaynak projeye sahip olmalarını ve başka açık kaynak projeleri olan programcıların projelerini ziyaret ederek iletişim kurmalarını, karşılıklı yardımlaşmalarını tavsiye ediyorum. Bunun amacı para kazanmak değil. Amaç sosyal ilişkileri geliştirmek, yeni insanlarla tanışmak, yeni şeyler öğrenmek, yeni fikirler keşfetmek, vs.

Açık kaynak bir projenin yaşaması ve gelişmesi topluluk ilgisini çekebilmesi ile ilgilidir. Bu nedenle açık kaynak projeler şu özelliklere sahip olmalıdır:

1. Açık kaynak projelerin can alıcı noktası projenin temel işlevinin çok kısa sürede çalışır hale getirilmesidir. Yani projeniz her an kolayca kurulabilir ve x bir işi yapabilir durumda olmalıdır. Örneğin bir e-ticaret sitesi yapacaksanız projeyi denemek isteyen kişi hemen çalışan bir demo site üzerinde inceleme yapabilmeli, eksik noktaları görebilmeli ve projenin çalışmak isteyip istemeyeceği bir proje olup olmadığını hızlıca inceleyebilmeli. Programı kullanmak isteyecek kişiler de basitçe programı bilgisayarlarına kurup birkaç dakika içinde denemelerini yapabilir duruma gelmeli.

2. Kodlar her zaman derlenebilir olmalıdır. Kodları indiren bir kişi için en büyük hayal kırıklığı kodların derlenmemesi veya hemen çalışır hale getirilememesidir. Kimse yapacağı küçücük bir değişiklik için saatlerce kurulum problemlerini çözmekle uğraşmak istemez.

3. Projenin aktif bir koordinatörü olmalıdır. Her projenin bir Linus Torvalds'a ihtiyacı vardır. Zaten ilk başta projenin en temel işlevini de büyük oranda bu kişi kodlar. Diğer programcılar projeye katkıda bulunmaya başladıktan sonra koordinatörün temel görevi diğer programcıların gönderdiği güncellemeleri veya patch dosyalarını birleştirmek olacaktır.

4. Eğer bir şirket ortamı gibi sürekli beraber çalışılmayacaksa kişiler arasında iş bölümü yapılmamalıdır. Hatta abartıp "her gün x saat projede çalışılacaktır" gibi gereksinimler koymak hiç doğru değil. Kimse projeyi yarı yolda bırakan kişi olmak istemez. Bu nedenle programcılar bir gün çalışamama ihtimalini göz önüne alarak baştan işe girmek istemeyecektir. Dileyen her programcı projeye katılmakta, istediği kadar süreyle ve istediği şekilde çalışmakta ve çalışmaya ara vermekte özgürdür. Elbette proje ilerledikçe ve gerçek hayatta kullanılmaya başladıkça sorumluluk almak ve sürekli çalışmak isteyen kişiler olacaktır.

5. Güven ortamı sağlamak çok önemlidir. Bu nedenle imkanlar olsa bile projeler özel sunucular yerine codeplex veya googlecode gibi popüler açık kaynak geliştirme ortamlarından biri üzerinde geliştirilmelidir. Bu ortamlar katılımcılara kendi kod yedeklerini oluşturabilme şansı verirler. Böylece proje koordinatörünün birine kızıp projeyi kapatması veya sunucu çökmesi gibi hoş olmayan durumlar yaşanmaz.

Bunlar olmazsa olmaz özellikler. Elbette dökümantasyon hazırlanması, otomatik test sistemlerinin geliştirilmesi, bir genel bir de detaylı planlama yapılması gibi işler projeye değer katacaktır.

Peki sistem nasıl işler?

Git veya mercurial gibi distributed versiyon kontrol sistemlerinin geliştirilmesi ile çok sayıda programcının tek proje üzerinde çalışabilmesi imkanı doğmuştur. Lock mekanizması içermeyen bu sistemler üzerinde çalışırken genellikle uygulanan temel mantık şudur.

Projenin en önemli giriş noktası "Issue" listesidir. Bu listeyi hem programı yazanlar hem de programı kullananlar oluştururlar. Bu listede hata raporları ve yeni özellik istekleri bulunur. Issue bir programcının ideal olarak bir veya iki saatlik bir sürede tamamlayabileceği büyüklükteki bir iş parçacığıdır. İlk Issue'lar temel roadmap planının ilk milestone'unun daha küçük işlere bölünmüş halidir. Bu liste zamanla yeni fikirler ve bug raporları eklendikçe oturur ve programcılar yapacakları işleri ilgi alanlarına ve o anki boş zamanlarına göre bu listeden seçerler.

Ana projeye kod ekleme yetkisine sadece proje koordinatörleri sahiptir. Kod güncelleme yetkisine sahip olmayan diğer programcılar kendilerine ait kopyalar üzerinde çalışırlar. Bu kopyalara kimi sistemlerde "fork" kimilerinde de "clone" adı verilir. Fork başka anlamlara da geldiği için genellikle "clone" tanımı tercih edilir.

Diyelim ki bir x projede bir iş yapmak istiyorum. İş listesinden seçtiğim işi yapmaya başlamadan önce hiç kimseye sormadan projenin kendi adıma bire bir kopyasını oluştururum ve bu kopyayı bilgisayarıma indiririm. Kendime ait "clone" üzerinde sınırsız güncelleme yetkim vardır. Seçtiğim "Issue" ile ilgili yapacağım işim bittiğinde "clone"u günceller ve koordinatöre bir "pull request" gönderirim. Pull Request'in açıklamasına yaptığım işlerin ID numaralarını eklerim ve gerekiyorsa ek açıklamalar da yazarım. Koordinatörlerden biri yaptığım değişiklikleri inceler ve uygun görürse yaptığım değişiklikleri ana proje ile "merge" eder. Tortoise HG gibi popüler cilent programları koordinatör için bu işleri oldukça kolaylaştıran araçlar içerirler.

Gönderdiğim değişiklikler birleştirildikten sonra kendime ait klonla işim bittiği için bu klonu silerim. Başka bir zamanda yeni bir işe başlayacağım zaman tekrardan bir klon oluştururum. Bu yeni klon geçen süre boyunca diğer programcıların yaptığı ve ana proje ile birleştirilen değişiklikleri içerecektir. Süper mantık değil mi? Aslında ana proje dediğimiz şey "head" denilen dalın kendisidir ancak bu dal mekanizması ile ilgili detaylara sonra girelim. Zaten her projede bu mekanizma topluluk yapısına göre farklı mantıklarda kullanırlar.

Burada en çok dikkat edilmesi gereken konu bir klonu uzun süre aktif bırakmamaktır. Klon aktif olduğu süre boyunca ana kod üzerinde yapılan değişikliklerin çok olması başka programcıların yaptığı işlerle çakışma olmasına ve "merge" işleminin zorlaşmasına neden olabilir. Bu nedenle uzun sürecek işler daha kısa sürede yapılabilecek işlere bölünmelidir.

Umarım süreçle ilgili yeterince açıklayıcı olabilmişimdir. İlgi duyan herkesi sambapos.com adresindeki açık kaynak restoran programı projesine davet ediyorum.

Hiç yorum yok: