क्या निदान करने और उसे ठीक करने से पहले हर दोष को दोहराने पर जोर देना उचित है?

Question

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

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

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

मेरे लिए, एक मूर्त, दृश्यमान अभिव्यक्ति (क्रम प्रजनन) के बजाय एक सार खाका (प्रोग्राम कोड) से काम करना मुश्किल लगता है, इसलिए मैं एक सामान्य सवाल पूछना चाहता था:

क्या हर दोष का प्रतिकार करने और उसका निदान करने और उसे ठीक करने से पहले डीबग करना उचित है?

या:

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

बहिनों के लिए डिबगिंग है?

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

अंतिम लेकिन कम से कम, यदि आप मुझसे सहमत हैं:

मुझे उन्हें समझाने के लिए अपनी टीम के साथ कैसे बात करनी चाहिए कि मेरा दृष्टिकोण उचित, रूढ़िवादी और अधिक बुलेटप्रूफ है?

Comments

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

— gnat

क्या आप "सही" उत्तर चाहते हैं - आपको हर बग को पुन: उत्पन्न करना होगा ताकि आप उसका निश्चित पता कर सकें, या "ग्राहक हमें $ $ भुगतान करते रहें" जवाब - कभी-कभी आपके पास ऐसा करने के लिए समय और संसाधन नहीं होते हैं, और आपके बॉस को उम्मीद है कि आप अपनी विशेषज्ञता का उपयोग करके इसे ठीक करने का अच्छा प्रयास कर सकते हैं?

— कुटलुमाइक

संबंधित: प्रोग्रामर.स्टैकएक्सचेंज.

— डैन नीली

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

— बेन ली

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

— आहारबुद्ध

Answer 1

क्या हर दोष का प्रतिकार करने और उसका निदान करने और उसे ठीक करने से पहले डीबग करना उचित है?

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

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

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

मुझे किसी ऐसे व्यक्ति पर भरोसा नहीं होगा जो "अपने सिर में" कोड चलाता है, अगर यह उनका एकमात्र तरीका है। यह एक अच्छी जगह के लिए शुरू । बग को पुन: प्रस्तुत करना, और इसे ठीक करना और फिर यह प्रदर्शित करना कि समाधान बग को दोबारा बनने से रोकता है - यही वह जगह है जहां इसे समाप्त होना चाहिए ।

मुझे उन्हें समझाने के लिए अपनी टीम के साथ कैसे बात करनी चाहिए कि मेरा दृष्टिकोण उचित, रूढ़िवादी और अधिक बुलेटप्रूफ है?

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

यदि आप समस्या को ठीक से ठीक करने में विफल रहते हैं , तो आपने ग्राहक के साथ (कुछ हद तक) विश्वास तोड़ दिया है और यदि आपके बाजार में प्रतिस्पर्धी हैं, तो वे आपके ग्राहक नहीं रह सकते हैं।

Comments

"बग को पुन: प्रस्तुत करना, और इसे ठीक करना और फिर यह प्रदर्शित करना कि समाधान बग को पुनः व्यवस्थित करने से रोकता है - यही वह जगह है जहां इसे समाप्त होना चाहिए।" - मेरी बात बिल्कुल

— उभयलिंगी

"क्योंकि अगर उन्होंने बग को कभी नहीं दोहराया, तो वे निश्चित रूप से नहीं जान सकते कि यह तय है।" आमीन ...

— मार्जन वेनेमा

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

— एंडी

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

— 23:14

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

— FrustratedWithFormsDesigner 17

Answer 2

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

मुझे नहीं लगता कि फिक्सिंग से पहले हर बग को पुन: पेश करने का प्रयास करना अनुचित है। हालाँकि यदि आप इसे पुन: पेश करने का प्रयास करते हैं और आप नहीं कर सकते हैं तो यह एक व्यापार निर्णय का अधिक हो जाता है कि क्या अंधा पैच एक अच्छा विचार है या नहीं।

Comments

