जोड़ी प्रोग्रामिंग और आईएसओ 27001

Question

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

अब तक यह हमारे लिए ठीक काम किया है, लेकिन मेरी कंपनी वर्तमान में आईएसओ 27001 ऑडिट से गुजर रही है और इसे ऑडिटर ने जोखिम के रूप में हरी झंडी दिखाई। मेरे पास कई संभावित समाधान हैं जैसे कि हर जोड़ी संयोजन के लिए एक युग्मन खाता बनाना, लेकिन मैं वास्तव में जानना चाहूंगा कि क्या किसी और ने इस समस्या का सामना किया है और उन्होंने इसे कैसे हल किया है?

ऑडिटर्स द्वारा क्या समाधान स्वीकार्य था?

Comments

मुझे लगता है कि ज्यादातर लोग जो जोड़ी प्रोग्रामिंग प्रथाओं को नियुक्त करते हैं, उन्हें लगता है कि आईएसओ जो करता है वह सभी तारीख प्रारूप और चरित्र एन्कोडिंग है।

— लार्स विकलंड

आपको जोड़ीदार खाते की आवश्यकता क्यों है? क्या यह उन व्यक्तिगत खातों को रखने के लिए काम नहीं करेगा जिन्हें आप किसी भी मशीन पर लॉग इन कर सकते हैं?

— गैरेट हॉल

आप अलग-अलग खातों का उपयोग नहीं कर सकते क्योंकि क्या होगा यदि कोई व्यक्ति जल्दी काम करता है / शौचालय में जाता है आदि और मशीन अन्य उपयोगकर्ता के रूप में लॉग इन है?

— जॉन सोबल

क्या आप उस खाते पर प्रगति के साथ काम जारी रखना चाहते हैं? अन्यथा आप अपने स्वयं के उपयोगकर्ता के रूप में कंप्यूटर पर एक और सत्र खोलने में सक्षम होना चाहिए।

— सिनजो

@JohnSibly, तब ड्राइवर लॉग ऑफ करता है, और सहकर्मी को लॉग ऑन करने देता है। यदि वे वॉशरूम जाते हैं, तो मशीन को लॉक करें यदि आपको अपने साथियों पर भरोसा नहीं है। हालांकि, कोई भी भरोसा एक बड़ा मुद्दा नहीं है जिसे सुधारना चाहिए।

— कैफीक झूले

Answer 1

मुझे लगता है कि ऑडिटर पसंद करेंगे कि डेवलपर्स खुद में लॉग इन करें और न कि कुछ "जोड़ी" के रूप में, जिसमें एक साझा पासवर्ड हो। जोखिम स्पष्ट होना चाहिए - एक डेवलपर "PairA" के रूप में कुछ दुर्भावनापूर्ण कोड जोड़ता है और टिप्पणी में किसी और व्यक्ति के शुरुआती अक्षर डालता है (या इसे टिप्पणी नहीं करता है)। आप दुर्भावनापूर्ण डेवलपर को वापस कैसे ट्रेस करेंगे?

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

Comments

+1, यह मेरी कंपनी में किया जाता है। हमारे पास सहकर्मी कोड समीक्षा या जोड़ी प्रोग्रामिंग का विकल्प है। जोड़ी प्रोग्रामिंग का मामला सहकर्मी की समीक्षा का एक विशेष मामला है, जहां सहकर्मी लगातार समीक्षा कर रहा है जबकि कोड लिखा गया था।

— डैनियल प्राइडेन

