क्या किसी संगठन में गैर-डेवलपर्स के साथ आंतरिक कोड साझा किया जाना चाहिए?

Question

जहां मैं काम करता हूं, हमारे पास बहुत सारे डेवलपर हैं और स्टाफ और ग्राहकों द्वारा उपयोग किए गए हमारे मालिकाना अनुप्रयोगों को चलाने वाले बहुत सारे कोड हैं।

हमारे पास बहुत सारे स्मार्ट सपोर्ट स्टाफ हैं जो अपने ग्राहकों को बेहतर समर्थन देने के लिए हमारे सिस्टम के आंतरिक कामकाज को समझना पसंद करते हैं, और शायद समय-समय पर एक पैच भी प्रस्तुत करते हैं।

क्या हमें अपने गैर-विकास कर्मचारियों को पढ़ने में सक्षम होने के लिए अपना कोड खोलना चाहिए? यह निर्णय लेते समय हमें किन कारकों को ध्यान में रखना चाहिए? मैं हर तरह से तर्कों और प्रतिवाद का एक समूह भर आया हूं और दूसरों के अनुभव के साथ-साथ अच्छी तरह से समझे गए जोखिमों के आधार पर निर्णय लेना चाहता हूं।

इस प्रकार कुछ तर्क:

• वीसीएस में पासवर्ड उजागर होते हैं (समाधान: पासवर्ड से छुटकारा पाएं - वे वहाँ नहीं होना चाहिए जिससे शुरू करें)
• कोड सफेद बॉक्स सुरक्षा हमलों के लिए खुला है (प्रतिवाद: यह केवल ईमानदार / आलसी हमलावरों को बाहर रखता है)
• सहायक कर्मचारी डेवलपर्स से पूछ सकते हैं कि "कैसे" चीजें काम करती हैं (काउंटर: मछली को एक आदमी सिखाना, आदि)

क्या कोई अपने संगठन के कर्मचारियों के लिए अपना कोड खोलता है? क्या इससे कोई समस्या हुई है?

Comments

आप इसे उनसे क्यों रखना चाहेंगे?

— मार्जन वेनमा

क्या आप कानून का हवाला दे सकते हैं?

— ब्लर एफएल

@ एस.लॉट: यह एक "कैपिटल एसेट" है और जैसा कि कंपनी के पास यह अधिकार है कि वह कर्मचारियों को नियंत्रित कर सकती है और वे इसे एक्सेस नहीं कर सकती हैं। आमतौर पर कंपनी उन कर्मचारियों की संख्या को सीमित करना चाहेगी, जिनकी पहुंच उन लोगों की संख्या को सीमित करने के लिए है, जो कंपनी से असहमत होने पर संपत्ति को दूर करने या संपत्ति का दुरुपयोग करने के लिए रिश्वत देने या मजबूर करने के लिए मजबूर हो सकते हैं। इसलिए ज्यादातर मामलों में आंतरिक रूप से इसका खुलासा नहीं करना चाहिए (हर किसी के लिए; इसे प्रबंधन को बताना होगा)।

— जनवरी Hudec

@ जानहुडेक: "प्रबंधन के लिए खुलासा किया जाना चाहिए"; "कंपनी को यह नियंत्रित करने का अधिकार है कि कौन से कर्मचारी इसे एक्सेस कर सकते हैं या नहीं।" उत्तम। यह निर्णय लेने के लिए डेवलपर्स के ऊपर नहीं है । इसलिए स्पष्टीकरण के लिए मेरा अनुरोध। यह सवाल कैसे उठ सकता है? डेवलपर्स यह निर्णय क्यों ले रहे हैं?

— लोट

@ एस.लॉट: मुझे यह सवाल स्पष्ट नहीं दिखता है कि यह डेवलपर्स हैं जो यह निर्णय ले रहे हैं। प्रबंधन के पास अंतिम शब्द है, लेकिन किसी को उनके लिए तर्क इकट्ठा करना होगा।

— Jan Hudec

Answer 1

मुझे नहीं लगता कि इसका कोई सामान्य उत्तर है। संगठन उनके आकार, भौगोलिक प्रसार, कंपनी की संस्कृति, कॉपीराइट नीतियों, सॉफ्टवेयर के प्रकार विकसित होने, इत्यादि में बेतहाशा भिन्न होते हैं।

उदा। कमोडिटी / इन्फ्रास्ट्रक्चर प्रकार के सॉफ्टवेयर विकसित करने वाली कंपनी के लिए, सोर्स कोड को खोलना आसान हो सकता है, यहां तक ​​कि इसे सोर्स करने के लिए भी, जैसा कि सिस्को ने कुछ साल पहले अपने प्रिंटर ड्राइवर सॉफ्टवेयर (IIRC) के साथ किया था।