मैं सहमत हूँ, हालांकि अगर समीक्षा के द्वारा एक बग पाया जाता है, तो वह इसे पुन: पेश करने के लिए आवश्यक महत्वपूर्ण जानकारी प्रदान कर सकता है। आप फिर इसे पुन: पेश कर सकते हैं, और यह साबित कर सकते हैं कि यह सही है ...

— मैट

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

— डैन नीली

@DanNeely: यदि एक थ्रेड किसी सरणी पर मान लिखता है और फिर एक फ़ील्ड में एक संदर्भ संग्रहीत करता है, और एक अन्य थ्रेड उस फ़ील्ड को पढ़ता है और संबंधित सरणी तत्व को एक्सेस करता है, तो कैसे एक बग को पुन: उत्पन्न कर सकता है जो कि JIT को राइट-रेफरेंस ले जाता है लेखन-तत्व एक से पहले ऑपरेशन?

— सुपरकैट

Answer 3

आदर्श रूप से, आप प्रत्येक बग को पुन: उत्पन्न करने में सक्षम होना चाहते हैं ताकि, बहुत कम से कम, आप परीक्षण कर सकें कि यह तय हो गया है।

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

इसलिए, जब आप कर सकते हैं तब डुप्लिकेट करें, लेकिन यदि आप नहीं कर सकते हैं, तो सिस्टम के अपने ज्ञान का दोहन करें, और कोड में अपराधी की पहचान करने का प्रयास करें।

Answer 4

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

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

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

Comments

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

— ट्यूलेंस कोरडोवा

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

— माइकल के

मुझे उम्मीद है कि अधिकांश परीक्षण मौजूदा सुविधाओं के प्रतिगमन परीक्षण होंगे।

— माइकल डुरंट

@ मिचेलक: आपका जवाब खुद के साथ संघर्ष करने के लिए लगता है। यदि आप यह निर्धारित नहीं करते हैं कि बग को पुन: उत्पन्न करने के लिए क्या कदम हैं, तो आप कभी कैसे जानेंगे कि आपके परीक्षण मामले क्या होने चाहिए? आपको हमेशा बग्स को खुद को पुन: पेश करने की आवश्यकता नहीं हो सकती है, लेकिन उन मामलों में से अधिकांश तब होंगे जब प्रजनन के चरण पहले से ही ज्ञात होंगे। यदि आपके पास कोई लॉग फ़ाइल है, जिसमें कोई ज्ञात कदम नहीं है, तो आपके पास QA के साथ कोई परीक्षण मामले नहीं हैं।

— एल्सडिल

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

— गांगेय

Answer 5

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

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

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

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

मुझे लगता है कि आप पा सकते हैं कि आपका दृष्टिकोण प्रस्तावित समाधानों का एक संयोजन होना चाहिए और यह जानना कि कब एक को छोड़ना और अगले को आगे बढ़ाना कुशलता से काम करने के लिए महत्वपूर्ण है।

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

Answer 6

क्या हर दोष का प्रतिकार करने और उसका निदान करने और उसे ठीक करने से पहले डीबग करना उचित है?

मैं कहता हूं हां, कुछ कैविटीज के साथ।

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

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

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

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

Answer 7

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

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

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

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

Answer 8

क्या हर दोष का प्रतिकार करने और उसका निदान करने और उसे ठीक करने से पहले डीबग करना उचित है?

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

आपके प्रश्न और आपके प्रस्ताव के साथ मुझे जो समस्या दिख रही है, वह यह है कि वे इसमें भेद करने में विफल हैं

• दोष रिपोर्ट
• विफलताएं ( त्रुटियां )
• बग (जिसे कभी-कभी त्रुटियां भी कहा जाता है )

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

एक बग रिपोर्ट विफलता का प्रमाण है।

एक विफलता कुछ की एक घटना गलत हो रहा है। एक विशिष्ट खराबी, लेकिन जरूरी नहीं कि इसका कोई कारण हो।

बग के कारण विफलता हो सकती है।

एक बग विफलताओं का एक कारण है; भविष्य में होने वाली असफलताओं को रोकने के लिए कुछ (सिद्धांत रूप में) बदला जा सकता है।

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

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

