ควรแบ่งปันรหัสภายในกับผู้ที่ไม่ใช่นักพัฒนาในองค์กรหรือไม่

ที่ที่ฉันทำงานอยู่เรามีนักพัฒนาจำนวนมากและมีรหัสมากมายที่น่ากลัวที่ใช้แอปพลิเคชันที่เป็นกรรมสิทธิ์ของเราที่ใช้โดยพนักงานและลูกค้า

นอกจากนี้เรายังมีเจ้าหน้าที่สนับสนุนที่ชาญฉลาดจำนวนมากที่ต้องการทำความเข้าใจการทำงานภายในของระบบของเราเพื่อสนับสนุนลูกค้าของเราได้ดียิ่งขึ้นและอาจส่งแพทช์เป็นครั้งคราว

เราควรเปิดรหัสของเราเพื่อให้พนักงานที่ไม่ใช่นักพัฒนาของเราอ่านได้หรือไม่? เราควรคำนึงถึงปัจจัยใดบ้างเมื่อทำการตัดสินใจครั้งนี้ ฉันเจอข้อโต้แย้งและข้อโต้แย้งหลายทางและต้องการตัดสินใจโดยอาศัยประสบการณ์ของผู้อื่นรวมถึงความเสี่ยงที่เข้าใจกันดี

บางคนโต้แย้ง:

• รหัสผ่านใน VCS นั้นถูกเปิดเผย (วิธีแก้ปัญหา: กำจัดรหัสผ่าน - พวกเขาไม่ควรเริ่มด้วย)
• รหัสนี้เปิดให้มีการโจมตีเพื่อความปลอดภัยในกล่องขาว (โต้เถียง: สิ่งนี้จะป้องกันผู้โจมตีที่ซื่อสัตย์ / ขี้เกียจเท่านั้น)
• เจ้าหน้าที่ให้ความช่วยเหลือสามารถถามนักพัฒนาว่า "ทำงานอย่างไร" สิ่งต่าง ๆ (เคาน์เตอร์: สอนคนตกปลา ฯลฯ )

ไม่มีใครเปิดรหัสของพวกเขาให้กับพนักงานในองค์กร มันทำให้เกิดปัญหาใด ๆ ?

ฉันไม่คิดว่าจะมีคำตอบทั่วไปเกี่ยวกับเรื่องนี้ องค์กรแตกต่างกันอย่างมากในขนาดแพร่กระจายทางภูมิศาสตร์วัฒนธรรมของ บริษัท นโยบายลิขสิทธิ์ชนิดของซอฟต์แวร์ที่ได้รับการพัฒนา ฯลฯ ฯลฯ

เช่นสำหรับ บริษัท ที่กำลังพัฒนาซอฟต์แวร์ประเภทสินค้าโภคภัณฑ์ / โครงสร้างพื้นฐานอาจเป็นเรื่องง่ายที่จะเปิดซอร์สโค้ดแม้ว่าจะเป็นซอฟต์แวร์โอเพ่นซอร์สก็ตามเนื่องจาก Cisco ทำมาหลายปีแล้วกับซอฟต์แวร์ไดรเวอร์เครื่องพิมพ์ (IIRC)

สำหรับ บริษัท ที่พัฒนาซอฟท์แวร์กรรมสิทธิ์ที่หายากซึ่งอาจรวมถึงอัลกอริทึมพิเศษหรือสิ่งที่ให้ความได้เปรียบในการแข่งขันกับการแข่งขันของพวกเขาฉันสามารถเข้าใจได้เป็นอย่างดี เช่น AFAIK Google จำกัด จำนวนผู้ที่ได้รับอนุญาตให้เข้าถึงการใช้อัลกอริทึมการค้นหาหลักอย่างเคร่งครัด

ปัจจุบันมีองค์กรข้ามชาติกระจายอยู่ในหลายประเทศเขตเวลาและวัฒนธรรมและด้วยเหตุผลด้านความปลอดภัยพวกเขาอาจแบ่งส่วนอินทราเน็ตและใช้ไฟร์วอลล์เพื่อควบคุมการรับส่งข้อมูลระหว่างส่วน / โดเมนที่ต่างกัน ดังนั้นการสร้าง repo SCM ให้กับ "ทั้ง บริษัท " ในความเป็นจริงอาจต้องการงานพิเศษมากมายสำหรับ sysadmins และความเสี่ยงด้านความปลอดภัยเพิ่มเติม แม้ว่าปกติแล้วมันจะไม่ก่อให้เกิดประโยชน์ใด ๆ โดยทั่วไปเนื่องจากนายจ้างที่ทำงานในทวีปที่แตกต่างกันในสิ่งที่แตกต่างกันโดยสิ้นเชิงอาจจะไม่รู้ด้วยซ้ำเกี่ยวกับโครงการของเราที่นี่

ดังนั้นหากเหมาะสมในแผนกของคุณและ / หรือสำหรับคนที่เกี่ยวข้องกับโครงการในบางกรณีทำไมไม่ แต่โดยทั่วไปเพียงเพื่อประโยชน์ของ "การเปิดกว้าง" ฉันไม่แน่ใจว่ามันคุ้มค่า

หมายเหตุสุดท้ายประการหนึ่ง: แม้ว่าผู้ให้การสนับสนุนจะฉลาดและกระตือรือร้นที่จะมีส่วนร่วมกับแพตช์ฉันจะบอกว่านักพัฒนาควรได้รับการตรวจสอบจากนักพัฒนาก่อนที่จะรวมเข้ากับระบบ

