डिबगिंग पर कम समय कैसे बिताएं? [बन्द है]

Question

पेरेटो नियम के बाद, एक प्रोग्रामर अपने समय का केवल 20% वास्तव में उपयोगी चीजों के लिए खर्च करता है।

मैं अपना 80% समय डिबगिंग में बिताता हूं, सब कुछ काम करने के लिए छोटी चीजें तय करता हूं।

क्या डिबगिंग में कम समय बिताने का एक तरीका है?

Comments

मुझे यकीन नहीं है कि मैं पारेटो सिद्धांत की व्याख्या कैसे करूंगा।

— c_maker

<meme> TDD पर एक नज़र डालें। </ meme>

— StuperUser

आप वास्तव में क्या करना करना जब डिबगिंग?

आपको अपने ध्यान पर अधिक समय बिताने की जरूरत है

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

— जॉय एडम्स

Answer 1

कोड में Agda या Coq । एक बार जब आपका कोड संकलित हो जाएगा, तो यह काम करेगा। यदि यह बहुत कट्टर है, तो कमजोर प्रकार की प्रणाली वाली भाषा चुनें, जैसे, हास्केल या एफ #।

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

Comments

JUst कुछ चलता है इसका मतलब यह नहीं है कि यह बग नहीं है। कीड़े अक्सर गलत काम करने वाले कोड का परिणाम होते हैं।

— HLGEM

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

— एसके-लॉजिक

@HLGEM, तो आपकी "डिबगिंग" की धारणा काफी रचनात्मक और मुख्यधारा से दूर है। और वैसे भी, इस दृष्टिकोण के साथ कोडिंग और "डिबगिंग" के बीच का अनुपात 20/80 से दूर होगा। तो कृपया, अपने मन को समझाने की कोशिश करें।

— एसके-तर्क

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

— एसके-लॉजिक

@ uhbif19 नथ का यह कहने पर हास्य होना था कि तुम्हें पता है कि वह वास्तव में क्या मतलब था?

— फिल

Answer 2

इकाई का परीक्षण।

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

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

Comments

मैं यूनिट-टेस्ट का उपयोग करता हूं और आपके साथ पूरी तरह से सहमत हूं। लेकिन, मैं हर चीज का परीक्षण नहीं कर सकता।

— uhbif19

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

— फ्रेड्रिक

@ फ़्रेड्रिक, आप ठीक a + bसे कोड के टुकड़े को भी इकाई परीक्षण नहीं कर सकते (जब तक कि आपका परीक्षण आपके अंकगणित डेटा प्रकार की पूरी श्रृंखला को कवर नहीं करता है)।

— एसके-लॉजिक

"एक डिबगिंग सत्र के बाद मैंने सिर्फ कोड तय किया।" -- वास्तव में? मुझे लगता है कि एक डिबगिंग सत्र के बाद मैंने सिर्फ अधिक बग पेश किए - मुझे नहीं पता कि वे कहां हैं।

— बी सात

Answer 3

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

Comments

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

— माइकल

मैं TDD (जहाँ संभव हो) जोड़ूँगा।

— टॉम

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

— Jan Hudec

@JanHudec रिफैक्टिंग + क्लीन कोड + टेस्ट = TDD

— टॉम

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

— Jan Hudec

Answer 4

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

यह आपको सबसे अधिक मिलेगा, लेकिन 99.999% परियोजनाओं के लिए आपको समय-समय पर चीजों को डिबग करना होगा। सबसे अच्छी बात यह है कि मुझे यहाँ 4 चीजें करनी हैं:

1. जहाँ भी संभव हो अपरिवर्तनीय प्रकारों का उपयोग करें - यदि किसी चीज़ का गलत मूल्य है, तो आपको ठीक से पता चल जाएगा कि तुरंत कहाँ दिखना है (जहाँ इसका निर्माण किया जा रहा है)।
2. कोड में अपरिवर्तनों को लागू करें - यदि आप जानते हैं कि एक मूल्य निश्चित रूप से अनुमति नहीं है, तो इसके लिए जांच करें और प्रवेश बिंदुओं के तरीकों और कंस्ट्रक्टर्स के अपवाद को फेंक दें। यदि आप इसे अपरिवर्तनीय प्रकारों के साथ जोड़ते हैं तो आप भी मान्यताओं के बारे में निश्चित धारणा बनाना शुरू कर सकते हैं कि क्या मान्य है या नहीं।
3. सुनिश्चित करें कि आपके पास पर्याप्त लॉगिंग है - इसे जल्दी से प्राप्त करें और यह आपको बहुत सी महत्वपूर्ण जानकारी देगा जब चीजें गलत हो जाती हैं। AOP वास्तव में यहाँ अच्छी तरह से काम करता है। आफ्टरगॉट के रूप में लॉग करना आमतौर पर थोड़ा बकवास है - इसे प्रोजेक्ट सेटअप के भाग के रूप में जल्दी से प्राप्त करें।
4. यदि आपका कोड आधार बड़ा / जटिल है तो प्राइमेटिव्स का उपयोग करने से बचें - जैसे कि केवल एक इंट का उपयोग करने के बजाय 'एज' नामक एक प्रकार है। यह पहली बार में थोड़ा व्यर्थ प्रतीत होगा, लेकिन एक पल में किसी चीज़ के सभी उपयोगों को ट्रैक करने में सक्षम होना एक बहुत बड़ी डिबगिंग जीत है।

Answer 5

