एक प्रोग्रामर को किसी और के असफल निर्माण को ठीक करना चाहिए? [बन्द है]


45

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

क्या दूसरे प्रोग्रामर ने सही काम किया या उसे पहले प्रोग्रामर के इश्यू के ठीक होने तक इंतजार करना चाहिए था?


31
प्रश्न: एक प्रोग्रामर सदस्य ने एक प्रश्न पूछा। एक अन्य सदस्य ने प्रश्न को पढ़ा और कुछ वाक्यात्मक और व्याकरण संबंधी त्रुटियों को देखा, इसलिए उन्होंने प्रश्न को संपादित करने और उन्हें सही करने के लिए प्रश्न को पढ़ने के लिए थोड़ा आसान बनाने का फैसला किया। क्या संपादक ने सही किया या उन्हें त्रुटियों को ठीक करने के लिए पोस्टर का इंतजार करना चाहिए था?
yannis

2
इस स्थिति के लिए आपकी टीम के नियम क्या हैं?

4
@ साहब ओह, चिंता मत करो, मैं यह नहीं कह रहा हूं कि यह एक समस्या है :)। बस एक समुदाय में, एक टीम के रूप में, एक दूसरे की मदद करने वाले सदस्यों को प्रोत्साहित किया जाना चाहिए। इसके अलावा, मुझे नहीं लगता कि किसी निर्माता का निर्माण तोड़ना अव्यावहारिक है, भले ही मामूली बग के लिए, ये चीजें हममें से सबसे अच्छी होती हैं।
यानिस y

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

14
यदि आप विपरीत मानते हैं तो यह बहुत आसानी से समझ में आता है - यदि निर्माण टूट गया है, तो पूरी टीम को धीमा कर देना (घर पर भी, घंटों के बाद) और आप इसे ठीक कर सकते हैं, लेकिन प्रक्रिया के कुछ बिंदु के कारण जानबूझकर चुनाव न करें , क्या आपको अपनी नौकरी रखने की अनुमति दी जानी चाहिए?
बिल के

जवाबों:


87

यह कुछ हद तक इस बात पर निर्भर करता है कि आपकी टीम आमतौर पर कैसे काम करती है, लेकिन मैं कहूंगा कि यह ठीक था। बिल्ड वर्किंग रखने से हर किसी का समय बचता है।

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


101
इसके पहले डेवलपर को डोनट्स खरीदने के लिए विनम्र निर्माण करने के लिए
jk।

17
मैं डोनट्स के बजाय बीयर पसंद करूंगा।
मार्टिन न्यूयॉर्क

2
डोनट्स लस असहिष्णु के लिए आक्रामक हो सकता है। सर्वश्रेष्ठ खरीदारी के लिए $ 5 उपहार कार्ड, दूसरी ओर ...
क्रिस्टोफर महान

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

1
आप $ 5 के तहत सर्वश्रेष्ठ खरीद पर क्या प्राप्त कर सकते हैं?
केविन क्लाइन

12

निर्भर करता है।

  • क्या बग इतना स्पष्ट है कि लाइब्रेरी को जोड़ना इसे ठीक करने का तरीका है? कभी-कभी फ़िक्स उस लाइब्रेरी की आवश्यकता नहीं करने के लिए वर्कअराउंड ढूंढने में होता है।

  • क्या परियोजना एक ऐसे चरण में है जहां सभी परिवर्तन मौजूदा टिकट से जुड़े होने चाहिए? यदि हां, तो क्या आपने टिकट दर्ज किया है? क्या वह टिकट आपको सौंपा गया है?

वैसे भी, बग को ठीक करने पर ध्यान दें, जिम्मेदार को दोष देने पर नहीं।


9
"... जिम्मेदार को दोष देने पर नहीं।" जब तक यह एक नियमित घटना नहीं है।
शॉन डी।

11

हायह ठीक है। हालांकि, मूल प्रोग्रामर के लिए यह अव्यवसायिक है कि घर पर परीक्षण करने से पहले बिल्ड को संकलित करना होगा।

आपकी प्रतिष्ठा आपके नियंत्रण में 100% है। इस तरह सामान आपकी प्रतिष्ठा को धूमिल करता है और एक कलंकित प्रतिष्ठा को चमकाने की कोशिश करना बहुत मुश्किल है।


