क्या मुझे किसी को बताना चाहिए कि उनकी प्रतिबद्धता के कारण प्रतिगमन हुआ?

Question

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

क्या यह करने योग्य है? क्या यह उस व्यक्ति को इंगित करने के लिए रचनात्मक है जिसने प्रतिबद्ध किया था? क्या गलती की प्रकृति (जिस कोड को उन्होंने बदल दिया है, उसकी मूलभूत गलतफहमी के लिए सरल असावधानी के पैमाने पर) यह एक अच्छा विचार है या नहीं?

यदि उन्हें यह बताना एक अच्छा विचार है, तो अपराध किए बिना या रक्षात्मक होने के लिए इसे करने के अच्छे तरीके क्या हैं?

तर्क के लिए, मान लें कि बग पर्याप्त रूप से सूक्ष्म है कि CI सर्वर के स्वचालित परीक्षण इसे नहीं उठा सकते हैं।

Comments

जब आप उसे यह ईमेल भेजते हैं, तो पूरी टीम को CC न करें।

— मात्रा_देव २ quant

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

— जलयान

@ जलयान - मजाक के साथ नहीं - जो कि लोगों को परेशान करता है

— user151019

"मान लें, तर्क के लिए, कि बग पर्याप्त रूप से सूक्ष्म है कि CI सर्वर के स्वचालित परीक्षण इसे नहीं उठा सकते हैं।" क्यों नहीं? क्या यह कुछ ऐसा है जिसके लिए आपके पास परीक्षण नहीं है? यदि यह है, तो आपको जो पहली चीज करनी चाहिए वह एक परीक्षण (या कुछ परीक्षण) लिखनी है जो अब विफल हो जाती है जब बग ठीक हो जाता है। यदि इसका परीक्षण नहीं किया जा सकता है, तो क्यों नहीं?

— थॉमस ओवेन्स

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

— स्कॉट

Answer 1

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

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

Me: मैं इस बग पर काम कर रहा हूँ जहाँ ... बग का सारांश ... और मुझे लगता है कि मैंने समस्या को आपके द्वारा किए गए बदलाव पर नज़र रखी है। क्या आप याद रख सकते हैं कि यह बदलाव किस लिए था? / क्या आपको इस परिवर्तन की व्याख्या करने के लिए कुछ समय मिला है?

तो कोई:

उन्हें: यकीन है, कि संभाल करने के लिए ... स्थिति मैं के बारे में पता नहीं था ...

या कुछ के साथ:

उन्हें: नहीं, माफ करना, मुझे याद नहीं है, मेरे लिए गलत लगता है।

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

यदि मूल कमिटेटर आसपास नहीं है या व्यस्त है तो आप बस के माध्यम से स्लॉग कर सकते हैं और यह सब अपने आप समझ सकते हैं, मुझे आमतौर पर लगता है कि उस व्यक्ति से बात करना जिसने मूल रूप से बदलाव किया है।

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

Comments

"उन्हें: यकीन है, संभाल करने के लिए ... स्थिति मुझे पता नहीं था ..." मैं इस tbh के साथ एक मुद्दा है। यदि उन्होंने प्रभावी रूप से परिवर्तन का दस्तावेजीकरण किया है, तो वह स्थिति ऐसी नहीं होनी चाहिए जिससे आप अनभिज्ञ हों।

— 8

@temptar मेला पर्याप्त - "के साथ" का पता नहीं था "के साथ" के बारे में अभी तक सोचा नहीं था "या जो कुछ भी आप पसंद करेंगे - मेरी बात यह है कि यद्यपि आप अपने लिए यह पता लगा सकते हैं (जैसे प्रलेखन को देखकर), इसके आमतौर पर बस पूछने के लिए जल्दी। बहुत सारे कोड भी उतने प्रलेखित नहीं हैं जितने होने चाहिए।

— जस्टिन

Answer 2

