बगफिक्सिंग कब ओवरकिल हो जाती है, अगर कभी?

Question

कल्पना कीजिए कि आप जावास्क्रिप्ट में एक वीडियो प्लेयर बना रहे हैं। यह वीडियो प्लेयर एक पुनरावर्ती फ़ंक्शन का उपयोग करके उपयोगकर्ता के वीडियो को बार-बार लूप करता है और उसके कारण, ब्राउज़र too much recursion RangeErrorकुछ समय में ट्रिगर हो जाएगा ।

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

• बग को ठीक करें

• बग को छोड़ दें

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

संपादित करें:

यदि पुनरावर्ती दृष्टिकोण एक वास्तविक बग पैदा नहीं करता है तो आपके लिए चिंता का विषय है, मान लीजिए कि हर बार जब खिलाड़ी वीडियो को लूप करता है तो एक चर बढ़ जाता है 1। 2 ⁵³ छोरों के बाद यह चर अतिप्रवाह हो जाएगा और आपका कार्यक्रम अपवाद को फेंकने में सक्षम नहीं होगा।

Comments

मेरे उदाहरण के मामले के परिदृश्य के साथ गड़बड़ न करें

— टिआगो मारिन्हो

@PlasmaHH मैं इस काल्पनिक परिदृश्य का उपयोग अपने प्रश्न को समझाने के लिए कर रहा हूँ। यदि बग मौजूद है या नहीं, तो इससे कोई फर्क नहीं पड़ता है

— टियागो मारिन्हो

@TiagoMarinho: मैं जिस बिंदु को बनाने की कोशिश कर रहा हूं, वह है: कभी-कभी ऐसा करने के लिए उचित व्यवहार के रूप में इस तरह के परिदृश्य को परिभाषित करने के लिए सिर्फ सही चीज।

— प्लाज़्मा एचएच

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

— jamesqf

यह एक व्यावसायिक प्रश्न की तरह लगता है। आपको लागत-से-फिक्स, और बग के प्रभाव / आवृत्ति के आधार पर प्राथमिकता देनी होगी।

— केसी कुबैल

Answer 1

आपको व्यावहारिक होना पड़ेगा।

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

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

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

Comments

पूरी तरह से सहमत हैं "आप आश्चर्यचकित होंगे कि उपयोगकर्ता कितने अच्छे अंत में सीमाओं के खिलाफ जोर दे रहे हैं और दोषों को उजागर कर रहे हैं।"

— चित्तीदार

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

— gnasher729

Youtube पर @ gnasher729 "10-घंटे XXXX" वीडियो एक अच्छा पहचानकर्ता है जो वास्तव में, कुछ लोग हमेशा के लिए लूप करना चाहते हैं।

— क्रिस क्रेफ़िस

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

— gnasher729

आखिरी पैराग्राफ पर जोर। क्या आप जानते हैं कि यदि 32,768 लगातार "माउस प्रेस" इवेंट बिना किसी "माउस रिलीज़" इवेंट के बिना हो जाए तो मैकओएस क्लासिक क्रैश हो जाएगा?

— मार्क

Answer 2

विंडोज 95 में एक समान बग था जिसके कारण कंप्यूटर 49.7 दिनों के बाद दुर्घटनाग्रस्त हो गया । यह केवल रिलीज के कुछ वर्षों बाद देखा गया था, क्योंकि बहुत कम Win95 सिस्टम वैसे भी लंबे समय तक बने रहे। तो एक बिंदु है: कीड़े अन्य, अधिक महत्वपूर्ण बगों द्वारा अप्रासंगिक हो सकते हैं।

आपको जो करना है वह कार्यक्रम के लिए एक जोखिम मूल्यांकन है और व्यक्तिगत बग के लिए प्रभाव आकलन है ।

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

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

Comments

मुझे कुछ इंटेल सीपीयू में हार्डवेयर (हार्डवेयर) बग भी याद है जहां एक विशिष्ट फ्लोटिंग पॉइंट वैल्यू सभी गलत हो गई थी।

@WilliamKappler en.wikipedia.org/wiki/Pentium_FDIV_bug मेरा मानना ​​है कि आप इसका उल्लेख कर रहे हैं। इससे पहले कि कोई भी इस पर ध्यान दिया गया एक साल के लिए था।

— Jeutnarg