2
बिल्ड का परीक्षण करने के लिए पहले डेवलपर पर ओनस लगाने के लिए +1। दूसरा पैराग्राफ वास्तव में सही या प्रासंगिक नहीं है। अन्य लोग आपकी प्रतिष्ठा को नुकसान पहुंचा सकते हैं, या तो जानबूझकर या नहीं, तब भी जब आपका व्यवहार पूरी तरह से बोर्ड से ऊपर हो।
कालेब

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

7

संवाद

उन परिदृश्यों के लिए कोई सख्त नियम (अपनी टीम के नियमों के बगल में) नहीं है।

Dev2 को देव को यह बताने में सक्षम होना चाहिए कि वह अपनी त्रुटि को ठीक कर सकता है, न ही उनमें से किसी को इस विनिमय के परिणामस्वरूप कुछ डरना चाहिए, वे एक टीम का हिस्सा हैं।


5

क्यों नहीं? यदि आपका उत्पाद दोषों को ठीक करने से अधिक महत्वपूर्ण है, तो यह निश्चित रूप से ठीक है। हालांकि लाइब्रेरी चेंज के कारण एक बिल्ड फेल हो रहा है, यह काफी लचर है और आपको इसकी टेस्टिंग नहीं करने के लिए डेवलपर को फटकार लगानी होगी।


3

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

जैसा कि कहा गया है, जिस आदमी ने इसे ठीक किया है, उसे शायद उस आदमी को ईमेल करना चाहिए जिसने इसे तोड़ा है और यह तय किया है कि यह क्या था।


2

मेरा आदर्श वाक्य, 3pm के बाद एसवीएन के लिए प्रतिबद्ध नहीं है जिस तरह से आप हमेशा अपनी खुद की बिल्ड विफलताओं को ठीक कर सकते हैं।

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

किसी तरह की 'पॉइंट ऑफ़ फिंगर ऑफ़ ब्लेम' स्क्रिप्ट ऐसा करने का एक अच्छा तरीका है, या उस व्यक्ति को बनाओ जो बिल्ड बाय डोनट्स खरीदता है !!


2
हमारे CI टूल में वास्तव में डेवलपर को ई-मेल भेजने का एक विकल्प है जिसने बिल्ड (टीम के बाकी हिस्सों के अलावा) को तोड़ दिया।
TM33

2

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

मैं एक व्याख्यात्मक ई-मेल भेजने के ल्यूक ग्राहम के सुझाव से सहमत हूं, हालांकि मैं कहूंगा कि यह विनम्र से अधिक है - यह बुनियादी संचार है।


एकीकरण के साथ कभी-कभी आपके सिस्टम की जटिलता के आधार पर एक घंटे या उससे अधिक समय का निर्माण होता है, आपको यह सुनिश्चित करने के लिए हर दिन "प्रतिबद्ध कटऑफ" लागू करना होगा ताकि यह सुनिश्चित हो सके कि दिन का आखिरी निर्माण हर किसी के पास हो। फिर भी, लोगों को डॉक्टर की नियुक्तियों, बच्चों के फुटबॉल अभ्यास, आदि की आवश्यकता होती है और निर्माण की स्थिति की परवाह किए बिना तुरंत बाहर निकालना पड़ता है। एजाइल का कहना है कि काम एक स्थायी गति से होना चाहिए और श्रमिकों पर एक नाली नहीं होनी चाहिए। बिल्ड सफल देखने के लिए उन्हें 8:00 बजे तक वहीं रखना इसके विपरीत है।
कीथ्स

@ केक: सच। लेकिन मैंने पाया है कि जब भी मैं छोड़ता हूं, तो बिल्ड के लिए मेरे लिए सबसे संभावित समय तब होता है जब मैं जल्दी में होता हूं: दोपहर के भोजन से ठीक पहले, बैठक से ठीक पहले, दिन के अंत से ठीक पहले। इसलिए मुझे लगता है कि बाद में निर्माण को देखने और ठीक करने के लिए पर्याप्त समय नहीं होने के कारण कुछ भी नहीं करने के लिए यह "व्यक्तिगत सर्वोत्तम अभ्यास" है।
डैनियल प्रीडेन

2