कुछ दुर्लभ मालिकाना सॉफ्टवेयर विकसित करने वाली कंपनी के लिए, विशेष रूप से विशेष एल्गोरिदम या सामान सहित, जो उन्हें अपनी प्रतिस्पर्धा पर प्रतिस्पर्धात्मक लाभ देता है, मैं बहुत अच्छी तरह से समझ सकता हूं कि क्या वे अपने कोड को गुप्त रखने का प्रयास कर रहे हैं। उदाहरण के लिए, AFAIK Google बहुत ही सख्ती से उन लोगों की संख्या को सीमित करता है, जिन्हें उनके मूल खोज एल्गोरिदम के कार्यान्वयन की अनुमति दी गई है।

इसके अलावा एक बहुराष्ट्रीय संगठन आजकल कई देशों, समय क्षेत्रों और संस्कृतियों में फैला हुआ है, और सुरक्षा कारणों से, वे संभवत: अपने इंट्रानेट सेगमेंट करते हैं और विभिन्न खंडों / डोमेन के बीच यातायात को नियंत्रित करने के लिए फायरवॉल का उपयोग करते हैं। तो "पूरी कंपनी" के लिए एक SCM रेपो को प्रशंसनीय बनाने से वास्तव में sysadmins, और अतिरिक्त सुरक्षा जोखिम के लिए अतिरिक्त कार्य की आवश्यकता हो सकती है। हालांकि यह आम तौर पर सामान्य रूप से कोई लाभ नहीं लाता है, क्योंकि पूरी तरह से अलग सामान पर एक अलग महाद्वीप पर काम करने वाले नियोक्ता शायद यहां पर हमारी परियोजना के बारे में भी नहीं जानते हैं, सकारात्मक रूप से योगदान देने के लिए बहुत कम।

तो अगर यह आपके विभाग के भीतर समझ में आता है , और / या किसी तरह से परियोजना से जुड़े लोगों के लिए, क्यों नहीं। लेकिन सामान्य तौर पर, "खुलेपन" के लिए, मुझे यकीन नहीं है कि यह इसके लायक है।

एक अंतिम ध्यान दें: यहां तक ​​कि जब समर्थन वाले लोग स्मार्ट होते हैं और पैच योगदान करने के लिए उत्सुक होते हैं, तो मैं कहूंगा कि सिस्टम में एकीकृत होने से पहले उनके योगदान की हमेशा एक डेवलपर द्वारा समीक्षा की जानी चाहिए।

Answer 2

मेरे द्वारा काम किए गए अधिकांश संगठनों में, कोड रिपॉजिटरी सभी डेवलपर्स के लिए खुली थी।

कुछ में यह सॉफ्टवेयर के साथ-साथ संस्करण बनाने के लिए दस्तावेजों (जैसे चश्मा और आवश्यकताएं) को स्टोर करने के लिए भी उपयोग किया जाता था। उस स्थिति में अधिकांश अन्य कर्मचारियों की भी पहुँच थी। जहां रेपो केवल कोड के लिए उपयोग किया जाता था, गैर-देवों के पास आमतौर पर पहुंच नहीं थी - लेकिन मैंने कभी किसी की शिकायत नहीं सुनी, इसलिए यह शायद कोई बड़ी बात नहीं थी।

मैं यथासंभव खुलेपन की सिफारिश करूंगा - इसलिए यदि लोग पहुंच चाहते हैं, तो इसे तब तक दें जब तक कि कोई स्पष्ट समस्या न हो। लेकिन यह वास्तव में संगठन की संस्कृति का सवाल है ...

Answer 3

मैं इस पर एक सामान्य / व्यावहारिक दृष्टिकोण साझा करता हूं और कार्य / संगठन की प्रकृति पर भी निर्भर हो सकता है। लेकिन मेरा मानना ​​है कि कोड आधार सभी के लिए खुला होना चाहिए (संगठन के भीतर भी खुलापन और विश्वास दिखाएगा)।

मैं एक समान सेटअप में भी काम करता हूं जैसा आपने उल्लेख किया है कि हमारे पास एक सपोर्टर / हेल्पडेस्क टीम है जो ग्राहकों के अनुरोधों से संबंधित है। हालांकि सिस्टम के कुछ जटिल क्षेत्रों में उन्हें अतिरिक्त मदद की आवश्यकता होती है। मेरे मामले में कोड आधार सभी के लिए खुला है, हमें कोई समस्या नहीं हुई है।