ในองค์กรส่วนใหญ่ที่ฉันทำงานอยู่พื้นที่เก็บข้อมูลรหัสเปิดให้นักพัฒนาทั้งหมด

ในบางครั้งมันถูกใช้เพื่อจัดเก็บเอกสาร (เช่นข้อกำหนดและข้อกำหนด) เพื่อจัดทำเอกสารควบคู่ไปกับซอฟต์แวร์ ในกรณีนี้พนักงานคนอื่น ๆ ส่วนใหญ่ก็สามารถเข้าถึงได้เช่นกัน ที่ repo ใช้สำหรับรหัสเท่านั้นผู้ที่ไม่ใช่ devs มักไม่สามารถเข้าถึงได้ - แต่ฉันไม่เคยได้ยินใครบ่นเลยดังนั้นมันอาจจะไม่ใช่เรื่องใหญ่เลย

ฉันจะแนะนำการเปิดกว้างให้มากที่สุดเท่าที่จะทำได้ดังนั้นหากผู้คนต้องการการเข้าถึงให้พวกเขาเว้นแต่พวกเขาจะมีปัญหาชัดเจน แต่นั่นเป็นคำถามเกี่ยวกับวัฒนธรรมขององค์กร ...

ฉันแบ่งปันมุมมองทั่วไป / ในทางปฏิบัติเกี่ยวกับเรื่องนี้และอาจขึ้นอยู่กับลักษณะของงาน / องค์กรด้วย แต่ฉันเชื่อว่ารหัสฐานควรเปิดให้ทุกคน (จะแสดง openess และไว้วางใจภายในองค์กรด้วย)

ฉันยังทำงานในการตั้งค่าที่คล้ายกันตามที่คุณกล่าวถึงเมื่อเรามีทีมงานสนับสนุน / ฝ่ายช่วยเหลือซึ่งจัดการกับคำขอของลูกค้า อย่างไรก็ตามบางพื้นที่ที่ซับซ้อนของระบบพวกเขาต้องการความช่วยเหลือเพิ่มเติม ในกรณีของฉันฐานรหัสเปิดให้ทุกสิ่งที่เราไม่พบปัญหา

• ฉันคิดว่าการเปิดใช้รหัสฐานสมาชิกในทีมสนับสนุนคนอื่นที่กระตือรือร้นสามารถเช็คเอาต์รหัสฐานและทำความคุ้นเคยกับกฎเกณฑ์ทางธุรกิจ / พื้นที่ที่พวกเขาสนใจหรือต้องการหาคำตอบ (และอาจปรับปรุงความเข้าใจด้านเทคนิคและมองสิ่งต่างๆ แตกต่างจากการจำเจซ้ำซากหากเวลาอนุญาต;)) สิ่งนี้อาจพิสูจน์ได้ว่ามีประโยชน์เมื่อสมาชิกในทีมสนับสนุนรับปัญหาและบันทึกของลูกค้าและจะสามารถชี้ / ช่วยเหลือในส่วนที่เป็นไปได้ของรหัสที่เกิดขึ้นโดยการดูที่สแต็คแท็กเช่น (แน่นอนจะขึ้นอยู่กับปัญหา ฯลฯ ) สิ่งนี้จะประหยัดเวลากับนักพัฒนา แต่ขึ้นอยู่กับปัญหาของหลักสูตร

นอกจากนี้ยังมีเอกสาร / วิกิที่ทันสมัยของผลิตภัณฑ์ซึ่งมีกฎ / การตัดสินใจทางธุรกิจทั้งหมดจะช่วยได้เช่นกัน แต่แน่นอนคุณต้องแน่ใจว่า wiki นั้นได้รับการปรับปรุงอยู่ตลอดเวลาเพื่อปรับปรุงและ / หรือแก้ไขข้อผิดพลาดใหม่ (ซึ่งการเปลี่ยนแปลงพฤติกรรม) ความคิดที่ซื่อสัตย์ของฉัน

โดยทั่วไปจากมุมมองขององค์กร - คนมาและไป โครงการ (หรือผลิตภัณฑ์) จำเป็นต้องพัฒนาต่อไป ดังนั้นในองค์กรส่วนใหญ่มักจะมี Open to repositories ทั้งหมดสำหรับการบำรุงรักษาโค้ด

โดยปกติจะมีสิทธิ์การเข้าถึงอื่น ๆ เพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต (เพื่อป้องกันการโจรกรรมรหัส ฯลฯ ) แต่ยูพีเอสที่สูงกว่าส่วนใหญ่จะไม่ถูกกันออกไป ภายในองค์กรหนึ่งต้องเชื่อถือคน (พอ) ที่คุณสามารถไว้วางใจพวกเขาด้วยรหัส การซ่อนรหัสจากพนักงาน (หรือเพื่อนร่วมงาน) เป็นปัจจัยกระตุ้นที่ยอดเยี่ยม

ในองค์กรของเราแม้ว่าผู้คนไม่ได้มีส่วนร่วมกับรหัสจริง ๆ พวกเขามีการเข้าถึงรหัสโดยตรงที่ช่วยเพราะพวกเขาพยายามต่อสู้ / แก้ไขปัญหาที่สนาม (ด้วยความเป็นเจ้าของ) แทนที่จะทิ้งสิ่งต่าง ๆ กลับไปยังนักพัฒนาและเข้าสู่โหมดสลีป!