@ gnasher729 - वास्तव में नहीं, वे पहले से ही निचले पायदान पर थे और अभी भी खुदाई कर रहे हैं :) ज्यादातर लोगों को 49.7 दिनों के आईआईआरसी की तुलना में विन 95 को अधिक बार फिर से स्थापित करना पड़ा।

— mcottle

@Luaan टिप्पणी का उद्देश्य M $ पर एक घटिया खुदाई के रूप में था, इसलिए पहले वाक्य के बाद स्माइली। वे '95 के साथ अठारहवें से पीछे थे क्योंकि यह 95 में बहुत देर से आया (शायद इसलिए कि 1996 में Win95 जारी किया गया था) एक बुरी नज़र होगी, आधा पका हुआ (यूएसबी बीएसओडी याद रखें?) और अस्थिर बनने की इच्छा रखते हुए और नियमित रूप से आवेगों की आवश्यकता होती है? इसलिए मेरा दूसरा वाक्य - जिसने कभी विंडोज 95 पर सर्वर चलाने का उल्लेख नहीं किया, मुझे नहीं पता कि आपको कहां से (फ्लैशबैक) मिला है। दूसरी रिलीज़ सीडी ने मामलों में सुधार किया लेकिन '95 की शुरुआती रिलीज़ एक ख़ुशी थी।

— एमसील्ट

टीबीएच मुझे लगता है कि यह "विंडोज फॉर वॉरशिप" फियास्को था जिसने अधिक प्रतिष्ठित क्षति ( संग्रह.wired.com/science/discoveries/news/1998/07/13987 ) की और वह NT का उपयोग कर रहा था। उस समय की यूनिक्स मशीनें लिनक्स के बहुत (शुरुआती) संस्करणों का उपयोग करते हुए, बहु-वर्ष के उतार-चढ़ाव का प्रबंधन कर सकती थीं। सभी घरेलू कंप्यूटर उच्च अपटाइम के लिए भी सक्षम थे, हालांकि शायद ही कभी इस तरह से उपयोग किया जाता था। मैंने देखा कि जब वे अप्रचलित थे, तब बीबीसी के माइक्रोकोस शैक्षिक प्रदर्शनों में एम्बेडेड थे।

— pjc50

Answer 3

अन्य उत्तर पहले से ही बहुत अच्छे हैं, और मुझे पता है कि आपका उदाहरण सिर्फ एक उदाहरण है, लेकिन मैं इस प्रक्रिया का एक बड़ा हिस्सा बताना चाहता हूं जिस पर अभी तक चर्चा नहीं की गई है:

आपको अपनी मान्यताओं की पहचान करने की आवश्यकता है, और फिर कोने के मामलों के खिलाफ उन मान्यताओं का परीक्षण करें।

आपके उदाहरण को देखते हुए, मैं कुछ धारणाएँ देखता हूँ:

• पुनरावर्ती दृष्टिकोण अंततः एक त्रुटि का कारण होगा।
• किसी को भी यह त्रुटि दिखाई नहीं देगी क्योंकि ढेर सीमा तक पहुंचने के लिए वीडियो को चलाने में बहुत लंबा समय लगता है।

अन्य लोगों ने पहली धारणा पर चर्चा की है, लेकिन दूसरी धारणा को देखें: क्या होगा यदि मेरा वीडियो केवल एक दूसरे लंबे समय का एक अंश है?

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

अज्ञात धारणाएं बग का एक बड़ा स्रोत हैं।

जैसा कि मैंने कहा, मुझे पता है कि आपका उदाहरण सिर्फ एक उदाहरण है, लेकिन आपकी मान्यताओं (जो अक्सर लगता है की तुलना में कठिन है) की पहचान करने की यह प्रक्रिया है और फिर उन मान्यताओं को अपवाद के रूप में सोचना यह तय करने में बहुत बड़ा कारक है कि आपका समय कहाँ बिताना है।

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

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

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

लेकिन उस प्रक्रिया का एक बड़ा हिस्सा पहले आपकी मान्यताओं की पहचान कर रहा है और फिर उन मान्यताओं को अपवादों को पहचानने की कोशिश कर रहा है।

Comments

बहुत अच्छी बात केविन। ऊपर दिए गए चयनित उत्तर पर मेरी टिप्पणी पर ध्यान दें जो विश्लेषण प्रश्न पर केंद्रित हैWhat's the worst thing that could happen?

— OMY

