कीड़े को पुन: पेश करने की जिम्मेदारी

Question

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

1. क्या वह सही है?
2. इस स्थिति में मैं क्या कर सकता हूं? यूनिट टेस्ट बनाना असंभव है, क्योंकि यह कुछ रैंडम नेटवर्क टाइमिंग पर निर्भर करता है।

Comments

यदि आप इकाई परीक्षण लिखने जा रहे हैं, तो आप बग को ठीक कर सकते हैं और पूरी बात का श्रेय ले सकते हैं।

— जेएफओ

@ जेफ़ो, वह उस पुस्तकालय का प्रबंधन कर रहा है और बगफिक्स को स्वीकार नहीं करेगा। क्योंकि "वह आश्वस्त नहीं है कि बग कभी अस्तित्व में था"

— user626528

संबंधित: मैं बग को पुन: उत्पन्न करने के लिए मुश्किल से अलग कैसे करूं? संभव डुप्लिकेट: एक बग को दूर करें यदि कोई प्रतिलिपि प्रस्तुत करने योग्य परीक्षण मामला मौजूद नहीं है? और क्या हमें हमेशा यूनिट के कीड़े को ठीक करते समय परीक्षण करना चाहिए?

— जन्नत

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

— जोशुआ ड्रेक

संबंधित: एक "

— मंडेलबग

Answer 1

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

मैं उसके साथ बग को बढ़ाऊंगा (जो आपने किया है), अगर यह आपकी परियोजना के साथ कोई समस्या पैदा कर रहा है तो मैं इसे आपके प्रोजेक्ट मैनेजर के साथ अवरोधक के रूप में उठाऊंगा और यह स्पष्ट कर दूंगा कि आपने बग को उचित तरीके से उठाया है। यदि यह शीघ्रता से तय नहीं किया गया तो व्यक्ति आपकी परियोजना को प्रभावित करने वाला है।

मैं डेवलपर के साथ बात करूंगा और समझाऊंगा कि यूनिट टेस्ट्स बनाना क्यों मुमकिन है लेकिन आप उसे अपनी मशीन पर दिखाते हुए खुश होंगे (यह मानते हुए कि यह संभव है?)।

Answer 2

वह 100% सही है कि आपको बग को प्रतिलिपि प्रस्तुत करने योग्य बनाने के लिए पर्याप्त जानकारी प्रदान करनी चाहिए - अन्यथा यह पता लगाने का कोई मौका नहीं है कि क्या वह जो भी प्रदान करता है वह वास्तव में काम करेगा।

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

Comments

इसलिए यदि कोई ऐप उपयोगकर्ता के लिए "हर अब और फिर" दुर्घटनाग्रस्त हो जाता है, तो डेवलपर को इसे ठीक करने की आवश्यकता नहीं है क्योंकि उपयोगकर्ता इसे कमांड पर पुन: पेश नहीं कर सकता है? मैं यहाँ दृढ़ता से असहमत हूँ ...

— Heinzi

@ हिनजी: अगर मुझे एक बग रिपोर्ट मिलती है "ऐप हर बार दुर्घटनाग्रस्त हो जाता है", तो मैं उस मुद्दे को काम करने के लिए बहुत कम प्राथमिकता देता हूं। न्यूनतम चीज़ जो मैं उम्मीद करता हूँ कि उपयोगकर्ता को लिखना है कि "अब और फिर" कितनी बार है, वह वही कर रहा था जो उस समय एप्लिकेशन के साथ था जब ऐप ने पिछली बार क्रैश किया था, और सटीक त्रुटि संदेश।

— डॉक्टर ब्राउन

@ user626528: IMHO पुस्तकालय के मालिक को आपके द्वारा बग को पुन: पेश करने के लिए बताए गए चरणों के माध्यम से जाने की कोशिश करनी चाहिए - जब तक आपका विवरण किसी बग को नहीं दिखाता है तब तक उसे 500 अलग-अलग परिदृश्यों का प्रयास करने के लिए नहीं चाहिए।

— डॉक ब्राउन

रिपोर्टर को प्रजनन कदम प्रदान नहीं करना चाहिए; अक्सर हम दुर्घटनाग्रस्त प्रक्रिया से बस एक डंप संलग्न करते हैं, खासकर अगर यह एक स्वचालित रन के दौरान होता है। यह पुनरुत्पादन चरणों को खोजने की जिम्मेदारी है, ताकि फिक्स को सत्यापित किया जा सके।

— अवतार

(इसका मतलब यह नहीं है कि रिपोर्टर को मददगार होने की कोशिश नहीं करनी चाहिए और यदि उन्हें पता है तो उन्हें कदम प्रदान करना चाहिए। छिटपुट दुर्घटनाओं के लिए, हालांकि, रिपोर्टर का यह दायित्व नहीं है कि वह उस चीज़ पर शोध करने के लिए समय जलाए जो घटक मालिक शायद तेज़ी से समझ जाएगा। )

— अवकर

Answer 3

