Açık kaynaklı projelerde kod incelemeleri var mı? Öyleyse, bunu yapmak için hangi araçlar kullanılır?

Ticari gelişimde kod incelemeleri için büyük bir itici güç olduğunu biliyorum. Ancak, kod incelemeleri açık kaynaklı yazılımlarda mı kullanılıyor yoksa güvene mi dayanıyor? Eğer öyleyse, nasıl yapılır? [Gecikmiş bir taahhüt, “ön taahhüt ortamı” mı, yamanın başka bir geliştiriciye gönderilmesine izin veren bir araç var mı?

Kod incelemelerini kullanan herhangi bir proje var mı?

Anladığım kadarıyla, Linux çekirdeği çoğunlukla taşıtın güvenine dayanmaktadır. MySQL, ana yazarın onayına ve performans etkisine dayanıyordu.

Hemen hemen tüm açık kaynaklı projeler, bir kişinin veya bir grup insanın resmi yapıya geçmek için tüm değişikliklerden çıkış yapması gereken bir tür bekçi iş akışı kullanır. Linux çekirdeği gibi bazı daha büyük projelerin ağ geçidi denetleyicileri katmanları vardır. Bir alt sistemin bir alanını yöneten birine bir değişiklik gönderirsiniz, değişikliklerini tüm bir alt sistemi yöneten birine gönderirsiniz ve değişikliklerini bazen kodu kendisi gözden geçiren veya bazen teğmenlerine güvenen Linus Torvalds'a gönderirler. Bu incelemelerin genellikle resmi bir yapısı yoktur. Birleştirilmeden önce kodu inceleyen biri.

Aletlere gelince, iyi bir örnek için github'daki çekme talebi mekanizmasına bakın. Bir çekme isteği yaparsınız ve bu çekme isteğine adanmış bir web sayfasında insanlar yorum yapar ve yazar kabul edene kadar revizyonlar yapar. Diğer ağ geçidi denetleyicileri, posta listelerinden yama uygulamak için ya da git gibi DVCS'lerin icat edilmesinin ana nedenlerinden biri olan halka açık depolardan çekme isteklerini birleştirmek için yalnızca düz git'i kullanır.

Açık kaynak projelerinde, genellikle proje iş akışının ve katkıların nasıl kabul edildiğini (ve dolayısıyla nasıl test edildiğini) açıklayan açık bir şekilde yayınlanan "topluluk yönergeleri" kümesi bulunur (ve içermiyorlarsa). çekirdek bir komutan olma süreci olarak.

Kod incelemesine gelince, yine topluma bağlıdır, ancak kurallar genellikle açıklığa kavuşturulmuştur. Taahhüt etmeyenlerin katkılarına ilişkin bazı örnek yönergeler "çalışma kodu kazancı" ndan "katkıların tam test kapsamına ve belgelerine, testlerin kodla aynı zamanda yapıldığı" ve aradaki her şeye sahip olması gerekir; bu yönergelere bakılmaksızın, ima edilen bir kılavuz, ana komisyon üyelerinin kabul etmeden önce komisyon üyesi olmayanların katkılarını gözden geçirecek olmasıdır.

Çekirdek komite gruplarına sahip açık kaynak projeleri de genellikle ekstra gözlere ihtiyaç duyabilecek katkıları tartışmak için sanal toplantılara veya özel bir zamana sahiptir - tıpkı bir soru kapatılmadan önce belirli bir itibara sahip kullanıcıların birden fazla yakın oylama SE süreci gibi, ve şüpheli şeylerin meta veya sohbet yoluyla tartışılması.

En iyi bildiğim projeler için bazı topluluk belgelerine birkaç hızlı bağlantı, burada bu projelere özgü sorunuzun cevaplarını bulabilirsiniz (yakında bir tema göreceksiniz):

• Project Blacklight topluluk ilkeleri
• DSpace kod katkısı yönergeleri
• Apache katkıda bulunanlar teknik kılavuz

Daha büyük OSS projelerinde bir dizi temel komisyon olacak. Yani onlar de-facto "kod yorumcular" sanırım.

Ayrıca, OSS kodu doğası gereği herkese açık olduğundan, yazdığınız kod hakkında çok daha fazla tartışma olması muhtemeldir. Bu resmi kod incelemeleri şeklinde olmasa da, kodunuzun belirli bir OSS projesi için çizilmeye kadar düşünülmediğini kesinlikle öğreneceksiniz.