यहां एक और धारणा यह है कि एक बढ़ती-बढ़ती स्टैक केवल समस्याओं को जन्म देगी जब यह एक अतिप्रवाह आकार तक पहुंच जाएगा। वास्तव में, स्टैक एक सामान्य संसाधन हो सकता है यह बग लगातार लीक हो रहा है। प्रत्येक पुनरावृत्ति ^ H ^ H ^ H ^ H ^ Hrecursion पर छोटे से बिट्स द्वारा पूरा ब्राउज़र धीमा और धीमा हो सकता है।

— एल्फ

1. ओपी ने कभी नहीं कहा कि समस्या एक बढ़ते हुए स्टैक के कारण हुई। यह आसानी से एक काउंटर रूटीन में त्रुटि (dec -> div / 0?) के कारण हो सकता है। 2. यदि समस्या है एक ढेर अतिप्रवाह समस्या तो इस सवाल StackOverflow में पोस्ट किया जा नहीं करना चाहिए? <rimshot!> ;-D

— OMY

@OMY वह टिप्पणी किसकी ओर निर्देशित है?

— केविन वर्कमैन

Answer 4

मेरा सुझाव है कि आप निम्नलिखित पेपर पढ़ें:

निर्भरता और इसके खतरे: एक वर्गीकरण

अन्य बातों के अलावा, यह विभिन्न प्रकार के दोषों का वर्णन करता है जो आपके कार्यक्रम में हो सकते हैं। आपने जो वर्णन किया है उसे निष्क्रिय दोष कहा जाता है , और इस पत्र में इसे इस तरह वर्णित किया गया है:

एक त्रुटि सक्रिय है जब यह एक त्रुटि पैदा करता है, अन्यथा यह निष्क्रिय है। एक सक्रिय दोष या तो एक) एक आंतरिक दोष है जो पहले निष्क्रिय था और जो कि संगणना प्रक्रिया या पर्यावरणीय परिस्थितियों, या b) एक बाहरी गलती द्वारा सक्रिय किया गया है। गलती सक्रियण एक घटक के लिए एक इनपुट (सक्रियण पैटर्न) का अनुप्रयोग है जो निष्क्रिय गलती को सक्रिय होने का कारण बनता है। अधिकांश आंतरिक दोष उनके निष्क्रिय और सक्रिय अवस्थाओं के बीच होते हैं

इसका वर्णन करने के बाद, यह लागत-लाभ के अनुपात में उबल जाता है। लागत में तीन पैरामीटर शामिल होंगे:

• कितनी बार मुद्दा खुद ही पेश होगा?
• इसके परिणाम क्या होंगे?
• यह आपको व्यक्तिगत रूप से कितना परेशान करता है?

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

यह व्यक्तिगत नहीं है। यह व्यवसाय है।

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

Comments

'यह व्यक्तिगत नहीं है। यह व्यवसाय है 'माइकल द्वारा मुझे लगता है, वीटो नहीं। (आप आश्चर्यचकित होंगे कि उपयोगकर्ता कितने अच्छे अंत में सीमाओं के खिलाफ धक्का और दोषों को उजागर कर रहे हैं)

— 384X21

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

— व्लादिमीर स्टोक

Answer 5

यह बग केवल तब तक अनदेखा रहता है जब तक कि कोई व्यक्ति लॉबी स्क्रीन पर अपने खिलाड़ी को कंपनी प्रस्तुति देने के लिए 24/7 नहीं रखता। तो यह अभी भी एक बग है।

आप क्या करते हैं इसका जवाब ? वास्तव में एक व्यावसायिक निर्णय है, एक इंजीनियरिंग नहीं:

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

Answer 6

जाहिर है बड़ी कंपनियों (या बड़ी परियोजनाओं) में एक बहुत व्यावहारिक तरीका है कि क्या करना है।

यदि फिक्सिंग की लागत उस रिटर्न से अधिक है जो फिक्स लाएगा तो बग को रखें। वाइसवेरा यदि फिक्स अपनी लागत से अधिक वापस आ जाएगी तो बग को ठीक करें।

आपके नमूना परिदृश्य में यह इस बात पर निर्भर करता है कि आप कितने उपयोगकर्ताओं से हारने की अपेक्षा करते हैं, यदि आप इस महंगे बग को सुधारने के बजाय नई सुविधाएँ विकसित करते हैं तो आप कितना उपयोगकर्ता प्राप्त करेंगे।

Comments

