डिबगिंग और मूल कारण विश्लेषण

लाभ:

• किसी बग को सबसे छोटे प्रतिलिपि प्रस्तुत करने योग्य उदाहरण में कम करने और इसे पूर्ण प्रमाण के साथ एआई में ले जाने की क्षमता
• सबसे सस्ते नियंत्रण के साथ साक्ष्य-आधारित परिकल्पनाओं का परीक्षण करने और मूल कारण खोजने की क्षमता
• मूल कारण को हल करने और लक्षण को ठीक करने के बजाय प्रतिगमन परीक्षण के साथ इसे सुरक्षित करने की क्षमता

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

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

साक्ष्य ही सब कुछ क्यों है?

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

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

युक्ति: बग को एआई में पोर्ट करने से पहले, इसे सबसे छोटे प्रतिलिपि प्रस्तुत करने योग्य उदाहरण तक सीमित करें। त्रुटि को ट्रिगर करने वाला सबसे छोटा कोड और इनपुट आपके और मॉडल दोनों के लिए चीजों को मौलिक रूप से आसान बना देता है; अक्सर इस कमी के दौरान आप स्वयं ही इसका कारण ढूंढ लेते हैं।

चरण दर चरण: मूल कारण विश्लेषण प्रवाह

1. लक्षण स्पष्ट करें. "क्या हो रहा है, आपको क्या होने की उम्मीद थी?" दोनों को एक वाक्य में लिखिए।
2. सबूत इकट्ठा करो. पूर्ण त्रुटि संदेश, स्टैक ट्रेस, प्रासंगिक लॉग लाइनें, ट्रिगरिंग प्रविष्टि, संस्करण जानकारी।
3. परिकल्पना उत्पन्न करें. एआई से "3 संभावित कारण जो इस लक्षण की व्याख्या करते हैं और मैं प्रत्येक के लिए परीक्षण कैसे करूं?" पूछना।
4. पहले सबसे सस्ती परिकल्पना का परीक्षण करें. एक लॉग जोड़ें, एक मान प्रिंट करें, एक परीक्षण चलाएँ। क्या साक्ष्य परिकल्पना की पुष्टि करते हैं?
5. मूल कारण को ठीक करें, लक्षण को नहीं। पैच लगाकर लक्षण को शांत करने के बजाय, मूल कारण का समाधान करें।
6. सत्यापित करें और प्रतिगमन परीक्षण जोड़ें। त्रुटि गायब देखें; फिर एक परीक्षण लिखें जो उस त्रुटि को पकड़ लेगा ताकि वह वापस न आये।

तीन मिनी मामले

केस 1 - स्टैक ट्रेस से सही फ़ाइल प्राप्त हुई। एक एप्लिकेशन कुछ अनुरोधों पर 500 त्रुटि लौटा रहा था। डेवलपर ने एआई को पूर्ण स्टैक ट्रेस और ट्रिगरिंग अनुरोध दिया; मॉडल ने अनुमान लगाया कि त्रुटि दिनांक पार्सिंग परत में कोई नहीं मान के कारण हुई थी। डेवलपर ने उस लाइन में एक लॉग जोड़ा, उसे सत्यापित किया और 15 मिनट में हल कर दिया; एक दिन पहले अप्रमाणित प्रयोगों से 2 घंटे बर्बाद हुए।

केस 2 - मतिभ्रम के कारण गलत राह पर चल पड़ा। एक अन्य डेवलपर ने बस इतना लिखा "डेटाबेस कनेक्शन गिर रहा है"। एआई ने बिना किसी सबूत के कनेक्शन पूल सेटिंग पर आरोप लगाया; डेवलपर ने इस सेटिंग के साथ छेड़छाड़ करने में 40 मिनट का समय बिताया। वास्तविक कारण नेटवर्क पक्ष पर एक टाइमआउट था और केवल लॉग को देखने से पता चला था। सबक: बिना सबूत के ली गई परिकल्पना केवल संभावित होती है, विश्वसनीय नहीं।

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

