डिबगर के उपयोग से बचने का क्या लाभ है?

Question

अपने करियर के दौरान, मैंने देखा है कि कुछ डेवलपर्स डिबगिंग टूल का उपयोग नहीं करते हैं, लेकिन समस्या क्या है, यह पता लगाने के लिए गलत कोड पर स्पॉट चेकिंग करते हैं।

जबकि कई बार डिबगर के बिना कोड में त्रुटियों को जल्दी से खोजने में सक्षम होने के लिए एक अच्छा कौशल है, ऐसा लगता है कि यह बहुत कम समय बिताने के लिए मुद्दों की तलाश में खर्च करता है जब एक डीबगर आसानी से टाइपोस जैसी छोटी गलतियों को ढूंढेगा।

क्या डिबगर के बिना किसी कॉम्प्लेक्स का प्रबंधन संभव है? क्या यह उचित है? " मानसिक डिबगिंग " का उपयोग करने से क्या लाभ हैं ?

Comments

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

उदाहरण: एक कोड पर विचार करें a = 6/3। टाइपो के बजाय, आपने टाइप किया है a = 6/2.. अब आप mnemonics स्तर में खोज कर रहे हैं।, ADD, JMP निर्देश और फिर आप पाते हैं कि 2 के बजाय एक अतिरिक्त पुनरावृत्ति थी, तो आपको पता चलता है कि विभक्त के पास क्या है। गलत टाइपो। अब आप अनुमान लगा सकते हैं कि हमेशा डिबगर का उपयोग करना कितना हास्यास्पद है।

— EAGER_STUDENT

Answer 1

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

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

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

बेशक इस पद्धति की अपनी सीमाएं हैं, ज्यादातर कोड के माध्यम से कई रास्तों को देखने के लिए किसी के दिमाग की सीमाओं के कारण। मैंने अपने मन की इन सीमाओं का सम्मान करना सीख लिया, और अधिक उन्नत एल्गोरिदम में बग को ठीक करने के लिए डिबगर की ओर रुख किया।

Comments

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

— बिल

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

— dasblinkenlight

+1 हालांकि मुझे कुछ प्रकार के बग (विशेष रूप से अधिक जटिल एल्गोरिदम में) के लिए एक डीबगर अमूल्य लगता है, वास्तव में कोड की अच्छी समझ रखने के लिए कोई विकल्प नहीं है

— क्रिस ब्राउन

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

— dasblinkenlight

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

— स्पेंसर Rathbun

Answer 2

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

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

Answer 3

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

मैं डिबगिंग से सलाह का पालन करता हूं : यहां तक ​​कि सबसे मायावी सॉफ्टवेयर और हार्डवेयर समस्याएं (डेविड एगन्स) खोजने के लिए 9 अपरिहार्य नियम , और यह "सोच और देखो" के मार्गदर्शन में एक वर्ग में आता है।

Comments

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

@Mark प्लस समस्या के गलत निदान और नए दोष में प्लगिंग का अतिरिक्त बोनस है।

— कीथ

@ मर्क बैनिस्टर - मैं देख रहा हूं कि आप क्या कह रहे हैं। मुझे इसमें संशोधन करना चाहिए, यदि आप 15 मिनट से अधिक समय से कोड में समस्या की तलाश कर रहे हैं, तो डिबगर का उपयोग करें और जिद्दी न बनें।

— JohnFx

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

— आने वाली

@ चिह्न जब तक आप एक बहुत छोटे कोड आधार पर काम कर रहे हैं मुझे लगता है कि कोड की हर पंक्ति को समझना असंभव है। मेरे वर्तमान बग का 95% आपके द्वारा वर्णित तरीके से हल हो गया है, लेकिन ट्रिकियर वे हैं जहां आपको डीबगर की आवश्यकता है।

— wobbily_col

Answer 4

किसी भी नौकरी के लिए सही उपकरणों का सही तरीके से उपयोग करना आवश्यक है। यदि आपके पास कोई डीबगर है, तो इसका उपयोग यह देखने के लिए करें कि वास्तव में क्या हो रहा है। अधिकांश कीड़े मान्यताओं के कारण होते हैं।