इसलिए कठिन मामलों के लिए प्रजनन योग्यता पर जोर देते हुए, इसे एक सख्त नीति के रूप में लागू करना नासमझी है।

Comments

यदि बग को पुन: पेश करना उचित नहीं है, तो आपको कैसे पता चलेगा कि आपने बग को ठीक किया है? बग बगैर प्रजनन के तरीका कितना जटिल है।

— B:02овиЈ

आपको पता है कि आपने बग को ठीक कर लिया होगा जब आपको पुन: पेश करना इतना आसान होगा कि आपको इसकी आवश्यकता नहीं है।

— रीइन्टीरियरपोस्ट

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

— gnasher729

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

— रिस्टोरियरपोस्ट

Answer 9

जैसा कि सॉफ्टवेयर विकास में सब कुछ है, सही उत्तर एक समझौता है।

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

व्यवहार में, यह हमेशा संभव नहीं है। शायद बग केवल बड़े उपयोगकर्ताओं पर दर्जनों कोड के साथ आपके कोड तक पहुँचने के साथ होता है। शायद डेटा के विशिष्ट सेट पर डेटा संचालन का एक विशिष्ट संयोजन है जो बग को ट्रिगर करता है और आपको पता नहीं है कि क्या है। शायद आपके ग्राहक बग के प्रकट होने से पहले 100 घंटे के लिए अंतःक्रियात्मक रूप से नॉन-स्टॉप चले।

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

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

Answer 10

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

इसके अलावा, आप उन्हें कैसे साबित करेंगे कि बग को ठीक किया जाता है यदि आप चरणों को दोहरा नहीं सकते हैं?

आपके मामले में समस्या यह है कि उपयोगकर्ता या तो यह नहीं जानता है कि त्रुटि कैसे हुई, यानी किस ऑपरेशन को करने की स्क्रीन में। उनके पास बस लॉग है।

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

मुझे लगता है कि आपको अपने मालिकों को बताना चाहिए कि त्रुटि को दोहराने में सक्षम होने के बिना इसे खोजने के लिए एक uknown समय लगेगा, और यह बिल्कुल भी नहीं है कि आप क्या करेंगे।

समस्या तब होगी जब आपका कोई सहकर्मी बग को शुद्ध भाग्य से बाहर निकालता है और उसे ठीक करता है।

Answer 11

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

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

क्या इसने बग को ठीक किया जो बग रिपोर्ट का कारण बना? आप 100% निश्चित नहीं हो सकते हैं ( इसी बात को लेकर दो कीड़े हो सकते हैं ), लेकिन यह शायद किया।

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

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

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

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

Comments

क्या आप यह मान रहे हैं कि कोड की शुरुआत किससे हुई थी?

— उभयलिंगी

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

— रेमकोगर्लिच

Answer 12

प्रश्न को पढ़ते हुए, मुझे आपकी स्थिति और आपकी टीम के बीच कोई मौलिक विरोध दिखाई नहीं देता है।

• हां, आपको क्लाइंट सेटिंग में होने वाली समस्या को पुन: पेश करने के लिए अपना सर्वश्रेष्ठ प्रयास करना चाहिए। लेकिन सर्वश्रेष्ठ प्रयास का मतलब है कि आपको उसके लिए कुछ समय बॉक्स को परिभाषित करना चाहिए, और वास्तव में समस्या को पुन: उत्पन्न करने के लिए लॉग में पर्याप्त डेटा नहीं हो सकता है।

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

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

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

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

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

Answer 13

मुझे लगता है जैसे आपको अधिक विस्तृत लॉगिंग की आवश्यकता है।

अधिक लॉगिंग जोड़ते समय यह गारंटी नहीं दी जा सकती है कि आपको डिबग करने की आवश्यकता नहीं होगी (या, इस स्थिति में, स्थिति को पुन: उत्पन्न करें), यह आपको वास्तव में गलत होने पर बेहतर जानकारी देगा।

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

Answer 14

क्या हर दोष का प्रतिकार करने और उसका निदान करने और उसे ठीक करने से पहले डीबग करना उचित है?

चूंकि किसी ने भी इसे स्पष्ट शब्दों में नहीं कहा है: बिल्कुल नहीं!