मेरा 80% डिबग है। मैं साधारण कीड़े को ठीक कर रहा हूं और सभी काम करने की कोशिश कर रहा हूं।

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

अंत में, आप संभवतः जटिल बगों को डिबग करने पर 80% खर्च करेंगे।

Answer 6

कम समय डिबगिंग कैसे खर्च करें? कम कोड लिखें।

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

Answer 7

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

Answer 8

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

Comments

मैं पूरी तरह सहमत हूँ। लिखने के तुरंत बाद अपना कोड पढ़ना बहुत ही स्पष्ट रूप से कुछ स्पष्ट बगों को प्रकट कर सकता है, जैसे कॉपी-एंड-पेस्ट टाइपोस (जो बाद में कभी-कभी ढूंढना मुश्किल हो सकता है)।

— जिरकामत

Answer 9

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

• अपने संस्करण नियंत्रण सॉफ़्टवेयर का उपयोग करने का तरीका जानें।

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

• आपके द्वारा उपयोग की जाने वाली प्रोग्रामिंग भाषा की अपनी समझ में सुधार करें।

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

• तार्किक बनो

  • एक बार में एक से अधिक चीज़ों को न बदलें अन्यथा यदि व्यवहार बदलता है तो आपको पता नहीं चलेगा कि किस परिवर्तन के कारण व्यवहार में परिवर्तन हुआ।
  • अपनी मान्यताओं को सत्यापित करें।

Answer 10

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

मैं अत्यधिक स्थैतिक विश्लेषण टूल (उदाहरण के लिए FxCop / Microsoft कोड विश्लेषण, Resharper, MSC के लिए जस्टकोड) चलाने की भी सिफारिश करूंगा। ये सभी प्रकार की सामान्य कोडिंग समस्याएं पा सकते हैं जो मूर्खतापूर्ण डिबगिंग कार्यों को कम कर सकते हैं और डिबगिंग व्यवसाय तर्क पर अधिक ध्यान केंद्रित कर सकते हैं।

Answer 11

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

Comments

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

— कालेब

Answer 12

मुझे हाल ही में इस समस्या के बारे में बहुत सोचा गया है - इसका सरल उत्तर है डॉन नॉर्मन की द डिज़ाइन ऑफ़ एवरीडे थिंग्स; कोड लिखें जैसे आप एक उत्पाद डिजाइन करेंगे।

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

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

-बड़ा कोड लिखना मुश्किल। खराब इनपुट के लिए जाँच करें और बाद में के बजाय त्रुटियों को जल्द ही फेंक दें, उपयुक्त होने पर ऐप का उपयोग करें, आदि। इन्हें लॉकआउट फ़ंक्शन कहा जाता है।

जहां उचित है वहां अमूर्तता का उपयोग करें। अल्पकालिक स्मृति कमजोर है।

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

-उन्नत परीक्षण। ये वास्तव में त्रुटियों को रोकते नहीं हैं, इसलिए यह स्पष्ट करते हैं कि कीड़े कहाँ हैं, और पवित्रता प्रदान करते हैं।

मुझे यकीन है कि मैं कई और सिद्धांतों को याद कर रहा हूं, लेकिन यह है कि त्रुटि के लिए डिजाइनिंग पर पढ़ें।

Answer 13

डिबगिंग को कम करने का सबसे अच्छा तरीका, IMO, कोडिंग करते समय ध्यान केंद्रित करना और धीमा करना है। यह आपको उन गलतियों को देखने के लिए मजबूर करता है जो आपने की हैं!

Answer 14

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

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

कभी-कभी कागज के एक टुकड़े पर एक त्वरित स्क्रिबल आपको पहेली के बड़े जुड़े टुकड़ों को देखने में मदद करता है।

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

पुनश्च। मेरा मतलब है 5 शायद दस मिनट, घंटे नहीं एक विशाल कल्पना लिख ​​रहा है।

Answer 15

कुछ अच्छे जवाब पहले से ही, बस कुछ और भोजन के लिए हालांकि दूसरों को क्या कहा है के लिए जोड़ने में।

अपनी गलतियों से सीखो। बार-बार वही बनाते नहीं रहते।

प्रोग्रामिंग करते समय किनारे के मामलों को कवर करना सुनिश्चित करें - वे ऐसे स्थान हैं जहां अक्सर बग होते हैं।

आवश्यकता पर ध्यान दें। यहां तक ​​कि अगर यह काम करता है, लेकिन क्या आवश्यकता निर्दिष्ट नहीं करता है, तो यह एक बग है।

अपवाद लॉग वास्तविक मदद हो सकता है जब कुछ गलत हो जाता है अब से छह महीने। अपवादों को रिकॉर्ड करने की आदत डालें।

Answer 16

मेरे दो शीर्ष विचार 1 हैं) बेहतर कोड लिखें जो कि जब आप कुछ अप्रत्याशित करते हैं तो असफल हो जाएंगे 2) डिबगिंग में बेहतर बनें

मेरा कोड के साथ लिटरेड है

if(value!=null) throw new NotImplementedException();
if(obj.v>0) throw new Exception(); //sometimes i dont write NotImplementedException
if(value=="thing") throw ...;

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

कॉल स्टैक, ब्रेकपॉइंट्स (शर्तों के साथ) के आसपास डिबगिंग मेस में बेहतर बनने के लिए, तत्काल विंडो (जिसे शीघ्र या उत्तर विंडो के रूप में भी जाना जाता है), 'वॉच' वेरिएबल्स और जो भी हो।