डेवलपर्स अपने स्वयं के कार्यस्थानों पर कैसे काम करते हैं, इसके लिए मानक


18

हम सिर्फ उन स्थितियों में से एक हैं, जो कभी-कभार तब सामने आती हैं जब कोई डेवलपर कुछ दिनों के मिड-प्रोजेक्ट के लिए बीमार हो जाता है।

इस बारे में कुछ सवाल थे कि क्या वह अपने कोड का नवीनतम संस्करण ले सकता है या क्या उसकी स्थानीय मशीन पर हाल ही में कुछ और है जिसे हमें देखना चाहिए, और हमारे पास एक ग्राहक के लिए डिलीवरी लंबित है, इसलिए हम इंतजार नहीं कर सकते उसे वापस करने के लिए।

अन्य डेवलपर्स में से एक ने कार्यक्षेत्रों की गड़बड़ी को देखने और देखने के लिए उस पर लॉग ऑन किया, कई एक ही परियोजनाओं के प्रतीत होते हैं, टाइमस्टैम्प के साथ जिसने यह स्पष्ट नहीं किया कि कौन सा "चालू" था (वह परियोजना के संस्करणों पर कुछ बिट्स की तुलना में प्रोटोटाइप कर रहा था) उसकी "कोर" एक)।

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

मैं चेक-इन कोड के लिए मानकों या सामान्य विकास मानकों के बारे में बात नहीं कर रहा हूँ, मैं बात कर रहा हूँ कि कैसे एक डेवलपर स्थानीय रूप से काम करता है, एक डोमेन जिसे आमतौर पर माना जाता है (मेरे अनुभव में) लगभग पूरी तरह से डेवलपर्स के नियंत्रण में है।

तो आप इस तरह की स्थितियों को कैसे संभालते हैं? क्या उन चीजों में से एक है जो बस होती है और आपको उन चीजों से निपटना पड़ता है, जो डेवलपर्स के लिए आप भुगतान करते हैं, जिस तरह से उन्हें सूट करने की अनुमति है?

या क्या आप डेवलपर्स से इस क्षेत्र में मानकों का पालन करने के लिए कहते हैं - विशिष्ट निर्देशिकाओं का उपयोग, मानकों का नामकरण, विकी पर नोट्स या जो भी हो? और यदि ऐसा है तो आपके मानक क्या हैं, वे कितने सख्त हैं, आप उन्हें और इतने पर पुलिस कैसे बनाते हैं?

या कोई और उपाय है जो मुझे याद आ रहा है?