सॉफ्टवेयर डेवलपमेंट में बाकी सभी चीजों की तरह, बगफिक्सिंग का मतलब समय, जोखिम और लागत को ध्यान में रखते हुए है। इनमें से किसी के बीच संतुलन बनाना किसी डेवलपर की नौकरी के विवरण का आधा हिस्सा है।

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

और निश्चित रूप से ऐसे कीड़े हैं जहां अगर आप उन्हें गलत पाते हैं तो एक ग्राहक $ 100'000 + खो देगा। और बग जहां ग्राहक को हर घंटे बग के लिए $ 100'000 + खोना होगा, बग तय नहीं है। आपको बग को देखने और निर्णय लेने की आवश्यकता है। सभी कीड़े एक ही काम नहीं करने के लिए कंबल बयान।

Answer 15

बहुत अच्छा सवाल! मेरी राय है कि यदि आप समस्या को पुन: उत्पन्न नहीं कर सकते हैं, तो आप यह सुनिश्चित करने के लिए 100% नहीं कह सकते कि आपके द्वारा किया गया सुधार नहीं होगा:

a) वास्तव में समस्या को ठीक करता है। बी) एक और बग बनाएँ

ऐसे समय होते हैं जब कोई बग होता है और मैं उसे ठीक कर देता हूं और मैं उसे परखने की जहमत नहीं उठाता। मुझे यकीन है कि यह काम करता है के लिए 100% पता है। लेकिन जब तक हमारा क्यूए विभाग यह कहता है कि यह काम कर रहा है, तब तक मैं इसे एक संभावना मानता हूं कि अभी भी एक बग मौजूद है ... या एक नया बग फिक्स से बनाया गया है।

यदि आप बग को पुन: उत्पन्न नहीं कर सकते हैं और फिर नया संस्करण स्थापित कर सकते हैं और पुष्टि कर सकते हैं कि यह ठीक है तो आप 100% निश्चितता के साथ यह नहीं कह सकते हैं कि बग समाप्त हो गया है।

मैंने कुछ मिनटों के लिए एक सादृश्य के बारे में सोचने की कोशिश की ताकि आप दूसरों को समझा सकें लेकिन वास्तव में कुछ भी समझ में नहीं आया। पुरुष नसबंदी एक मज़ेदार उदाहरण है लेकिन यह एक ही स्थिति नहीं है :-)

Comments

उदाहरण के लिए मान लीजिए कि किसी को एक रिपोर्ट प्राप्त होती है कि एक प्रोग्राम कभी-कभी गलत तरीके से कुछ दशमलव-स्वरूपित संख्याओं को प्रारूपित करता है जब विंडोज़ के एक फ्रांसीसी संस्करण पर स्थापित किया जाता है; संस्कृति-सेटिंग कोड के लिए एक खोज से पता चलता है कि एक ऐसा तरीका है जो वर्तमान थ्रेड संस्कृति को बचाता है और इसे InvariantCultureएक CompareExchangeलूप के भीतर सेट करता है, लेकिन इसे बाद में रीसेट करता है [जैसे कि यदि CompareExchangeपहली बार विफल हो जाता है, तो "सहेजा गया" संस्कृति चर ओवरराइट हो जाएगा] । विफलता की परिस्थितियों को पुन: प्रस्तुत करना कठिन होगा, लेकिन कोड स्पष्ट रूप से गलत है और संकेतित समस्या का कारण बन सकता है।

— सुपरकैट

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

— super पर सुपरकैट

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

— Jaydel Gluckie

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

— सुपरकैट

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

— सुपरकैट

Answer 16

[बग से संबंधित] समवर्ती डेटाबेस का उपयोग, क्लस्टर किए गए कार्यान्वयन, मल्टीथ्रेडेड

क्या हर दोष का प्रतिकार करने और उसका निदान करने और उसे ठीक करने से पहले डीबग करना उचित है?

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

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

Answer 17

दोनों गतिविधियाँ (कोड समीक्षा और परीक्षण) आवश्यक हैं, न ही पर्याप्त हैं।

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

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

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