मुखर रहें आक्रामक न हों। हमेशा एहसान करें कि "कोड का यह टुकड़ा काम नहीं कर रहा है" बनाम "आपका कोड काम नहीं कर रहा है"। कोड की आलोचना करें, न कि उस व्यक्ति की जिसने कोड लिखा है।

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

बेशक, आपको अन्य डेवलपर्स को उसी समस्या के साथ आने के लिए सुनने के लिए तैयार होना चाहिए और कार्य करना चाहिए कि आपने कैसे काम किया है।

Comments

+1। व्यक्तिगत पसंदीदा दृष्टिकोण: "इससे पहले कि मैं इसके साथ खिलवाड़ करूं, क्या कोई कारण था कि आपने इसे इस तरह से किया?"

— पीडीआर

+1। "कोड की आलोचना करें, उस व्यक्ति की नहीं जिसने कोड लिखा है।"

— c_maker

+1, यह वैसा ही सलाह है जैसा कि मेरे मैरिज काउंसलर ने मेरी पत्नी और मुझे बताया था, जब आपके पार्टनर के खिलाफ शिकायत हो रही हो , तो आप शब्द से बचें , यह बहुत ही टकराव की स्थिति है।

— maple_shaft

+1, लेकिन मुझे नहीं लगता कि शब्द "आप" टकराव का है। स्वामित्व की स्पष्ट समझ होनी चाहिए। मेरे पास व्यक्तिगत रूप से लोगों के पास लगातार कोड हैं जो निर्माण को तोड़ते थे क्योंकि वे यह नहीं समझते थे कि वे ही थे जो इसका कारण थे। मुझे @ pdr का दृष्टिकोण पसंद है ... यह कथन गैर-टकरावपूर्ण है, फिर भी इसमें "आप" शब्द है।

— टिम रेड्डी

लगता है कि आप एक नए बग को फिर से प्रस्तुत कर सकते हैं। हो सकता है कि उनका फिक्स पिछला मुद्दा सही कर दिया हो जिसके बारे में आपको जानकारी नहीं है। उनके पास क्यों नहीं गए और पूछें कि उन्होंने उस तरह से कोड क्यों लिखा है जो उन्होंने किया था। यह प्रकट हो सकता है कि एक विषम भाषा / डिज़ाइन / vm quirk है जो इसे कवर कर रही थी। जा रहे हैं और उन्हें अपने अहंकार को दिखाते हुए ["विधर्मी कैसे मैं बेहतर कर सकता हूं" उनकी मदद नहीं करेगा]

— भिक्षु

Answer 3

हाँ, हमेशा । एक प्रोग्रामर के रूप में, गलतियों से सीखना आपका काम है।

उन्हें उन गलतियों को बताने दें जो वे करते हैं, इससे उन्हें बेहतर कोडर बनने में मदद मिलेगी और भविष्य में गलती करने की संभावना कम होगी। लेकिन विनम्र मत बनो और इसका एक बड़ा सौदा मत करो, हम सभी हर बार बग बनाते हैं। मुझे लगता है कि एक विनम्र ईमेल लोगों को बताने का एक बहुत ही गैर-टकराव वाला तरीका है।

Comments

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

— फाल्कन

@ फाल्कन अंतर्दृष्टि "हमें एक सभ्य क्यूए की आवश्यकता है" गलतियों से सीखने का एक उदाहरण है। आप यह सोचकर आगे बढ़ सकते हैं कि "हमारे पास क्यूए क्यों नहीं है / हमारे क्यूए को यह समस्या क्यों नहीं हुई"

— मार्कज

@ फाल्कन "ये ऐसी चीजें हैं जो बस होती हैं" <--- यह अकेला ज्ञान है जिसे आप बार-बार लेकिन तुच्छ गलतियों से प्राप्त करते हैं। क्या आपके पास एक अनुभव है जब आप संकलित करते हैं और चीजें काम नहीं करती हैं, तो पहली बार जब आप अपनी वर्तनी और बैंग की जांच करते हैं, तो 10 सेकंड के भीतर बग खत्म हो जाता है। आपके पास ज्ञान है कि "ये ऐसी चीजें हैं जो बस होती हैं", कभी-कभी यही कारण है कि आप 10 सेकंड में 10 घंटे नहीं डिबग करने में सक्षम हैं।