दोनों पक्षों को कुछ प्रयास करना चाहिए।

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

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

Answer 4

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

लेकिन आपके पास सीमित मात्रा में ऐसे उत्पाद पर काम करने में खर्च होता है जो आपके हित के लिए परिधीय हो। दुर्भाग्य से, इसका मतलब यह हो सकता है कि बग मौजूद है, और इसे हल करने पर कोई काम नहीं किया गया है।

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

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

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

Comments

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

— user626528

चूँकि आप एक हैं जो इसे अभी तय करना चाहते हैं, यह आपकी जिम्मेदारी है कि आप उसे समझाएं कि यह अब ठीक करने के लायक है, इसे 10 या 12 साल के बजाय जब उसे ठीक करने के लिए और कुछ भी महत्वपूर्ण नहीं है। theregister.co.uk/2013/01/21/kde_bug_quashed । महत्व के X के एक अप्रतिबंधित बग, और उसी महत्व के एक प्रतिलिपि प्रस्तुत करने योग्य बग को देखते हुए, मैं हर बार प्रतिलिपि प्रस्तुत करने योग्य बग पर काम करूंगा।

— जोर्मेनो

बहुत ज्यादा अहंकार। वह उस भयावह पुस्तकालय पर काम करने के लिए भुगतान किया जाता है।

— user626528

@ user626528: यह अहंकार के बारे में नहीं है, यह प्राथमिकताओं के बारे में है - एक बग लोअर की पुनरावृत्ति करने में असमर्थता यह प्राथमिकता है। दो EOI (Execute Operator तुरंत) बग, एक प्रतिलिपि प्रस्तुत करने योग्य और एक नहीं, को देखते हुए, मैं उस पर काम करूंगा जिसे पहले पुन: प्रस्तुत किया जा सकता है, और मैं किसी अन्य डेवलपर को भी ऐसा करने के लिए कहूंगा। और अगर पुस्तकालय का इतना उपयोग नहीं किया जाता है, तो मैं किसी अन्य परियोजना पर पूरी तरह से काम कर सकता हूं - भले ही उसमें कीड़े उतने महत्वपूर्ण न हों। यदि वह इस पुस्तकालय में काम करने के लिए पूरी तरह से / भुगतान किया जा रहा है और इस के अलावा कोई बकाया सुविधा अनुरोध या बग नहीं हैं, तो हाँ उसे बस करना चाहिए।

— जोमेरो

Answer 5

मैं सोते हुए कुत्तों को झूठ बोलने के लिए प्रेरित करूंगा - आपने इस मुद्दे को उठाया है और यह उसे सौंपा गया है। संभवतः बकाया कीड़े को ट्रैक करने और उनका पीछा करने के लिए जगह में प्रक्रियाएं हैं?

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

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

Answer 6

आपको एक बग मिला, आपने इसे रिपोर्ट किया और वह इसके बारे में एक झटका है।

अगर आप दोनों करीबी दोस्त होते तो वह मदद करने के लिए कुछ करता, लेकिन वह सिर्फ इस मुद्दे को पीछे धकेल देता।

आप अधिक विवरणों को दर्ज करके और अपने दावों का समर्थन करने की कोशिश कर सकते हैं कि यह मेमोरी लीक कर रहा है। फिर भी, आपकी अपनी जिम्मेदारियां हैं और आपको अपना काम पूरा करने की जरूरत है।

बग ट्रैकर में अधिक से अधिक जानकारी लॉग इन करें और कर सकते हैं।

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

Comments

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

— रॉबी डे

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

— रिएक्टगुलर

Answer 7

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

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

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

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

Comments

मेरी सहानुभूति है कि कोई आपके उत्तर पर विचार कर रहा है (जो व्यावहारिक संभावना है) बुरा और उसे वोट देना। वही मेरे जवाब के लिए हुआ है।

— isnn

Answer 8

आपने उल्लेख किया है कि 'मैंने इस रिसाव को करने के लिए शर्तों के विवरण के साथ एक बग दर्ज किया।'

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

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

यदि यह काम नहीं करता है, तो आपके पास निम्नलिखित विकल्प हैं:

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

Comments

लाइब्रेरी मेंटेनर के लिए यूनिट टेस्ट बनाना ओपी की जिम्मेदारी नहीं है।

— एंडी

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

— डैन नेली

@DanNeely: वह नजरअंदाज नहीं कर रहा है, वह दावा कर रहा है कि रिपोर्टर को कुछ और करना है - जो रिपोर्टर के लिए करना संभव नहीं है। और रिपोर्टर को वापस संवाद करना होगा! मैंने प्राधिकरण को शामिल करने का भी सुझाव दिया है, क्योंकि यह उस पर उतर सकता है।

— isnn

@Andy कुछ स्थितियों में यह कॉर्पोरेट नीति है कि बग बिना स्वचालित परीक्षण के स्वीकार नहीं किए जाते हैं।

— जोशुआ ड्रेक

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

— दान नीली