Selamün Aleyküm;

Bildiğimiz gibi Github vb. platformlardan yazılım projelerinin kaynak kodlarına ulaşabiliyoruz. Benim sualim ise dünyada birçok yazılım projesi ekipler sayesinde geliştiriliyor lakin kodları nasıl geliştirmeye açık tutuyorlar? Ya da daha doğrusu biz bu kodları geliştirmek istesek (yani yazılımı) bunların neresinden başlamamız gerekiyor? Çünkü bir yazılım kaynak kodları neredeye sayılamayacak kadar çok. Geliştirici neresinden yazılım çalışma prensibini anlamaya başlıyor? Mesela Android'in Github'dan kodlarına baktığımızda sürüsüyle farklı klasörler var ve içlerinde aynı şekilde sürüsüyle farklı .c, .cpp, .java vs. dosyalar var. Geliştirici bu kodları nasıl okuyup anlayabiliyor? Tahminimce geliştirmekten ziyade kodları okuyup anlamakla mı zamanını harcıyor? Bu iş nasıl yapılıyor? Teşekkürler.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Cevabınız için teşekkür ederim.
Peki bu yaptığımız irili ufaklı geliştirmeleri Github'da onaylayan kişi veya kişiler o kodun doğru çalıştığını nasıl anlayabiliyorlar? Yani bunun için bir anlatım falan mı yapmamız lazım? Aksi halde onaylayan kişiler koca bir projeyi her seferinde yeniden derlemek zorunda kalabilir ya da kod gözle denenemeyecek kadar karışık olabilir -ki bu madde doğru mu onu bilmiyorum :)-.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (İbrahim:1464183105):

Herhalde en iyisi, bir yanlışlığından veya eksikliğinden haberdar olmak ve gidermek istemektir.

Yakın zamanda yaptığım ve şimdiye kadarki elle tutulur tek açık kaynak katkım, bir arkadaşın isteğiyle oldu: Redis sunucusunu Tiny-Redis modülü ile kullanıyordu ama Tiny-Redis Redis'in "subscribe" ve "publish" komutlarını henüz desteklemiyordu.

Arkadaşım benden yardım istedi, ben de ekledim. İlgisiz olarak, şu:

https://github.com/acehreli/Tiny-Redis/commit/3818eb15afe5378f3cdd9b0c9483b3026a2408bd

Başka bir fikir, projelerin hata bildirimlerine (issues) bakmak ve kolay görünenlerini çözmek olabilir.

Alıntı:

Bu konuda çok etken var: deneyim (örneğin, hangi dosyaların ne barındırdığı), o belirli konuya yatkınlık, hata bildiriminde zaten söylenmiş olması (örneğin, birisi "bunu çözmek için şu dosyada şunu yapmak gerek" demiş olabilir), proje üyelerine soru sormak :), vs.

Alıntı:

Doğru, projesine göre anlamak çok uzun sürebilir.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (İbrahim):

Kodu bildikleri için değişikliğin etkisini görebiliyorlar diyelim.

Alıntı:

İyi kod zaten anlaşılır olarak yazılır. ;) Kolay anlaşılamayan yerlerinde de açıklamalar bulunur. Bunun üstüne, evet, kod için pull request yapıldığında güzel bir açıklama çok yararlı olur.

Alıntı:

Kesinlikle derlenmesi şart tabii ki. dmd gibi bazı projelerin otomatik testleri de oluyor. Birisi pull request yaptığında o kodun var olan testleri geçip geçmediği öyle biliniyor.

Alıntı:

O kod reddedilir. :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ali hocanın bahsettiği testi gerçekleştiren araçlardan bir tanesi Travis CI.

Pull request yapıldığında (örn https://github.com/dlang/dmd/pull/5829) Travis CI gibi araçlar ile (https://travis-ci.org/dlang/dmd/builds/134469430) otomatik olarak kod test edilir. Test dosyaları çalıştırılır ve yapılan pull request projede başka bir özelliği bozup bozmadığı ortaya çıkar. Bu testten geçmeyen pull request leri pek kaale alacaklarını sanmıyorum :)

https://travis-ci.org/ adresini ziyaret edersen travis ile alakalı detaylı bilgi alabilirsin.

Zekeriya

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]