[तर्क के लिए मान लें कि डेवलपर से बात करने के लिए संपर्क नहीं किया जा सकता है कि वह यहां क्या कर रहा था - भले ही वह यह जान और वर्णन कर सके कि कौन सा कार्यक्षेत्र है जो स्मृति से सरल और निर्दोष नहीं है और कभी-कभी लोग वास्तव में ऐसा नहीं कर सकते हैं 'संपर्क नहीं किया जाना चाहिए और मुझे ऐसा समाधान चाहिए जो सभी घटनाओं को कवर करे।]

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


8
-1 एक प्रोग्रामर के कमांड सेंटर पर गेस्टापो जाने के लिए।
systemovich

17
रुको, दूसरे डेवलपर को पहले डेवलपर का पासवर्ड कैसे पता चला?
TheLQ

12
एक उत्कृष्ट प्रश्न के लिए +1। डेवलपर के लिए निगम के लिए काम कर रहे हैं और इसलिए अपने स्थानीय मशीनों के लिए उपयोग के अधिकारों को त्यागने के बाद से "जाप गैपापो" मेरी राय में एक कॉर्पोरेट वातावरण में प्रासंगिक नहीं है। आप गोपनीयता चाहते हैं, अपने स्वयं के हार्डवेयर का उपयोग करें।
गैरी रोवे

4
यदि डेवलपर से पासवर्ड के लिए संपर्क किया जा सकता है, तो आपने उससे सिर्फ यह क्यों नहीं पूछा कि वर्तमान संस्करण कौन सा है?
बेन एल

2
@ गैरी: क्या? नहीं, यह पूरी तरह से (और बहुत खतरनाक) बकवास है। यह कंपनी के लिए काम करने से लेकर गोपनीयता के लिए व्यक्तिगत अधिकारों को छोड़ने के लिए एक लओंग शॉट (दोनों तार्किक और कानूनी रूप से) है। मैं जॉन की कार्रवाई "गेस्टापो जा रहा" (यहां तक कि इससे पहले कि वह समझाया इसे और अधिक), लेकिन कंपनियों के फोन नहीं होता है गेस्टापो कभी कभी जाने के लिए और यह कुछ ऐसा है की जरूरत को रोका और सभी स्तरों पर लड़ा जा रहा है। मैं केवल जर्मनी के लिए बोल सकता हूं लेकिन यहां आपके पास कंपनी के स्वामित्व वाले हार्डवेयर पर काम करने के दौरान भी कुछ गोपनीयता अधिकार हैं।
कोनराड रुडोल्फ

जवाबों:


64

" अगर यह स्रोत नियंत्रण में नहीं है, तो यह मौजूद नहीं है। "

यह हमारे पेशे की कुछ चीजों में से एक है, जिसके बारे में मैं सीमावर्ती हूं। निम्नलिखित कारणों के लिए:

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

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

साथ ही, छुट्टी पर जाने से पहले सब कुछ जांचना अनिवार्य था ।

TL; DR संस्करण : लोगों के वर्कस्टेशन के माध्यम से राइफलिंग खराब रूप है। लोगों की वर्कस्टेशन के माध्यम से जाना आसान बनाने की संस्कृति को बढ़ावा देने की कोशिश करने के बजाय हम क्या चाहते हैं, समझदार स्रोत नियंत्रण उपयोग और नियमित जाँच की संस्कृति को बढ़ावा देना बेहतर अभ्यास है। संभवतः हाइपर-रेगुलर चेकइन और प्रोजेक्ट्स के महत्वपूर्ण चरणों में ठीक-ठाक काम करते हैं।


10
+1: किसी का बीमार होना, उनके कार्य केंद्र पर गड़बड़ करना शायद मूल्य से अधिक लागत होने वाला है। एक व्यक्ति पहले ही जा चुका है। अब एक और समय बर्बाद कर रहा है यह पता लगाने की कोशिश कर रहा है कि क्या चल रहा है। बिना किसी मूल्य के विशाल प्रबंधन दुःस्वप्न। जब तक यह स्रोत नियंत्रण में है, तब तक यह कभी अस्तित्व में नहीं था।
एस.लॉट

1
अगर वह दिन के लिए बंद है? सप्ताह के बाकी समय के लिए हाँ? शायद, एक महीने के लिए? सवाल ही नहीं। यह उन गंदे "शेड्स ऑफ़ ग्रे" समस्याओं में से एक है ... हम वापस आ गए हैं, फिर से, जल्दी करने के लिए, अक्सर कमिट करने के लिए - इसलिए पैटर्न जरूरी नहीं कि वर्कस्टेशन हों लेकिन संस्करण नियंत्रण का उपयोग करें, लेकिन स्पष्ट रूप से इसका कुछ सोचने लायक।
मर्फ़

जब आप रिलीज़ कहते हैं, तो क्या आप बिल्ड या उपयोगकर्ताओं को रिलीज़ करने के लिए रिलीज़ करते हैं?
जेएफओ

2
@ मर्फ़: यदि बदलाव हर X दिनों में कहीं न कहीं किए जाते हैं, तो गलत तरीके से किए जा सकने वाले काम की अधिकतम राशि X दिनों के लायक होती है, और यह सच है कि डेवलपर कितनी भी देर तक बाहर रहा हो। उचित बात यह है कि नीतियों को बार-बार जांचने के लिए पर्याप्त है ताकि खोए हुए काम की मात्रा स्वीकार्य सीमा के भीतर हो।
डेविड थॉर्नले

1
@ मेरी टिप्पणी @ S.Lott की प्रतिक्रिया थी - "खो" के बारे में तर्क के संदर्भ में। अच्छी तरह की। मैं बदलावों के एक पूरे सेट के अर्थ में परमाणु बनना चाहता हूं (मुझे समझ में आने लगा है कि रिबेस इतना आकर्षक क्यों है) - तो मैं समस्याग्रस्त (सामान्य उदाहरण में और अनुपस्थिति में "बचाने के लिए प्रतिबद्ध" देखता हूं एक रिबेस के बराबर)। और किसी भी स्थिति में दैनिक स्वचालित कार्य केंद्र बैकअप होना चाहिए जो संस्करण नियंत्रण से काफी अलग है।
मर्फ़

22

आपके डेवलपर्स अपने कार्यस्थानों को कैसे व्यवस्थित करते हैं, इसके लिए एक मानक लागू करने के बजाय , एक मानक लागू करें जहां प्रत्येक दिन के अंत में सभी काम की जांच की जाती है । यदि अभी भी अपूर्ण है तो चेक-इन शाखाओं के लिए हो सकता है।

इस तरह से किसी को भी किसी अन्य डेवलपर के कार्य केंद्र तक पहुंचने की आवश्यकता नहीं होनी चाहिए।

मुझे लगता है कि यह नीति कुछ विपक्षों के साथ मिल जाएगी, लेकिन अगर आप कार्य केंद्र के संगठन के बारे में नियम लागू करते हैं तो मैं इसकी अपेक्षा के मुकाबले कुछ भी नहीं करूंगा।


1
आप कितनी बार शाखा का विलय करेंगे? हर बार जब आपको लगा कि यह स्थिर है?
जॉन हॉपकिंस

2
@Jon हॉपकिंस: "Relableable" "Stable" की तुलना में प्रबंधित करना आसान है। भरोसेमंद में स्थिर के साथ-साथ उत्पाद स्वामी भी इसके लिए तैयार है। और आप बहुत से ब्रांच-टू-रिलीज़ प्रोसेसिंग करेंगे। शाखा-से-स्थिर में व्यक्तिपरकता और "मेरे लिए काम किया" चर्चा के लिए बहुत अधिक संभावनाएं हैं।
एस.लॉट

2
-1 मैं योग्यता की एक बड़ी राशि के बिना इससे असहमत हूं, चेकिन एक तार्किक बिंदु पर होना चाहिए - और दिन के अंत में मनमाने ढंग से नहीं। (हाँ, हमें लक्ष्य नहीं छोड़ना चाहिए कि हमें एक समझदार ब्रेकपाइंट मिल गया है लेकिन जीवन हमेशा सहयोग नहीं करता है।) बैकअप अलग होना चाहिए। और हम सभी को अपने बक्सों तक पहुंच के बारे में थोड़ा कीमती होने की जरूरत है ( परिवर्तन नहीं , पहुंच के लिए)
मर्फ़

1
-1 क्योंकि यह परिदृश्यों को संबोधित नहीं करता है, जैसे "मैं वास्तव में बीमार महसूस करता हूं, मैं अभी घर जा रहा हूं। हम्म, बेहतर है कि तैयारी के 30 मिनट में कुछ और करें ताकि जब मैं प्रतिबद्ध हो तो मैं निर्माण को न तोड़ूं।"
गैरी रोवे

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

6

मैं आपको सच बताऊंगा कि मैं इस विचार के बारे में असहज महसूस करता हूं कि कोई व्यक्ति मेरी मशीन पर लॉग इन करने और अपने सामान के माध्यम से ब्राउज़ करने जा रहा है। दी, यह कंपनी के उपकरण और संपत्ति है, लेकिन यह बस एक बुरी बात है।

पिछली बार जब मैंने एक सप्ताह के अंत में लोगों को डेटाबेस और स्रोत नियंत्रण के साथ सर्वर को फिर से कॉन्फ़िगर किया और किसी कारण से अपनी मशीन पर लॉग इन करना और नई सेटिंग के लिए सिस्टम को फिर से कॉन्फ़िगर करना आवश्यक महसूस किया।

बहुत बुरा उन्हें पता नहीं था कि वे क्या कर रहे थे और उन्होंने पिछले दो महीनों से जिस प्रोटोटाइप पर काम कर रहे थे, उसे मिटा दिया।

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

लेकिन लोगों के कामकाज के साथ खिलवाड़ न करें।

पुनश्च हम एक निर्देशिका संरचना के लिए एक सम्मेलन है, लेकिन यह मुख्य अस्तित्व का कारण इतिहास / विन्यास का एक मिश्रण है - इसे कहीं और डाल दें और यह अनिवार्य हो जाएगा।


3
@ मर्फ़: अपने सिस्टम से कुछ पाने के लिए तत्काल ज़रूरत के साथ "बीमार जाना" एक बहुत ही दुर्लभ स्थिति है। किसी भी मानकीकरण प्रयासों के लायक नहीं हो सकता है।

1
मैं समझ सकता हूं कि किसी को आपके मेल को क्यों पढ़ना चाहिए और आपको अपनी मशीन पर कुछ भी नहीं बदलना चाहिए लेकिन अगर यह कोड निर्देशिकाओं को पढ़ने (केवल पढ़ने) के लिए मानक था तो कैसे होगा? जो मुझे आपकी आपत्तियों के रूप में दिखाई देता है, उसका अधिकांश हिस्सा आपको मिल जाएगा, लेकिन फिर भी लोगों को किसी आपात स्थिति में आपके काम पर जाने की संभावना है।
जॉन हॉपकिंस

3
उस प्रोटोटाइप पर कोई बैकअप नहीं?
जेएफओ

2
@ डायवर्टर कला, आपने संस्करण प्रणाली की एक शाखा में काम क्यों नहीं किया?

1
@DeveoperArt, क्या मतलब है "आप उस विकल्प का उपयोग नहीं कर रहे हैं"? आपका मतलब है कि आपके लिए सिर्फ अपने दम पर एक शाखा बनाने का कोई तरीका नहीं था? क्या उन्होंने किसी तरह ब्रांचिंग को निष्क्रिय कर दिया था? मैंने उस संभावना के बारे में कभी नहीं सुना है। फिर भी, आप किसी अन्य को शामिल किए बिना अपने स्वयं के स्थानीय मशीन (शायद ड्रॉपबॉक्स या एक नेटवर्क ड्राइव के लिए समर्थित) पर अपने स्वयं के "गिट" (या यहां तक ​​कि "svn") भंडार भी बना सकते थे। मैं सिर्फ 2 महीने (या यहां तक ​​कि 2 घंटे , वास्तव में) पर काम करने के लिए व्यक्तिगत रूप से संबंधित नहीं हो सकता हूं चाहे "महत्वपूर्ण" या नहीं, और इसकी केवल 1 प्रति हो।
जोएलफैन

6

कुछ महीने पहले मैं एक बड़ी परियोजना पर काम कर रहा था और अचानक काम छोड़ना पड़ा क्योंकि मुझे पता चला कि मुझे अस्पताल में भर्ती कराया जा रहा है। मेरे पास परियोजना के लिए अपने नवीनतम कोड में जांच करने का समय नहीं था।

सौभाग्य से, यह /var/www/ourdomain.comउत्पादन को नियंत्रित करने के लिए कोड को स्टोर करने के लिए यहां (हालांकि "आवश्यक" नहीं) सम्मेलन है । इस तरह के एक तार्किक, और सम्मेलन का पालन करना आसान होने के साथ, एक सहकर्मी के लिए मेरी मशीन में प्रवेश करना और मेरे नवीनतम परिवर्तनों को पुनः प्राप्त करना आसान था।

मुझे लगता है कि कुछ सम्मेलन अच्छे हैं। हालाँकि मैं बॉबी के कहने पर सहमत हूँ

"अगर यह स्रोत नियंत्रण में नहीं है, तो यह मौजूद नहीं है।"

इसके अलावा, किसी भी प्रोग्रामर कार्यक्षेत्र के लिए एक उपयोगी अतिरिक्त एक फ्रंट-बे हॉट-स्वैप एसएटीए ड्राइव हो सकता है, जिस पर सभी स्रोत और विकास परियोजनाओं को संग्रहीत किया जा सकता है। इस तरह, यदि ऐसी समस्या उत्पन्न होती है, तो एक कर्मचारी डेवलपर्स के लिए लॉगिन करने की आवश्यकता के बिना आसानी से परियोजना में नए स्रोत परिवर्तन प्राप्त कर सकता है।


"... यह मौजूद नहीं है"। दूसरों को, वह है।

4

आपके प्रश्न का पहला भाग स्पष्ट रूप से आपकी टीम के भीतर संचार समस्याओं की पहचान करता है। क्या आपने दैनिक स्टैंडअप की कोशिश की है ?

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

आपके मामले में, मैं संबंधित डेवलपर के काम पर लौटने के कुछ दिनों बाद प्रतीक्षा करूंगा। फिर उन मानकों के बारे में बात करने के लिए एक बैठक का आयोजन करें।

किसी भी मनोवैज्ञानिक ब्लॉक और प्रतिरोध से बचने के लिए, उन व्यक्तियों या विशिष्ट चीजों को नाम न दें जिन्हें आपने देखा था। इसे सामान्य रखें, यहां लक्ष्य हर किसी से इनपुट प्राप्त करना है, जिसमें आपको लगता है कि डेवलपर को अपने काम करने के तरीके में सुधार करना चाहिए। आदमी आपके संगठन को एक गड़बड़ भी मान सकता है।

बैठक के दौरान समस्या पेश करें और स्पष्ट रूप से पूछें कि टीम स्थिति को कैसे सुधार सकती है।

(पूरी) टीम तय करती है कि उसे क्या करना है।


2

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

मुख्य बिंदु तक, हालांकि, नहीं, मैं नहीं चाहता कि मेरे ऊपर कार्य मानकों को लागू किया जाए कि मैं अपने कार्य केंद्र को कैसे व्यवस्थित करूं। मैं वर्तमान में एक IDE पर अपने विभाग के मानकीकरण के बारे में जोर दे रहा हूं (मेरा बॉस वास्तव में हम सभी को ग्रहण में चाहता है क्योंकि यह वही है जो वह उपयोग करता है और जानता है, भले ही आईएमओ यह मेरी नौकरी के लिए सबसे अच्छा उपकरण नहीं है )।

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


1
वह कैसे मदद करेगा? यह प्रश्न अभी भी मौजूद है, हम सिर्फ अपने स्थानीय DVCS रिपॉजिटरी के बजाय किस कार्यक्षेत्र के बारे में बात कर रहे हैं।
जॉन हॉपकिंस

इसके औजारों को ग्रहण न करें - इसकी भी सराहना की जा सकती है कि जिन साधनों की कमी हो सकती है उनका उपयोग कैसे किया जाए। दूसरों को दिखाए जाने की कुछ जरूरतों के लिए क्या स्पष्ट है। स्रोत वृक्ष की बहुत सी प्रतियों का प्रतिरूप मैंने कई बार देखा है। हां, DVCS मदद कर सकता है - लेकिन इस संदर्भ में हमारे पास अभी भी सही शाखा की पहचान करने के साथ एक समस्या है और - अगर हम आगे जाना चाहते हैं - उन कार्य को प्रगति शाखाओं में उपलब्ध कराने के साथ। @Jon स्थानीय DVCS को स्वचालित रूप से उस उपयोगकर्ता के "बैकअप" को उनकी रिपॉजिटरी पर धकेलना चाहिए। बहुत कम से कम अगर समस्या उनके बॉक्स से दूर जाती है।
मर्फ़

@Jon - मुझे लगता है कि बिंदु है, उसकी विविध शाखाएँ कुछ इस तरह की होंगी कि इसमें बनाई गई कार्यक्षमता को विलय करना होगा, बल्कि फाइलों को हटाने की निर्देशिकाओं को बिखेरना होगा। इसके अलावा, उसे उठना और DVCS पर जाना एक प्रशिक्षण अवसर होता।
दान रे

1
@ दान - लेकिन उन शाखाओं में से कुछ मृत अंत हैं - अवधारणा के प्रमाण, मिश्रित डिबग कोड वाली चीजें जिसमें आप विलय नहीं करना चाहते हैं, पुराने संस्करण। तथ्य यह है कि आपके पास मर्ज की कार्यक्षमता है, जब आप नहीं जानते कि आपको क्या विलय करना चाहिए।
जॉन हॉपकिंस

@ जॉन - मुझे लगता है कि यह सच है। हो सकता है कि किसी से वास्तव में कोई गड़बड़ी करने के लिए प्रतिबद्ध कोई वसूली नहीं है।
दान रे

2

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

एक बार कोड एक ऐसी स्थिति में था कि यह विकास शाखा पर स्थिर था, जिस शाखा के साथ आप एकीकृत करने जा रहे थे, उसमें से एक कोड को ड्रैगिंग कोड में किया गया था। एक बार जब आप उस मर्ज का परीक्षण कर लेते हैं, तो यह केवल एकीकरण शाखा में कोड को लागू करने का मामला होगा - इसके लिए आपको किसी विलय की आवश्यकता नहीं होगी क्योंकि आप अपनी शाखा में पहले ही विलय कर चुके हैं।

इस तरह, आप डेवलपर्स की समस्या को बचाने के लिए कोड के टूटने के बारे में चिंता कर रहे हैं - और आप इसे रात में कार्यालय छोड़ने से पहले कोड को चेक करने के लिए सुपर स्वीकार्य बनाने की सामाजिक नीति लागू करना शुरू कर सकते हैं - अच्छा और सुरक्षित।


2

में इस विशेष स्थिति कॉल घर पर व्यक्ति, यह बहुत स्पष्ट आप पर शक नहीं कर रहे हैं कि वह बीमार है, लेकिन आप किसी और की है अपने काम जारी रखने के लिए, और पूछते हैं कि नवीनतम सामान है और क्या राज्य में की जरूरत है।

फिर आपको यह विचार करने की आवश्यकता है कि यहां से क्या करना है। यदि समस्या यह है कि लोग बहुत कम मात्रा में जांच करते हैं, तो वितरित स्रोत नियंत्रण प्रणाली का उपयोग करने पर विचार करें जो लोगों को एक दूसरे को परेशान किए बिना शाखाओं में काम करने की अनुमति देता है।

यदि समस्या यह है कि आप डेवलपर्स को अपनी मशीन पर कई कार्यस्थानों को पसंद नहीं करते हैं, तो इसे खत्म कर दें। कार्य शैली व्यक्तिगत है और आपको मूल रूप से स्रोत रिपॉजिटरी के नियमों के साथ ठीक काम करने के लिए मूल रूप से अपने सिस्टम से दूर रहना चाहिए। व्यक्तिगत रूप से मैं अलग-अलग परियोजनाओं के लिए बहुत बार एक नई प्रति की जांच करता हूं और केवल एक बार में ही साफ कर देता हूं।

यदि समस्या यह है कि आपको नहीं पता कि आपका डेवलपर क्या कर रहा है, तो समस्या राजनीतिक नहीं तकनीकी है, और आपको अपनी प्रबंधन शैली को बदलने की आवश्यकता है। कृपया याद रखें कि डेवलपर्स अत्यधिक कुशल व्यक्ति हैं, जो शायद ही कभी micromanagement पसंद करते हैं और आपको प्रतिनिधि करना पड़ता है । अन्यथा आप सबसे कुशल व्यक्तियों को दूर धकेल देंगे।

इसलिए, मैं आम स्रोत रिपॉजिटरी के साथ काम करने के लिए बेहतर तरीके को प्रोत्साहित करने की सिफारिश करूंगा - यह कहना कि यह लोगों के लिए शाखाओं में काम करने के लिए ठीक है, और जब तक वे मास्टर रिपॉजिटरी में अपनी स्थानीय कॉपी को दैनिक रूप से सिंक्रनाइज़ नहीं करते हैं, तब तक वे (जैसा कि वे करते हैं) हमेशा एक शाखा में विकास कार्य करेंगे जो दूसरों को प्रभावित नहीं करेगा)।