— गैप्टन

@ गैप्टन और मार्कज: वे अच्छे अंक हैं! मैंने उसके बारे में नहीं सोचा।

— फाल्कन

"एक प्रोग्रामर के रूप में अपनी नौकरी गलतियों से सीखने के लिए।" -> "एक इंसान के रूप में ..." अपनी गलतियों से सीखना इस क्षेत्र के लिए कुछ खास नहीं है।

— बुरहान अली

Answer 4

रचनात्मक तरीका बग को खोजना है, इसे ठीक करना है और भविष्य में उत्पन्न होने वाले समान कीड़े से बचने के लिए कार्रवाई करना है।

यदि इसमें लोगों को यह बताना शामिल है कि बग को कैसे लागू किया जाए, तो इसके लिए जाएं।

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

Comments

+1 के लिए "भविष्य में उत्पन्न होने वाले समान कीड़े से बचने के लिए कार्रवाई करें"। वह सबसे महत्वपूर्ण हिस्सा है, IMO।

— एक सीवीएन

The constructive way is to find the bug, fix it and take actions to avoid similar bugs to arise in the future.-> सवाल यह है कि आपने बग पहले ही तय कर लिया है।

— ह्यूगो

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

— जैकब

@ सटोक - मैं सहमत हूँ।

— मौविसील

Answer 5

सामान्य तौर पर, हाँ ।

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

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

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

हमेशा याद रखें कि यदि आप पता लगा सकते हैं कि "बग" में किसने चेक किया है, तो वे आसानी से पता लगा सकते हैं कि उनके कोड को किसने "फिक्स" किया है। यदि आपको लगता है कि वे इस तथ्य के बाद अपने परिवर्तन के बारे में जानने से नाराज / नाराज / शर्मिंदा होंगे, तो पहले से बता दें।

इसके अलावा, बग को ठीक करना आपका एकमात्र विकल्प नहीं है। आप हमेशा अपने इश्यू ट्रैकर में बग की रिपोर्ट कर सकते हैं। यहां फिर से टैक्ट की आवश्यकता होती है - बग की रिपोर्टिंग पूरी टीम को अधिक दिखाई देती है, लेकिन यह लेखक को अपनी गलती को ठीक करने का मौका भी देती है। यदि आप समस्या को ठीक करने के सर्वोत्तम तरीके के बारे में निश्चित नहीं हैं या यदि आपके पास इसे ठीक करने का समय नहीं है, तो रिपोर्टिंग सबसे अच्छा विकल्प है।

Comments

मुझे पसंद है "मैं इसे बहुत नहीं समझता, क्या आप मुझे समझा सकते हैं कि यह कैसे काम करता है?" दृष्टिकोण। यदि यह जानबूझकर (और हाल ही में) है, तो मूल प्रोग्रामर को यह अच्छी तरह से समझाने में सक्षम होना चाहिए कि कोड कैसे काम करता है। यदि यह एक बग है, तो संभावनाएं अच्छी हैं कि यह समझाने में कि कोड क्या करता है, एस / वह गलती करेगा और स्पष्टीकरण के बीच में आपको "उफ़" सुनाएगा। किसी भी तरह से, किसी को भी यह महसूस करने के लिए कठोर दबाया जाएगा कि वे एक संभावित त्रुटि के लिए उन पर उंगली उठाए हुए हैं।

— सीवीएन

+1 के लिए "यह एक बग जैसा दिखता है, लेकिन इससे पहले कि मैं आपके कोड के साथ खिलवाड़ करूं, मैं इसे आपके द्वारा चलाना चाहता था।"

— बजे रसेल बोरोगोव

Answer 6