• मुझे लगता है कि कोड आधार को खोलने से अन्य सहायता टीम के सदस्य जो उत्सुक हैं, वे भी कोड के आधार की जांच कर सकते हैं और उन व्यावसायिक नियमों / क्षेत्र से परिचित हो सकते हैं जिनकी उन्हें दिलचस्पी है या जवाब खोजने की आवश्यकता है (और संभवतः उनकी तकनीकी समझ और कुछ को देखने में सुधार करें) यदि समय अनुमति देता है तो नीरस दिनचर्या से अलग;)। यह तब भी उपयोगी साबित हो सकता है जब टीम के सदस्य ग्राहकों के मुद्दों और लॉग्स को प्राप्त करते हैं और कोड के संभावित क्षेत्रों पर बिंदु / सहायता करने में सक्षम होंगे जहां स्टैकट्रेस जैसे (स्पष्ट रूप से समस्या आदि पर निर्भर करेगा) को देखकर ऐसा होता है। यह डेवलपर के साथ समय भी बचाएगा लेकिन निश्चित रूप से समस्या के आधार पर।

साथ ही उस उत्पाद का प्रलेखन / विकी अप करने के लिए जिसमें सभी व्यावसायिक नियम / निर्णय शामिल हैं, इससे भी मदद मिलेगी। लेकिन निश्चित रूप से आपको यह सुनिश्चित करने की आवश्यकता है कि नई वृद्धि और / या बग फिक्स (जहां व्यवहार में परिवर्तन होता है) को राहत देने के लिए विकि को लगातार अपडेट किया जाता है। मेरे ईमानदार विचार

Answer 4

सामान्य तौर पर, संगठन के दृष्टिकोण से - लोग आते हैं और जाते हैं; परियोजना (या उत्पाद) को विकसित करने के लिए जारी रखने की जरूरत है। इसलिए, ज्यादातर संगठन में, कोड बनाए रखने के लिए आमतौर पर सभी रिपॉजिटरी के लिए एक ओपन है।

आमतौर पर अनधिकृत अनधिकृत पहुंच को रोकने के लिए (कोड चोरी आदि को रोकने के लिए) एक्सेस अधिकार आदि हैं, लेकिन अधिकांश उच्च अप वास्तव में इस पर वर्जित नहीं हैं। किसी संगठन के भीतर, लोगों को (पर्याप्त) विश्वास करना चाहिए कि आप कोड के साथ उन पर भरोसा कर सकते हैं। कर्मचारियों (या सहकर्मी) से कोड छिपाना एक महान प्रेरक कारक है।

हमारे संगठन में, यहां तक ​​कि जब लोग वास्तव में कोड में योगदान नहीं करते हैं - तो उनके पास कोड तक सीधी पहुंच होती है जो मदद करता है क्योंकि वे डेवलपर को वापस डंप करने की चीजों के बजाय क्षेत्र में (स्वामित्व के साथ) समस्याओं को लड़ने / ठीक करने का प्रयास करते हैं और सो जाते हैं!

Comments

"ज्यादातर संगठन में, कोड बनाए रखने के लिए आमतौर पर सभी रिपॉजिटरी के लिए एक ओपन है।" - मुझे इसमें संदेह है। क्या आप इस दावे को वापस करने के लिए कोई डेटा उद्धृत कर सकते हैं? इसके अलावा, प्रोजेक्ट फू का रेपो मुझे डिमोनेटाइज़ करने के लिए कैसे सक्षम नहीं हो पा रहा है?

— पेतेर टॉरक

@ PéterTörök - मुझे संदेह है कि दीपन का मतलब क्या है कि ज्यादातर संगठनों के पास उसका अनुभव है, कोड सभी के लिए खुला है। संगठन के विभिन्न आकारों में 20 वर्षों में अपने स्वयं के अनुभव के साथ यह संक्षिप्त होगा। रक्षा उद्योग में काम करते हुए भी आश्चर्यजनक रूप से बहुत कम कोड थे जो केवल सुरक्षित नेटवर्क पर थे।

— मार्क बूथ

@ मर्क, इस मायने में मैं सहमत हूं। अब तक के मेरे अधिकांश कार्यस्थलों में, मैंने एससीएम रेपो के लिए एक एक्सेस पॉलिसी तैयार करने में बहुत प्रयास नहीं किए हैं, इसलिए अक्सर वे किसी भी व्यक्ति के लिए सुलभ होते हैं जो आने वाले समय के लिए होता है। लेकिन यह उपेक्षा का परिणाम है, किसी के सचेत निर्णय का नहीं।

— पेटर टॉर्क