1
मैंने विशेष रूप से सवाल में कहा था कि व्यक्ति से संपर्क नहीं किया जा सकता है।
जॉन हॉपकिंस

@ जों, उस मामले में अपने अधूरे काम को खो जाने पर विचार करें, इसे किसी अन्य प्रोग्रामर को सौंप दें, और फिर इस बात पर विचार करना शुरू करें कि यह पहले स्थान पर क्यों हुआ।

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

@ मर्फ़, तो "कमिट अक्सर - एक शाखा में" का नियम लागू करते हैं और कम से कम रोज़ाना केंद्रीय धक्का देते हैं।

1

तो आप इस तरह की स्थितियों को कैसे संभालते हैं?

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

या क्या आप डेवलपर्स से इस क्षेत्र में मानकों का पालन करने के लिए कहते हैं - विशिष्ट निर्देशिकाओं का उपयोग, मानकों का नामकरण, विकी पर नोट्स या जो भी हो?

हमारे पास एक विशाल पर्यावरण विन्यास दस्तावेज है जो सम्मेलनों को दर्शाता है, लेकिन एक मानक नहीं है। उत्पादन कोड और वातावरण के लिए मानक हैं। हालाँकि, हमारे कई विकास उपकरण सम्मेलनों का समर्थन करने के लिए तैयार हैं और अधिकांश डेवलपर्स इस प्रवृत्ति को कम करने का प्रयास नहीं करते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.