मैंने ऐसे डेवलपर्स के साथ काम किया है जो डिबगर का उपयोग करने से इनकार करते हैं क्योंकि वे बेहतर जानते थे। क्लासिक प्रतिक्रिया मुझे एक बार मिली थी 'दुर्घटना मेरे कारण नहीं हो रही है, मैंने सारा दिन कोड [जहां यह दुर्घटनाग्रस्त था] का निरीक्षण करने में बिताया है और कुछ भी गलत नहीं है'। (उस शून्य मान के बारे में क्या है जो db से पढ़ा गया था?) बॉस को लगता है कि यह एक शानदार उत्तर था लेकिन ग्राहक ने ऐसा नहीं किया।

मैं उस टीम से उतनी ही तेजी से बाहर निकला जितना मैं कर सकता था। उनका उद्देश्य नौकरी को पंख देना था और दिनभर की व्यस्त समस्या में 10 मिनट की सरल समस्या को हल करना था।

Comments

+1 "अधिकांश कीड़े मान्यताओं के कारण होते हैं" बहुत समझदार शब्द हैं

— ZJR

मुझे लगता है कि सभी कीड़े मान्यताओं के कारण होते हैं। (देखें कि मैंने वहाँ क्या किया? = P)

— dan_waterworth

@ जेडजेआर: यही कारण assertहै कि बहुत अच्छा है। अपनी मान्यताओं की जाँच करें। उन्हें अक्सर जांचें।

— ज़ेन लिंक्स

@dan_waterworth: सच नहीं है। एक के लिए, यह एक टाइपो हो सकता है।

— थॉमस ईडिंग

Answer 5

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

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

Comments

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

— क्रिसफैचर

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

— माइक डनलवेई

@MikeDunlavey क्या वह व्यक्ति डिबगर का उपयोग करना जानता है और उसका उपयोग नहीं करना चुनता है? ठीक। अगर वे नहीं जानते हैं, तो मैं अपने बयान के साथ खड़ा हूं।

— डीजेकेवर्थ

आप जैसे चाहें खड़े हों, एक समय आसानी से आ सकता है जब आप पर विशेषण लगाया जा सकता है। तब आप समझेंगे - यह स्कूल का सामान है।

— माइक डनलवेई

Answer 6

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

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

कहा जा रहा है, मैंने उन उपकरणों और वातावरण के साथ काम किया है जहाँ डिबगर को सही तरीके से काम करना मुश्किल था, या इतना कम और बेकार कि अनुमान लगाना दुर्भाग्य से अक्सर बेहतर दृष्टिकोण था। मैंने कुछ मालिकाना उपकरणों के साथ काम किया है जिनमें उचित डिबगर भी नहीं थे। मुझे लगता है कि यह संभव है कि यदि कोई व्यक्ति ऐसे वातावरण में काम करता है, तो वे अंततः डिबगर्स में अपना विश्वास खो देते हैं और अनुमान लगाने के दृष्टिकोण पर भरोसा करते हैं।

Answer 7

मुझे आश्चर्य है कि इस विषय पर चर्चा ने "इकाई परीक्षण" का उल्लेख नहीं किया है।

क्योंकि मैं परीक्षण-संचालित विकास करता हूं, इसलिए मैं डिबगर में बहुत समय नहीं बिताता। 10 साल पहले, मैं डीबगर के माध्यम से कर्तव्यपूर्वक कदम रखता था:

1. यह सुनिश्चित करने के लिए कि यह काम किया और कोड का एक टुकड़ा लिखने के बाद
2. जब मुझे समस्या का निदान करने की कोशिश करने के लिए एक बग रिपोर्ट मिली

परीक्षण-संचालित विकास के 10 वर्षों के बाद मैंने जो पाया है वह यह है कि मैं एक प्रोग्रामर के रूप में बहुत अधिक उत्पादक हूं यदि:

1. मैं यह सुनिश्चित करने के लिए कोड लिखने से पहले यूनिट परीक्षण लिखता हूं कि मैंने इसे सही तरीके से लिखा है
2. मैं समस्या पर डुप्लिकेट और ड्रिल-डाउन करने का प्रयास करने के लिए बग रिपोर्ट प्राप्त करने पर तुरंत यूनिट परीक्षण लिखता हूं।

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

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

Comments

+1 यह अक्सर प्रिंट स्टेटमेंट जोड़ने और परीक्षण को फिर से चलाने के लिए डीबगर का उपयोग करने के लिए तेज़ होता है।

— विंस्टन एवर्ट

@ winston - अक्सर डिबगर को आग लगाने के बजाय कई प्रिंट स्टेटमेंट लिखने के लिए जब तक आप समस्याग्रस्त कोड का स्थान नहीं खोज लेते। यह सब निर्भर करता है। सरल समस्याओं को आमतौर पर आपके द्वारा वर्णित तरीके से अधिक तेज़ी से हल किया जाता है, लेकिन जटिल समस्याएं हैं जहां आपको डीबगर की आवश्यकता होती है। किसी भी निरपेक्ष सिद्धांत का सख्ती से पालन करने से बेहतर है दोनों का उपयोग करना।

— wobbily_col

Answer 8

व्यक्तिगत रूप से, मैं डिबगर के उपयोग को कम करने की कोशिश करता हूं:

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

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

Answer 9

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

Answer 10

डिबगिंग रन समय में आपके कोड में ऑब्जेक्ट्स और वेरिएबल्स की स्थिति का निरीक्षण करने के लिए एक बहुत ही उपयोगी उपकरण है।

जैसा कि पहले ऊपर दिए गए जवाबों में बताया गया है, डिबगिंग बेहद मददगार है, लेकिन कुछ मामले ऐसे हैं जहां यह सीमित है।

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

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

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

साथ ही समवर्ती कोड की अप्रत्याशितता डेवलपर को समवर्ती कोड डीबग करने में और विचलित कर सकती है।

अंत में, मेरी ईमानदार राय में:

• जब डीबगिंग का उपयोग किया जाता है तो "डिबगिंग थिंक पैटर्न" का फोकस खोने की प्रवृत्ति बढ़ जाती है।

तथा

• किसी भी तरह से = डिबगिंग उत्पादकता में वृद्धि हुई है b / c आपका ध्यान अप्रत्याशित ब्रेकप्वाइंट (रेस की स्थिति के कारण अप्रत्याशित) से बाधित नहीं है।

Comments

+1 समवर्ती वातावरण में डिबगिंग के मुद्दे को लाने के लिए, जहां पारंपरिक डीबगर्स की उपयोगिता अक्सर शून्य के पास कम हो जाती है।

— dasblinkenlight

Answer 11

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

यहां तक ​​कि जब मुझे लगता है कि मैंने इसे पकड़ लिया है, तो मैं आमतौर पर यह सुनिश्चित करने के लिए डिबग करता हूं कि मैं सही हूं। जब समस्या थोड़ी अधिक जटिल होती है, मेरा मानना ​​है कि डिबगिंग बिल्कुल आवश्यक है।

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

Answer 12

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

परीक्षण और त्रुटि से प्रोग्रामिंग कुछ महान नए दृष्टिकोणों के साथ आ सकती है, और उन चीजों को पकड़ सकते हैं जो दूसरों को याद आती हैं।

नकारात्मक पक्ष, आमतौर पर ज्यादा समय लेता है।

Answer 13

एर्म, यह व्यक्ति पर निर्भर करता है। व्यक्तिगत रूप से, मैं ऐसे डिबगर्स का उपयोग नहीं करता हूं जो खुद बहुत ज्यादा हैं। जब मैं माइक्रो कंट्रोलर प्रोग्राम करता हूं, तो मैं मूल रूप से एलईड या राइटिंग डेटा का उपयोग करता है, जो उस पर कोड को "डीबग" करने के लिए ईईपीआरओएमएस पर लिखते हैं। मैं JTAG का उपयोग नहीं करता।

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

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

Answer 14

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

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

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

Answer 15

