सॉफ्टवेयर कोड को डीबग कैसे करें: 7 दोहराए जाने वाले चरण

एक कार्ट सफलतापूर्वक कंपाइल हो सकता है और फिर भी $5 अतिरिक्त दे सकता है। इस नियंत्रित अभ्यास में, यह खामी जानबूझकर बनाई गई थी: एक बार कूपन लगाएं, फिर क्वांटिटी बदलने पर वह दोबारा घट जाए। असली सवाल यह है कि आप कैसे साबित करें कि यह अतिरिक्त कटौती कहां हो रही है।

गणित इस जांच को ठोस बनाता है। $54 का कार्ट एक कूपन के साथ** $49** हो जाता है। एक और** $24** का आइटम जोड़ने पर सही डिस्काउंटेड टोटल** $73** बनता है। बग वाली गणना $68 देती है। आप इस अंतर का उपयोग स्टेट ट्रांज़िशन को ट्रेस करने के लिए कर सकते हैं, बजाय इसके कि कोई संदिग्ध लाइन का अंदाज़ा लगाएं।

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

बग को डीबग करने से पहले समझें

लक्षण को मूल कारण से अलग करें

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

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

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

फेल्योर को वर्गीकृत करें

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

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

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

सबूत संरक्षित करें और प्रभाव का आकलन करें

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

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

सॉफ्टवेयर कोड डीबग करने के 7 दोहराए जाने वाले चरण

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

एक दोहराने योग्य जांच पुनरुत्पादन को संरक्षित रखते हुए संभावित कारणों की संख्या कम करती है।

चरण 1 — फेल्योर को परिभाषित करें और दोहराएं

"कूपन खराब है" कहने के बजाय एक सीक्वेंस लिखें: कार्ट लोड करें, $5 कूपन लगाएं, $24 वाले आइटम की क्वांटिटी एक से दो करें, फिर टोटल की तुलना $78 − $5 = $73 से करें। शुरुआती क्वांटिटी शामिल करें ताकि अपेक्षित परिणाम स्पष्ट रहे।

$49 और $68 राशियां लगातार बगी-प्रीव्यू कैप्चर में दिखती हैं। शुरुआती $54 प्लान और बिल्ड रिपोर्ट में बताया गया है; बाद में फिक्स किए गए, रीसेट प्रीव्यू में भी $54 दिखता है। स्क्रीनशॉट्स इन स्टेट्स को संरक्षित करते हैं, जबकि एक रेकॉर्डिंग या इंटरेक्शन टेस्ट पूरे क्लिक सीक्वेंस को सत्यापित करेगा।

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

अपेक्षित मूल्य डेमो की कीमतों का अनुसरण करते हैं। बगी परिणाम उसी $5 कूपन को दूसरी बार घटाता है।

चरण 2 — इसे सबसे छोटे फेलिंग केस में घटाएं

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

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

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

चरण 3 — एरर, लॉग्स, स्टैक फ्रेम्स और स्टेट का निरीक्षण करें

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

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

VS Code के डॉक्यूमेंटेशन से लिया गया एक वास्तविक डीबगर इंटरफेस। पैनल कई तरह के सबूत एक साथ दिखाता है।

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

चरण 4 — सर्च स्पेस संकुचित करें

संदिग्ध रास्ते को उपयोगी बाउंड्रीज़ में बांटें। क्या आइटम स्टेट गलत है, क्या सबटोटल गलत है, या बाद में दिखाया गया टोटल गलत हो जाता है? यदि सबटोटल $78 है लेकिन डिस्प्ले $68 है, तो आप मल्टीप्लिकेशन की जांच बंद कर सकते हैं और डिस्काउंट एप्लीकेशन का निरीक्षण कर सकते हैं।

एक रिग्रेशन के लिए, git bisect एक ज्ञात अच्छे और खराब रिविज़न के बीच सर्च करता है। एक आदर्श बाइनरी सर्च में, 1,024 संभावनाएं 10 हैल्विंग राउंड्स में सिमट कर एक रह जाती हैं। वास्तविक जांच के लिए भरोसेमंद एंडपॉइंट्स, रीप्रोड्यूसेबल बिल्ड्स, और एक भरोसेमंद अच्छा-या-खराब चेक भी चाहिए।

Bisect रिग्रेशन से जुड़े बदलाव को ढूंढता है; यह खुद मूल कारण नहीं बताता।

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

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

चरण 5 — एक समय में एक परिकल्पना का परीक्षण करें

परिकल्पना को फॉल्सिफाएबल (नकारने योग्य) बनाएं: "क्वांटिटी एक्शन स्टोर किए गए कूपन कटौती में एक और $5 जोड़ता है।" यदि यह सच है, तो पहली क्वांटिटी बदलाव के बाद कटौती $5 से $10 तक बढ़नी चाहिए जबकि कूपन सक्रिय रहता है। इस संचय को हटाने से ठीक एक फ्लैट डिस्काउंट बहाल होना चाहिए।

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

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