चार प्रतिलिपि योग्य टेम्पलेट

साक्ष्य-आधारित परिकल्पना निर्माण:

मैं एक बग डीबग कर रहा हूं। नीचे दिए गए साक्ष्य।- अपेक्षित व्यवहार: {{अपेक्षित}} - देखा गया व्यवहार: {{अवलोकन किया गया}} - त्रुटि संदेश / स्टैक ट्रेस: ​​{{ट्रेस}} - ट्रिगरिंग इनपुट: {{इनपुट}} - पर्यावरण/संस्करण: {{संस्करण}} 3 सबसे संभावित मूल कारणों की सूची बनाएं जो इस लक्षण की व्याख्या करते हैं। प्रत्येक के लिए: मैं कैसे परीक्षण करूं (सबसे सस्ता चेक) और यदि यह सत्य है तो इसे कैसे ठीक करूं। यदि साक्ष्य अपर्याप्त है, तो मुझे बताएं कि आपको कौन सी अतिरिक्त जानकारी चाहिए।

स्टैक ट्रेस की व्याख्या करना:

इस स्टैक ट्रेस को पढ़ें. इस बीच अंतर करें कि त्रुटि संभवतः किस पंक्ति (रूट) से शुरू होती है और कौन सी पंक्तियाँ श्रृंखला की निरंतरता हैं। पहले देखने के लिए 1-2 स्थान सुझाएँ। संबंधित कोड:{{कोड}}ट्रेस:{{ट्रेस}}

न्यूनतम रिप्रो घटाव:

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

सुधार के बाद सत्यापन और प्रतिगमन परीक्षण:

मान लें कि मूल कारण {{कारण}} है और मैं निम्नलिखित सुधार करता हूं: {{ठीक करें}}।1) क्या यह सुधार वास्तव में लक्षण को ठीक करता है, क्या इसका कोई दुष्प्रभाव होगा?2) एक प्रतिगमन परीक्षण लिखें जो भविष्य में इस बग को पकड़ लेगा।

कमजोर संकेत/मजबूत संकेत

कमज़ोर: "कोड काम नहीं करता, क्यों?"

मजबूत: "नोड 20 / एक्सप्रेस। POST /orders 500 लौटाता है जब आइटम शरीर में एक खाली स्ट्रिंग है; 400 लौटाया जाना चाहिए। स्टैक ट्रेस: टाइप एरर: अपरिभाषित के गुणों को नहीं पढ़ सकता ('0' पढ़ना) - संलग्न पूर्ण ट्रेस और संबंधित हैंडलर है। मुझे 3 सबसे संभावित कारण बताएं जो इस लक्षण को समझाते हैं और प्रत्येक का परीक्षण कैसे करें। [ट्रेस + कोड]"

शक्तिशाली संस्करण; यह वातावरण, समापन बिंदु, ट्रिगर इनपुट, सटीक त्रुटि प्रकार और अपेक्षित व्यवहार देता है। मॉडल अब पूर्वानुमान नहीं, बल्कि विश्लेषण कर सकता है।

कदम

एआई का योगदान

आपका नियंत्रण

सबूत जुटाना

क्या सबूत चाहिए, याद दिलाते हैं

सच में सबूत जुटाता है

परिकल्पना पीढ़ी

संभावित कारणों की सूची बनाएं

संदर्भ के साथ प्राथमिकता देता है

परिकल्पना परीक्षण

परीक्षण पद्धति की अनुशंसा करता है

व्यक्तिगत रूप से संचालन और निरीक्षण करता है

सुधार

पैच अनुशंसा करता है

क्या यह मूल कारण का समाधान करता है? यह सच है.

प्रतिगमन

एक परीक्षण लिखता है

सत्यापित करता है कि परीक्षण टूटा हुआ है

मूल कारण का समाधान करें, लक्षण का नहीं

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

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

सामान्य गलतियाँ

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

संक्षेप में

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

आवेदन कार्य

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

चेकलिस्ट

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