हाँ हाँ हाँ! यह सामूहिक कोड स्वामित्व को बढ़ावा देता है और एक उच्च मानक रखने के लिए और टूटी हुई खिड़की के परिदृश्य को विकसित नहीं होने देने के लिए टीम में एक प्रकार का स्वस्थ सहकर्मी-दबाव सेट करता है। दूसरे डेवलपर को बताने के लिए संचार का एक अच्छा विचार है।


2

मुझे लगता है कि स्पष्ट चीजों को ठीक करना ठीक है - यानी, यदि आप 100% सुनिश्चित हैं कि जिस व्यक्ति का कोड आप ठीक कर रहे हैं, वह वही बना देगा - या काफी हद तक वही - फिक्स। यदि फिक्स अधिक जटिल है, तो यह आमतौर पर उस व्यक्ति से बात करने के लिए विनम्र है जिसका कोड आप ठीक कर रहे हैं - यह हो सकता है कि आप इरादे को गलत समझे या टूटने का कारण वह नहीं है जो आपने सोचा था कि, या हो सकता है कि उसने एक और तय किया हो लेकिन किसी कारण के लिए यह अभी तक नहीं कर सका (जीवन होता है, आप जानते हैं :)।

सामान्य तौर पर, नियम आमतौर पर है: आप बिल्ड को तोड़ते हैं - आप बिल्ड को ठीक करते हैं, लेकिन अपवाद हैं, खासकर अगर फिक्स स्पष्ट है और / या जिम्मेदार व्यक्ति पहुंच से बाहर है।

बेशक, अगर आपके पास सीरियल बिल्ड ब्रेकर का मामला है - विशेष रूप से पैटर्न के साथ "चेक इन, होम, बिल्ड टूट गया दिनों के लिए" - जिम्मेदार व्यक्ति को इस बारे में कुछ बात करने की आवश्यकता है कि सीआई सिस्टम और परीक्षण मौजूद क्यों हैं और एक को कैसे होना चाहिए जाँच करने से पहले जाँच करें :)


1

चीजें होती रहती हे। तोड़फोड़ करने के लिए एक नया कोड फ़ाइल (चाहे स्रोत या संकलित) को जोड़ने की विफलता संभवतः टूटी हुई बिल्ड्स का सबसे आम कारण है, यह मानते हुए कि यह डेवलपर के कंप्यूटर पर काम करता है। सीआई वातावरण के साथ मेरी आखिरी नौकरी में, यहां तक ​​कि सबसे वरिष्ठ लोग कभी-कभी भूल गए।

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


1

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


0

इसे ठीक करना तब तक ठीक है जब तक कि यह नियमित रूप से होने वाली स्थिति में न हो कि मैं किस स्थिति में बॉस को बुलाऊं और उसे वापस कर दूं और इसे स्वयं ठीक कर दूं।


0

यह निर्भर करता है, यह निर्भर करता है ...

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

वैसे भी, नवीनतम आदमी है कि एक अजीब टोपी पहनने के लिए निर्माण तोड़ दिया अगली बार ^ _ ^ पर अधिक ध्यान देने के लिए पर्याप्त है


0

कुछ वातावरणों में, यह बहुत अशिष्ट है, और अच्छे कारणों के लिए। अन्य वातावरणों में, यह अपेक्षित है, और अच्छे कारणों के लिए।

अभी भी अन्य वातावरणों में, यह बहुत अशिष्ट है या बहुत खराब कारणों से अपेक्षित है।

यह काफी हद तक इस बात पर निर्भर करता है कि टूटा हुआ निर्माण कितना महत्वपूर्ण है और एक सत्यापित सही निर्माण कितना महत्वपूर्ण है। और कुछ हद तक, यह इस बात पर निर्भर करता है कि यह तय कितना सही था और केवल एक की जरूरत थी।


0

पहला, 'घर चला गया' एक एकवाद है। प्रोग्रामर अब घर नहीं जाते हैं - वे सिर्फ ऑनलाइन या ऑफलाइन हैं। आप पिंग कर सकते हैं और प्रतीक्षा कर सकते हैं।

अधिक गंभीरता से, वास्तव में प्रश्न के दो भाग हैं। 'कोड परिवर्तन के माध्यम से देखना' ठीक है; आराम करना सही बात नहीं हो सकती है। क्या होगा अगर एक लापता पुस्तकालय का उसका निर्णय गलत था?

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