अगर मैं एक कमिट करता हूं जिसमें बग शामिल है, तो आपने मुझे बेहतर बताया था। अगर मुझे आपकी एक कमेटी मिली जिसमें बग शामिल है, तो मैं आपको जरूर बताऊंगा।

हम केवल तभी सुधार करते हैं जब हम अपनी त्रुटियों को समझते हैं। इसी तरह हम भविष्य में बेहतर कोड का उत्पादन करते हैं।

Answer 7

आपको यहाँ बेहतरीन उत्तर मिल रहे हैं।

मैं केवल एक तकनीक जोड़ सकता हूं जो मैंने एक प्रबंधक से सीखी थी जब मैं एक गलती करूंगा।

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

उसने लगभग क्षमाप्रार्थी लहजे में मुझसे कहा कि कोई समस्या लग रही थी, और क्या मुझे इस पर गौर करने का समय मिलेगा?

अक्सर पर्याप्त, त्रुटि मेरी थी, और वह यह जानती थी। वह कौशल है।

Answer 8

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

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

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

Answer 9

आपके प्रश्न पर अच्छा कर्षण! सभी ने आपको बताया कि आप क्या करते हैं। क्या आपको बताना चाहिए? हाँ! कभी भी यह सवाल पूछा जाता है कि "क्या मुझे अधिक संवाद करना चाहिए?", इसका उत्तर लगभग हमेशा ही होता है!

लेकिन कुछ अलग करने के लिए: आपका आधार त्रुटिपूर्ण है।

एक सहकर्मी ने एक ऐसा कमिट किया जो सीआई को नहीं तोड़ पाया, लेकिन आपको एक समस्या का पता लगाने के लिए प्रेरित करता है।

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

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

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

Answer 10

हमेशा दूसरे व्यक्ति को अपने से बेहतर मानें, हमेशा दूसरों की अच्छी विशेषताओं को देखें और हमेशा यह जानें कि मैं भी गलतियाँ कर सकता हूँ।

उन्हें बताएं कि कब आप दोनों में से केवल एक है।

Comments

अंतिम वाक्य के लिए +1। सार्वजनिक में प्रशंसा करें, निजी में आलोचना करें।

— स्कॉट सी विल्सन

Answer 11

अगर किसी को बुरा लगता है जब आपने कहा कि उसने गलती की है, तो इसका मतलब है कि वह सोचता है कि वह पृथ्वी पर सबसे बुद्धिमान है और कोई गलती नहीं करता है, और जब आलोचना की जाती है, तो वह महसूस करता है, जैसा कि हमने पोलैंड में कहा था, 'ताज से गिर रहा है उसका सिर'।

इसलिए आपको यह कहने में संकोच नहीं करना चाहिए कि किसी ने गलती की है। यह सामान्य है। हर कोई गलती करता है, यहां तक ​​कि सबसे अच्छा! केवल जो कुछ भी नहीं बनाते हैं वे कोई गलती नहीं करते हैं;)

Comments

यह सब है कि कैसे आप उस व्यक्ति को बताते हैं जिसमें उन्होंने गलती की। मैं हर समय गलतियाँ करता हूँ और किसी के लिए प्रसन्नता व्यक्त करूँगा ताकि मैं उनमें सुधार कर सकूँ लेकिन अगर आप आते हैं और मुझे बताते हैं "यार, आपकी अंतिम प्रतिबद्धता ने कोड को पूरी तरह से तोड़ दिया है। आप अपनी गलतियों की जाँच करने में बेहतर क्यों नहीं हो सकते। ? " मैं निश्चित रूप से नाराज होने जा रहा हूँ।

— द जुग

हां, हालांकि सवाल "दोस्त, क्या आपने प्रतिबद्ध होने से पहले जूनियर परीक्षण चलाए हैं?" मुझे लगता है, पूरी तरह से स्वीकार्य :)

— डैनुबियन नाविक

+1 केवल उन लोगों के लिए जो बिना कुछ किए गलती करते हैं । जाहिर है जब यह स्पष्ट है, लेकिन मैंने इसे इतने करीने से पहले नहीं देखा है।