चरण 6 — मूल कारण ठीक करें

स्टेट मॉडल एक केंद्रित सुधार की ओर इशारा करता है: फ्लैट कटौती को क्वांटिटी बदलावों के दौरान संचित करने के बजाय कूपन स्टेट से निकालें (derive)। यह React के अतिरेक स्टेट से बचने संबंधी मार्गदर्शन का पालन करता है। यदि कोई वैल्यू वर्तमान इनपुट्स से कैलकुलेट की जा सकती है, तो एक अलग स्टोर की गई कॉपी असहमत होती जा सकती है।

डॉक्यूमेंटेशन का उदाहरण नामों का उपयोग करता है; वही सिद्धांत आइटम्स और कूपन स्टेट से निकाले गए कार्ट टोटल पर लागू होता है।

एक सरलीकृत सुधार पैटर्न वर्तमान कूपन स्टेट से डिस्काउंट निकालता है:

const subtotal = getSubtotal(state.quantities);
const couponDeduction = state.couponApplied ? COUPON_VALUE : 0;
const total = subtotal - couponDeduction;

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

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

चरण 7 — फिक्स को सत्यापित, दर्ज और मॉनिटर करें

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

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

डीबगिंग मेथड को बग टाइप से मिलाएं

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

लाइव स्टेट के लिए ब्रेकपॉइंट्स और स्टेपिंग का उपयोग करें

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

आधिकारिक ओवरव्यू अलग-अलग लक्षणों को अलग-अलग रुकने की शर्तों से जोड़ता है।

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

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

debugger स्टेटमेंट एक निरीक्षण सहायक है। जब कोई डीबगिंग सुविधा उपलब्ध नहीं होती, तो इसका कोई उपयोगी रुकने का प्रभाव नहीं होता।

डिस्ट्रिब्यूटेड सबूत के लिए लॉग्स, ट्रेसिंग, और प्रोफाइलिंग का उपयोग करें

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

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

Logpoints सोर्स एडिट किए बिना या एप्लीकेशन को रोके बिना एक वैल्यू रिकॉर्ड कर सकते हैं।

कारण को अलग करने के लिए टेस्ट, एसर्शन, और बाइनरी सर्च का उपयोग करें

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

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

AI-जनरेटेड कोड को पैच पर भरोसा किए बिना डीबग करें

चलाने से पहले जनरेट किए गए बदलाव की समीक्षा करें

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

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

रीराइट मांगने के बजाय मॉडल को सबूत दें

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

एक केंद्रित रिक्वेस्ट हो सकती है: "SET_QUANTITY के बाद couponDeduction कैसे बदलता है, ट्रेस करें। समझाएं कि $78 का सबटोटल $68 क्यों बन जाता है। एक मिनिमल पैच सुझाएं जो फ्लैट कूपन को $5 पर रखे, और क्वांटिटी बदलने से पहले कूपन लगाने के लिए एक टेस्ट जोड़ें।" आप मॉडल को कुछ ऐसा देते हैं जिस पर वह तर्क कर सके और कुछ ऐसा जो आप सत्यापित कर सकें।

डिफ का निरीक्षण करें और स्वतंत्र रूप से सत्यापित करें

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

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

Enter Pro ऐप को प्रीव्यू से कोड तक डीबग करें

कूपन डीबगिंग डेमो दिखाता है कि एक नियंत्रित Enter Pro प्रोजेक्ट में सॉफ्टवेयर कोड डीबग कैसे करें। छह कैप्चर प्रॉम्प्ट, प्लान, बगी प्रीव्यू, रिपेयर रिक्वेस्ट, और रिपेयर की गई प्रीव्यू को फॉलो करते हैं। यह खामी इस अभ्यास के लिए जानबूझकर बनाई गई थी।

बिल्ड करने से पहले एक नियम तय करें

प्रॉम्प्ट प्राइसेज़ को $24, $18, और $12 पर फिक्स करता है, हर क्वांटिटी को एक से शुरू करता है, और शिपिंग व टैक्स को बाहर रखता है। नियम सरल है: एक सक्रिय कूपन ठीक $5 घटाता है। यह पहले बगी वर्शन मांगता है ताकि सुधार से पहले फेल्योर संरक्षित किया जा सके।

Enter Pro बिल्ड प्रॉम्प्ट: क्वांटिटी बदलाव के बाद जानबूझकर एक दूसरी $5 कटौती बनाना।

प्लान शुरू में $54, कूपन लगने के बाद $49, और केतली की क्वांटिटी बढ़ाने पर सही $73 के बजाय $68 दिखाए जाने का पूर्वानुमान लगाता है। एक प्लान इच्छित व्यवहार को दर्ज करता है; प्रीव्यू अगला सबूत देता है।

प्रोजेक्ट प्लान प्राइसेज़, अपेक्षित टोटल्स, और प्लान की गई क्वांटिटी-एक्शन खामी को दर्ज करता है।

प्रीव्यू में फेल्योर कैप्चर करें

