Dahili kod bir kuruluştaki geliştirici olmayanlarla paylaşılmalı mıdır?

Çalıştığım yerde, hem geliştiriciler hem de personel ve müşteriler tarafından kullanılan özel uygulamalarımızı çalıştıran çok sayıda kod var.

Ayrıca, müşterilerimizi daha iyi desteklemek ve hatta zaman zaman bir yama göndermek için sistemlerimizin iç işleyişini anlamaktan çok fazla akıllı destek ekibimiz var.

Geliştirme ekibimizin okuyabilmesi için kodumuzu açmalı mıyız? Bu kararı verirken hangi faktörleri dikkate almalıyız? Her şekilde bir sürü argüman ve karşı argümanla karşılaştım ve başkalarının deneyimlerine ve iyi anlaşılmış risklere dayanarak bir karar vermek istiyorum.

Şimdiye kadar bazı argümanlar:

• VCS'deki şifreler ortaya çıkar (çözüm: şifrelerden kurtulun - başlamak için orada olmamalıdırlar)
• Kod beyaz kutu güvenlik saldırılarına açıktır (karşı argüman: bu sadece dürüst / tembel saldırganları uzak tutar)
• Destek personeli, geliştiricilere işlerin nasıl çalıştığını sorabilir (sayaç: adama balık tutmayı öğretin, vb.)

Kodunu kuruluşlarındaki personele açan var mı? Herhangi bir soruna neden oldu mu?

Bunun genel bir cevabı olduğunu düşünmüyorum. Kuruluşlar, büyüklükleri, coğrafi dağılımları, şirket kültürleri, telif hakkı politikaları, geliştirilmekte olan yazılımlar vb.

Örneğin, meta / altyapı tipi yazılım geliştiren bir şirket için, Cisco'nun yazıcı sürücüsü yazılımıyla (IIRC) birkaç yıl önce yaptığı gibi, kaynak kodunu açmak, hatta açık kaynak koduyla açmak kolay olabilir.

Bazı nadir tescilli yazılımlar geliştiren bir şirket için, potansiyel olarak, rakiplerine karşı rekabet avantajı sağlayan özel algoritmalar veya şeyler dahil, kodlarını gizli tutmak için çaba gösterip göstermediklerini çok iyi anlayabiliyorum. Örneğin, AFAIK Google, temel arama algoritması uygulamalarına erişim izni verilen kişilerin sayısını kesinlikle sınırlar.

Ayrıca çok uluslu bir organizasyon günümüzde birçok ülkeye, zaman dilimine ve kültüre yayılmıştır ve güvenlik nedeniyle muhtemelen intranetlerini bölümlere ayırırlar ve farklı bölümler / alanlar arasındaki trafiği kontrol etmek için güvenlik duvarları kullanırlar. Dolayısıyla, bir SCM repo'yu "tüm şirkete" uygun hale getirmek aslında sistem yöneticileri için fazladan çalışma ve ekstra güvenlik riski gerektirebilir. Genel olarak herhangi bir fayda sağlamaz, ancak farklı bir kıta üzerinde tamamen farklı şeyler üzerinde çalışan işverenler muhtemelen projemizi bile bilmiyorlar, buna olumlu katkıda bulunmak için çok daha az.

Bu yüzden bölümünüz içinde ve / veya bir şekilde projeyle ilişkili kişiler için mantıklıysa , neden olmasın. Ama genel olarak, sadece "açıklık" uğruna buna değdiğinden emin değilim.

Son bir not: Destek çalışanları yamalara katkıda bulunmak için akıllı ve istekli olsalar bile, katkılarının sisteme entegre edilmeden önce her zaman bir geliştirici tarafından incelenmesi gerektiğini söyleyebilirim.

Çalıştığım çoğu kuruluşta, kod deposu tüm geliştiricilere açıktı.

Bazılarında, belgeleri yazılımla birlikte versiyonlamak için belgeleri (özellikler ve gereksinimler gibi) saklamak için de kullanılmıştır. Bu durumda diğer çalışanların çoğunun da erişimi vardı. Repo sadece kod için kullanıldığında, geliştirici olmayanlar genellikle erişime sahip değildi - ama kimsenin şikayet etmediğini hiç duymadım, bu yüzden muhtemelen her iki şekilde de büyük bir anlaşma olmadı.

Mümkün olduğunca açıklık öneriyorum - bu yüzden insanlar erişim isterse, bariz bir sorun olmadığı sürece onlara verin. Ama bu gerçekten organizasyonun kültürüyle ilgili bir soru ...

Bununla ilgili genel / pragmatik bir görüş paylaşıyorum ve ayrıca işin / organizasyonun doğasına da bağlı olabilirim. Ama kod tabanının herkese açık olması gerektiğine inanıyorum (ayrıca organizasyon içinde açıklık ve güven de gösterecek).

Ayrıca, müşteri istekleri ile ilgilenen bir destek / yardım masası ekibimiz olduğu gibi, benzer bir kurulumda da çalışıyorum. Ancak sistemin bazı karmaşık alanları ek yardım gerektirir. Benim durumumda kod tabanı herkese açık, herhangi bir sorunla karşılaşmadık.

• Kod tabanını açarak istekli olan diğer destek ekibi üyeleri de kod tabanını kontrol edebilir ve ilgilendikleri veya cevap bulmaları gereken iş kurallarına / alanlarına aşina olabilirler (ve muhtemelen teknik anlayışlarını geliştirebilir ve bir şeye bakabilirler) zaman izin verirse monoton rutinden farklı;)). Bu, destek ekibi üyeleri müşteri sorunları ve günlükleri aldığında ve yığın izine bakarak (örneğin açıkça soruna bağlı olacaktır) kodun olası alanlarını işaret edebildiklerinde / yardımcı olabildiklerinde de yararlı olabilir. Bu aynı zamanda geliştirici ile zamandan tasarruf edecektir, ancak elbette probleme bağlı olarak.

Ayrıca, ürünün tüm iş kurallarını / kararlarını içeren güncel bir belgelere / wiki'ye sahip olması da yardımcı olacaktır. Ancak elbette, wiki'nin yeni geliştirmeleri ve / veya hata düzeltmelerini (davranışların değiştiği yerlerde) gidermek için sürekli olarak güncellendiğinden emin olmanız gerekir. Dürüst düşüncelerim

Genel olarak, organizasyon açısından - insanlar gelir ve gider; proje (veya ürün) gelişmeye devam etmelidir. Bu nedenle, çoğu organizasyonda, genellikle kodu korumak için tüm depolara bir Açık vardır.

Genellikle fark edilmeyen yetkisiz erişimi (kod hırsızlığını önlemek vb.) Önlemek için erişim hakları vb. Vardır, ancak çoğu yüksek up gerçekten bu konuda engellenmez. Bir kuruluşta, insanlara kodla güvenebileceğiniz kişilere (yeterli) güvenmek gerekir. Kodları çalışanlardan (veya iş arkadaşınızdan) gizlemek, motivasyonu büyük ölçüde etkisiz hale getirir.

Kuruluşumuzda, insanlar koda gerçekten katkıda bulunmasalar bile - yardımcı olan koda doğrudan erişimleri vardır, çünkü yardımcı olan şeyleri geliştiriciye geri döndürmek ve uykuya dalmaktan ziyade sahada (sahiplikle) problemlerle savaşmaya / düzeltmeye çalışırlar!