कई जवाब, लेकिन हेइज़ेनबग के बारे में उल्लेख नहीं है ?!?!?

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

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

Answer 16

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

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

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

Answer 17

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

पिछली बार जब मैंने एक डिबग का उपयोग किया था, जब मुझे कुछ विरासत आवेदन में एक कोर फ़ाइल मिली थी।

क्या मैं एक "डिबग्यूअर मिनियन" हूं या ये लोग "बहुत कट्टर" हैं?

न तो। वे केवल ऐसे लोग हैं जो अपने जीवन को कठिन बनाना पसंद करते हैं तो यह होना चाहिए।

Answer 18

डिबगिंग केवल एक उपकरण है जिसे एक अच्छे डेवलपर को कुशल रूप से उपयोग करना चाहिए।

निश्चित रूप से कभी-कभी आप दिल से जान सकते हैं कि बग कहाँ हो सकता है यदि आप कोड आधार जानते हैं। लेकिन आप कोड को देखकर सिर्फ एक pesky बग को खोजने के लिए एक पूरा दिन या सप्ताह भी खो सकते हैं।

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

तो आपके सवाल का जवाब देने के लिए - शायद वे शानदार प्रोग्रामर हैं, लेकिन उनके समस्या निवारण कौशल और शिकार कीड़े खराब होने पर उनकी दक्षता।

Answer 19

एक समस्या के दायरे पर निर्भर करता है। यदि कार्यक्रम छोटा है और चीजें अच्छी तरह से विभाजित हैं, तो आप शायद इसे देखकर पता लगा सकते हैं। यदि कार्यक्रम कई वर्षों में 100+ लोगों की टीम द्वारा विकसित की गई 4.5 मिलियन लाइनों का कोड है, तो कुछ कीड़े स्पॉट करना असंभव होगा।

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

बिंदु जा रहा है: छोटे कार्यक्रमों या ऐसी चीजों में जो अत्यधिक रूपांतरित हैं, आप w / o डिबगर से दूर हो सकते हैं। यदि कार्यक्रम वास्तव में बड़ा और जटिल है तो डिबगर आपको बहुत समय बचा सकता है। जैसा कि दूसरों ने कहा है, यह एक उपकरण है, और इसकी अपनी स्थितियां हैं जहां यह किसी भी अन्य विधि से ऊपर है, और अन्य जहां यह सबसे अच्छा विकल्प नहीं है।

Answer 20

यदि बग क्लाइंट के कंप्यूटर में, या कंप्यूटर में होता है कि इसका एनकाउंटर आपके से बहुत अलग है, तो डिबगर / रिमोट डीबगर सेट करना बोझिल है। तो, ठंड के दिन के लिए जहां आपको मैदान से एक बग मिलता है, 'लेकिन ... मैं एक डीबगर नहीं है' की प्रतिक्रिया से मदद नहीं मिलती है। इसलिए, आपको कोड और लॉग फ़ाइलों की समझ के माध्यम से बग को शूट करने और खोजने में परेशानी का एक कौशल सेट विकसित करने की आवश्यकता है।

Answer 21

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

इसके अलावा, इस बात पर विचार करें कि डिबगिंग कोड के साथ काम करने वाला हर कोई उस कोड से परिचित नहीं है। कई बार ठेकेदार ऐसे माहौल में आ जाते हैं, जहां उनके पास केवल एक सामान्य आदर्श होता है कि क्या हो रहा है। यहां तक ​​कि उन्हें पर्यावरण के बारे में भी विस्तृत विवरण दिया जा सकता है - या 20 साल पुराने स्कीमा मैप और गाईड नामकरण सम्मेलनों के लिए गाइड (एफ 1, एफ 2, और एफ 3 के साथ टेबल एक्स 1234 और टेबल एक्स 4312 के बीच के अंतर को समझने की कोशिश करें] हां, इस तरह कचरा मौजूद है] जब आप नए हैं), लेकिन कई बार यह वर्णन गलत है; अन्यथा, "रहस्य" त्रुटि क्यों है।

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

Comments

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

— डेब्यूगर्स की