— FumbleFingers

Answer 12

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

Answer 13

मुझे यहाँ एक भी उत्तर क्यों नहीं दिख रहा है जो प्रश्न पर शीर्ष मतदान टिप्पणी को दर्शाता है ??

हां, उन्हें इसके बारे में बिल्कुल बताएं, लेकिन पूरी टीम के सामने ऐसा न करें

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

मैं आमतौर पर यह सबसे अच्छा काम करता है जब आप एक तारीफ के साथ शुरू करते हैं और फिर त्रुटि के लिए मिलता है ... कुछ इस तरह "ठीक है कि आप लागू महान काम करता है, लेकिन यह टूट एक्स, वाई, जेड" या "एक करने के लिए धन्यवाद" लगता है , b, c, लेकिन यह x, y, z को उत्पन्न करता है।

Answer 14

सरल उत्तर: हाँ।

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

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

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

Comments

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

— स्टुअर्ट वुडवर्ड

Answer 15

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

Answer 16

खेलने में बहुत सारे कारक हैं।

• बग कितना गंभीर है?
• आपके और ब्रेकर के बीच वरिष्ठता संबंध क्या है?
• टीम कितनी व्यस्त / तनावग्रस्त है?
• क्या ब्रेकर कोडबेस या आपके हिस्से में काम कर रहा था?
• आप कितने निश्चित हैं कि यह एक बग था, और आप कितने निश्चित हैं कि आपका फिक्स सही है?

यदि समस्या मामूली थी - एक टाइपो / थिंक / कट एंड पेस्ट बग - और ब्रेकर एक व्यस्त सहकर्मी है, और आप समस्या के अपने आकलन में आश्वस्त हैं, तो आपको शायद उनके ध्यान में लाने की आवश्यकता नहीं है। (जैसे foo.x = bar.x; foo.y = bar.y, foo.z = bar.y)।

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

यदि त्रुटि की प्रकृति एक गंभीर गलतफहमी (कार्यान्वयन मंच, स्थानीय नीतियों, या परियोजना की कल्पना) को इंगित करती है, हालांकि, इसे एएसएपी तक लाया जाता है।

यदि आप अपने मूल्यांकन के बारे में निश्चित नहीं हैं, तो उन्हें अपने फिक्स की समीक्षा करने के लिए कहें, खासकर यदि यह कोड में नहीं है जिससे आप बहुत परिचित हैं। (मैं दृढ़ता से अनुशंसा करता हूं कि आपकी देव टीम एक 'कोड मित्र' नीति अपनाए, जहां चेकइन से पहले किसी अन्य व्यक्ति द्वारा सभी परिवर्तनों की समीक्षा की जाए, वैसे भी)

Answer 17

यदि आप उन्हें नहीं बताते हैं तो क्या होता है?

विपक्ष

वे अन्य स्थानों पर भी यही गलती कर सकते हैं क्योंकि वे नहीं समझते कि इससे समस्या पैदा हो रही है। इतना ही नहीं बल्कि एक ही गलती को बार-बार ठीक करने के लिए अतिरिक्त अनावश्यक समय होगा। आप उन गलतियों से नहीं सीख सकते हैं जिनसे आप अनजान हैं।

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

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

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

गुण

लोग अपनी गलतियों को इंगित करने के लिए आपसे शर्मिंदा या नाराज नहीं होते हैं।

मुझे लगता है कि मैं उन्हें बताने के पक्ष में दृढ़ता से नीचे आता हूं, लेकिन इसे अच्छी तरह से और निजी रूप से कर रहा हूं। सार्वजनिक अपमान की कोई आवश्यकता नहीं है। यदि व्यक्ति बार-बार वही गलतियाँ करता है या गंभीर गलतियाँ करता है जो समझ की कमी दिखाती है, तो पर्यवेक्षक को भी जागरूक करने की आवश्यकता है।