सभी क्वांटिटीज़ एक पर और कूपन सक्रिय होने के साथ, प्रीव्यू सबटोटल $54, कटौती $5, और दोनों टोटल्स $49 दिखाता है। केतली की क्वांटिटी दो करने पर सबटोटल $78 हो जाता है, लेकिन कटौती $10 बन जाती है। दिखाया गया $68 और स्वतंत्र रूप से कैलकुलेट किया गया $73 यह असमानता उजागर करते हैं।

क्वांटिटी बदलाव से पहले: सबटोटल $54, कूपन कटौती $5, दिखाया गया और सही टोटल $49।

केतली की क्वांटिटी दो करने के बाद: सबटोटल $78, कटौती $10, दिखाया गया $68, सही $73।

दिखाई गई प्लान couponDeduction को स्टोर करती है। APPLY_COUPON इसे $5 पर सेट करता है; SET_QUANTITY कूपन सक्रिय रहने पर एक और $5 जोड़ता है। यह प्लान किया गया स्टेट पथ देखी गई कटौती वृद्धि से मेल खाता है। इसे पैच करने से पहले संबंधित रिड्यूसर कोड का निरीक्षण करें।

एक केंद्रित सुधार मांगें

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

रिपेयर प्रॉम्प्ट एक मिनिमल बदलाव और वास्तविक रिग्रेशन सबूत मांगता है, जबकि 68/73 की खामी अभी भी दिखाई देती है।

सही स्तर पर सुधार सत्यापित करें

आखिरी कैप्चर कूपन खामी को ठीक किया गया बताता है और कहता है कि कटौती अब कूपन स्टेट से निकाली जाती है। इसका प्रीव्यू रीसेट है: हर क्वांटिटी एक है, कूपन निष्क्रिय है, और दोनों टोटल्स $54 हैं। यह रिपेयर की गई बेसलाइन दिखाता है; यह रिपेयर की गई क्वांटिटी-बदलाव टोटल $73 नहीं दिखाता।

रीसेट स्टेट पर रिपेयर की गई प्रीव्यू: दोनों टोटल्स $54। रिपोर्ट अलग से उन UI चेक्स की पहचान करती है जो चलाई नहीं गईं।

रिपोर्ट एक्ज़िट कोड 1 के साथ फिक्स-से-पहले की npm टेस्ट लॉग कैप्चर का हवाला देती है। स्क्रीनशॉट पूरे रॉ फेलिंग और पासिंग रन्स या वास्तविक डिफ को नहीं दिखाता। यह यह भी बताता है कि टेस्ट्स रिड्यूसर और टोटल फंक्शन्स को कवर करते हैं, UI/DOM टेस्टिंग के लिए कोई jsdom और Testing Library एनवायरनमेंट नहीं है।

कूपन सक्रिय रहते हुए Apply बटन निष्क्रिय रहता है, तो दोबारा लगाना एक रिड्यूसर-स्तर की जांच है। मोबाइल विड्थ और डार्क स्टाइलिंग को भी असत्यापित मार्क किया गया है। सत्यापन पूरा करने के लिए, रिपेयर किए गए कार्ट को रीसेट करें और $54 → $49 → $73 को दो बार दोहराएं, फिर घटाव और कूपन हटाने की जांच करें। डिफ और पूरा रिग्रेशन आउटपुट बरकरार रखें।

बग को एस्केलेट करें और सबूत के साथ बंद करें

जब जोखिम एक और प्रयोग के मूल्य से ज्यादा हो, तो एस्केलेट करें

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

एक पुनरुत्पादन योग्य सबूत पैकेज ट्रांसफर करें

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

कोड-डीबगिंग चेकलिस्ट पूरी करें

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

बंद करने की प्रक्रिया कारण और सुधार को संरक्षित सबूत से जोड़ती है। एक पास होने वाला बिल्ड इसका केवल एक हिस्सा कवर करता है।

अंतिम विचार: सॉफ्टवेयर कोड को भरोसेमंद तरीके से डीबग कैसे करें

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

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

Enter Pro में यह वर्कफ़्लो आज़माएं: एक फेल हो रहा केस संरक्षित करें, एक केंद्रित सुधार मांगें, और स्वीकार करने से पहले सबूत की समीक्षा करें।

अक्सर पूछे जाने वाले सवाल

कोड फेल होने पर सबसे पहले क्या करना चाहिए?

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

वह कोड डीबग कैसे करूं जो सिर्फ कभी-कभी फेल होता है?

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

क्या मुझे प्रिंट स्टेटमेंट या डीबगर का उपयोग करना चाहिए?

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

क्या AI मेरे लिए कोड डीबग कर सकता है?

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

बग को बिना बिगाड़े कैसे डीबग करूं?

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

फिक्स होने के बाद बग दोबारा क्यों आता है?

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

कोड डीबग करने के लिए Enter Pro का उपयोग कैसे करूं?

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

Enter Pro किसी बग को ठीक करने के बाद मुझे क्या सत्यापित करना चाहिए?

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