बग को ठीक करने के लिए ROI का मूल्यांकन करना आसान है - आपको आमतौर पर अपने फैसले पर निर्भर रहना पड़ता है।

— एंट पी

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

— जेरी जेरेमिया

@JerryJeremiah अगर बग व्यवसाय प्रक्रिया को चलने से रोकता है तो यह प्रतिष्ठा के बारे में नहीं है, यह व्यवसाय प्रक्रिया के महत्व पर निर्भर करता है। और हर मामले और हर नीति में आप सही बग पर लागू होते हैं या नहीं, आपको अपने अनुभव और ज्ञान के आधार पर व्यक्तिपरक मूल्यांकन करना पड़ता है। यहां तक ​​कि अगर आप उस उपयोगकर्ता की सही संख्या जान सकते हैं जो बग का सामना करेंगे, तो आपको अभी भी एक मानव विकल्प बनाना होगा (ROI नीति में बग हिट आँकड़े भी शामिल हो सकते हैं जो लागतों को बढ़ा सकते हैं)। आज के रूप में एक प्राथमिक तरीका जानने के लिए कोई यांत्रिक तरीका नहीं है।

— जूलिनरॉज

Answer 7

tl; डॉ। यही कारण RESOLVED/WONTFIXहै कि एक बात है। बस इसे अति प्रयोग न करें - यदि आप सावधान नहीं हैं तो तकनीकी ऋण ढेर हो सकता है। क्या यह आपके डिजाइन के साथ एक मूलभूत समस्या है, भविष्य में अन्य समस्याओं के कारण होने की संभावना है? फिर इसे ठीक करें। अन्यथा? इसे तब तक छोड़ दें जब तक कि यह प्राथमिकता नहीं बन जाती (यदि यह कभी भी हो)।

Answer 8

आपके द्वारा वर्णित स्थिति में वास्तव में तीन त्रुटियां हैं:

1. सभी लॉग की गई त्रुटियों का मूल्यांकन करने के लिए एक प्रक्रिया की कमी (आपने अपने टिकट / बैकलॉग / जो भी सिस्टम आपके पास है, उस त्रुटि को लॉग इन किया है?) यह निर्धारित करने के लिए कि क्या इसे ठीक किया जाना चाहिए या नहीं। यह एक प्रबंधन निर्णय है।

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

3. समस्या जो वीडियो बहुत लंबे समय के बाद प्रदर्शित करना बंद कर सकती है।

केवल तीन त्रुटियों में से (3) को ठीक करने की आवश्यकता नहीं है।

Comments

2-क्रम की समस्याओं को इंगित करने के लिए धन्यवाद। बहुत से लोग केवल लक्षण का इलाज करते हैं, और कारण अधिक लक्षण पैदा करने पर सही रहता है।

— जैक्सटर

Answer 9

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

Answer 10

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

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

Answer 11

यहां तीन चीजें हैं:

सिद्धांतों

यह सिक्के का एक पक्ष है। कुछ हद तक, मुझे लगता है कि बग को ठीक करने पर जोर देना अच्छा है (या बुरा कार्यान्वयन, भले ही वे "काम" करें), भले ही कोई भी इसे देख रहा हो।

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

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

• प्रोग्रामर ने नोटिस किया, लेकिन इसे "समस्या नहीं" माना। यदि इसे खड़ा करने के लिए छोड़ दिया जाता है, तो laissez-faire की संस्कृति विकसित होती है, जो अंततः, कीड़े को जन्म देती है जहां यह दर्द होता है। इस विशेष मामले में, कौन परवाह करता है। लेकिन क्या होगा अगर वह प्रोग्रामर अगली बार बैंकिंग एप्लिकेशन विकसित कर रहा है, और यह तय करता है कि एक निश्चित नक्षत्र कभी नहीं होगा। फिर करता है। बुरा समय।

व्यवहारवाद

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

तेजी से असफल, कठिन असफल

यदि संदेह है, तो तेजी से असफल और कठिन असफल।

इसका मतलब है, दूसरों के बीच, कि आपका कोड त्रुटि स्थिति को नोटिस करता है, पर्यावरण को नहीं।

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

इस तरह, आपके पास है

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

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

Comments

मुझे खेद है कि अगर आप इस तरह महसूस करते हैं कि मैंने कितनी जल्दी एक उत्तर स्वीकार कर लिया है। मेरे बचाव में मुझे नहीं पता था कि सवाल> 10,000 विचारों और स्वीकृति के समय कई जवाब होंगे। वैसे भी मैंने अभी भी सबसे अच्छे उत्तर पर अपना विचार नहीं बदला है।