@ डैनियल अपना अनुभव साझा करने के लिए धन्यवाद। जब हमने पहली बार जोड़ी बनानी शुरू की, तो यह ड्राइवर था जो लॉगिन करेगा। हालाँकि, हमारे युग्मन सत्र अब अधिक अच्छे हैं और अक्सर एक जोड़ी पूरी तरह से काम पूरा होने से पहले ही स्वैप हो जाएगी। यद्यपि यह आदर्श नहीं है, लेकिन कभी-कभी हमारे स्वैप को ऑर्केस्ट्रेट करना आवश्यक होता है क्योंकि उत्पादन कोड पर सभी को जोड़ी की आवश्यकता होती है। इसका मतलब है कि मूल 'ड्राइवर' को दूर चलना होगा और इस तरह लॉग आउट करना होगा। हम उनके बिना जाँच किए गए कोड को प्राप्त कर सकते हैं, लेकिन जोड़ी के विघटन, जो संभावित रूप से ऐप को डिबग करने के बीच में हैं, को बहुत हल्के में नहीं लिया जाता है।

— मार्टिन ह्यूजेस

Answer 2

मैं उन खातों को रखूंगा जैसे वे हैं, आमतौर पर केवल एक व्यक्ति चला रहा है, और यहां तक ​​कि अगर दूसरा व्यक्ति मशीन का उपयोग करता है (अनौपचारिक रूप से) तो लॉग इन किए गए व्यक्ति को अभी भी पता होना चाहिए कि उनकी मशीन पर क्या हो रहा है।

चेकइन को अभी भी टिप्पणियों की आवश्यकता होगी, यह दिखाने के लिए कि जोड़ी कौन थी।

Comments

क्या आपका मतलब है कि जोड़ीदार खाते ("जैसे हैं वैसे खाते रखें"), या व्यक्तिगत खातों का उपयोग करें ("जिस व्यक्ति ने लॉग इन किया है")?

— कालेब

@ कालेब, व्यक्ति के रूप में व्यक्ति जो लॉग-इन कर रहा है ड्राइविंग

— CaffGeek

Answer 3

अलग-अलग खाते बनाने के बजाय, ताकि कार्य संभवतः अनुपस्थित उपयोगकर्ता के लिए बंद न हो, अपने संस्करण नियंत्रण प्रणाली का उपयोग करें। जब एक जोड़ी काम करना शुरू करती है, तो एक कार्य शाखा बनाएं। जब भी परीक्षण पास हो तब कार्य शाखा को कोड दें। जब कार्य पूरा हो जाता है, तो वापस विलय करें और कार्य शाखा को बंद करें।

Answer 4

अब तक यह हमारे लिए ठीक काम किया है, लेकिन मेरी कंपनी वर्तमान में आईएसओ 27001 ऑडिट से गुजर रही है

आईएसओ 27001 या नहीं, आपकी वर्तमान प्रणाली केवल इसलिए काम करती है क्योंकि आप एक छोटी कंपनी हैं जहां संचार और आपसी विश्वास का एक उच्च स्तर है। इस तरह की बात बहुत अच्छी नहीं है, इसलिए आपको भविष्य में किसी भी समय अन्य विकल्पों पर विचार करना होगा।

हर संभावित जोड़े के लिए एक अलग खाता बनाना और भी कम व्यावहारिक लगता है: आपको 10 डेवलपर्स के समूह के लिए 90 खातों की आवश्यकता होगी, और उन 10 डेवलपर्स में से प्रत्येक को 9 अलग-अलग लॉगिन / पासवर्ड संयोजन जानने होंगे।

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

Answer 5

पीट की खातिर, जोड़ी के ड्राइविंग सदस्य को पुश / कमिट के लिए क्रेडिट / जिम्मेदारी ले। अगली बार अन्य सदस्य ड्राइव करेंगे। "ड्राइवर" कुछ भी नहीं करेगा वह सह-पायलट के साथ सहमत नहीं है।

प्रोग्रामिंग एक सहयोगात्मक प्रयास है। कोई प्रोग्रामिंग विलेख 100% व्यक्तिगत नहीं है। यह बताने के लिए तेज नहीं होना चाहिए कि टॉम और हैरी द्वारा एक पुश / कमिट किया गया था और न केवल टॉम द्वारा किया गया था। जोड़ी प्रोग्रामिंग के लाभ उस बारीकियों को देखने लायक हैं।

लेखा परीक्षक सही है, "पूल" खातों से बचा जाना चाहिए।