— टियागो मारिन्हो

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

— एनओई

मैं पूरी तरह से अजीब downvoting के बारे में सहमत

— टैगो मारीन्हो

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

— जैक्सटर

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

— AoE

Answer 12

मेरे कार्यस्थल पर एक वरिष्ठ डेवलपर के डेस्क पर यह पोस्ट करता है

क्या यह किसी की मदद करता है?

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

Answer 13

तीन बातें दिमाग में आती हैं:

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

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

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

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

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

Comments

कृपया नीचे टिप्पणी करते समय टिप्पणी छोड़ें। हमें यह जानना चाहिए कि उत्तर को बेहतर बनाने के लिए आलोचक क्या है।

— एल्फ

Answer 14

कम संभावना / हल्के परिणाम = कम पुजारी तय

• यदि ऑक्यूरेंस की संभावना बहुत कम है
• यदि ऑक्यूरेंस के परिणाम हल्के होते हैं
• फिर बग कोई खतरा पैदा नहीं करता है, तो प्राथमिकता तय नहीं है।

लेकिन यह आलसी डेवलपर्स के लिए एक बैसाखी नहीं बन सकता ...

• क्या "बहुत कम समुद्र" भी मतलब है?
• क्या "हल्के परिणाम" भी मतलब है?

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

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

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

वास्तविक दुनिया डेटा के साथ अपने अंतर्ज्ञान का सामना करें

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

एक हल्के समस्या और नियंत्रण का एक उपाय

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

निष्कर्ष

हां, ऐसे कीड़े हैं जिन्हें तुरंत ठीक करने की आवश्यकता नहीं है, जो कि नए फीचर के विकास में देरी करने के लिए पर्याप्त महत्वपूर्ण नहीं हैं। हालाँकि यह सुनिश्चित करने के लिए सिस्टम का नियंत्रण होना चाहिए कि यह बग छोटा है क्योंकि हम अपने स्वयं के अंतर्ज्ञान पर भरोसा नहीं कर सकते।

Answer 15

मुझे लगता है कि यह शुरू से गलत सवाल पूछ रहा है।

सवाल यह नहीं है कि "मुझे इस बग को ठीक करना चाहिए या मुझे इस बग को ठीक नहीं करना चाहिए"। किसी भी डेवलपर के पास सीमित समय होता है। तो सवाल यह है कि "सबसे उपयोगी चीज क्या है जो मैं एक घंटे, या चार घंटे, या एक हफ्ते में कर सकता हूं"।

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

Comments

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

— 14

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

— gnasher729

Answer 16

बग फिक्सिंग हमेशा एक ओवरकिल है

आइए पहले बग के भाग को वर्गीकृत करें ।

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

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

इसलिए, कृपया इसे ठीक करने का प्रयास न करें ।

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

स्पष्टता स्पष्ट है, अब आपको टूटे हुए कोड और नई लूप सीमा दोनों का समर्थन करना होगा।

पीएस चरम दृश्य के लिए माफी माँगता है।

पीपीएस शब्दावली पर एक नोट: आप बग को "ठीक" नहीं कर सकते। खैर एक पशुचिकित्सा शायद, लेकिन चलो वहाँ नहीं जाना ;-)। समस्याओं को हल या "निश्चित" किया जाता है, जबकि बग को हटा दिया जाता है या चारों ओर काम किया जाता है।

Comments

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

— डोपेलग्रेनेर 10

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

— दिमा टिस्नेक

मुझे नहीं पता कि आप किस प्रकार की बग फिक्सिंग की बात कर रहे हैं, लेकिन मेरे दिन-प्रतिदिन की दुनिया में, "आर्किटेक्चर को बदलना" बग फिक्सिंग की एक विधि है। आप परिभाषित करना चाहते हैं कि आप "बग फिक्सिंग" शब्द के तहत क्या एकत्र कर रहे हैं।

— doppelgreener

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

— 15

@ आप स्पष्टीकरण के लिए धन्यवाद। मुझे लगता है कि जब से "ठीक" की एक ऐसी परिभाषा प्रश्न द्वारा इस्तेमाल नहीं किया जा रहा है, इस सवाल का जवाब शब्द है जो की भावना को जवाब देना चाहिए है इस्तेमाल किया जा रहा।

— doppelgreener