आर्टिफिशियल इंटेलिजेंस के साथ डिबगिंग और क्रैश विश्लेषण

लाभ:

• प्रासंगिक कोड और परिदृश्य संदर्भ के साथ कृत्रिम बुद्धिमत्ता को क्रैश रिकॉर्ड (स्टैक ट्रेस) देकर संभावित मूल कारणों को शीघ्रता से कम करने की क्षमता
• कोड और परीक्षण में एक परिकल्पना के रूप में एआई के निदान को मान्य करने और लक्षण को शांत करने के बजाय मूल कारण को स्थायी रूप से हल करने की क्षमता
• क्रैश रिकॉर्ड और लॉग में व्यक्तिगत डेटा को छिपाकर डिबगिंग करते समय गोपनीयता की रक्षा करना

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

क्रैश लॉग पढ़ना: जहां AI सबसे अधिक चमकता है

क्रैश लॉग एक लंबा और डराने वाला टेक्स्ट होता है; अनुभवहीन डेवलपर को पता नहीं होगा कि कहां देखना है। एआई इस पाठ को सेकंडों में पार्स करता है: यह किस लाइन पर क्रैश हुआ, कौन सा अपवाद फेंका गया, संभावित कारण क्या है। सामान्य मोबाइल त्रुटियाँ स्पष्ट हैं और AI उन्हें तुरंत पहचान लेता है: NullPointerException (शून्य मान तक पहुँचने का प्रयास), Android पर IndexOutOfBoundsException (गैर-मौजूद सूची तत्व तक पहुँचना), iOS पर EXC_BAD_ACCESS (मुक्त मेमोरी तक पहुँचना), अप्रत्याशित रूप से शून्य पाया गया (शून्य वैकल्पिक को मजबूर करना)।

मोबाइल क्रैश के सबसे सामान्य प्रकार और उनके विशिष्ट कारण इस प्रकार हैं:

त्रुटि (अपवाद)

मंच

विशिष्ट कारण

NullPointerException

एंड्रॉइड

शून्य मान तक पहुँचना

IndexOutOfBoundsException

एंड्रॉइड

गैर-मौजूद सूची तत्व तक पहुँचना

अप्रत्याशित रूप से शून्य पाया गया

आईओएस

शून्य वैकल्पिक (!) को बलपूर्वक खोलना

EXC_BAD_ACCESS

आईओएस

मुक्त स्मृति तक पहुँचना

एएनआर/फ्रीज

एंड्रॉइड

मुख्य धागे पर लंबी/भारी प्रोसेसिंग

चरण दर चरण डिबगिंग प्रवाह:

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

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

व्यक्तिगत डेटा जाल

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

सावधानी: एआई द्वारा सुझाया गया समाधान "बग को शांत" कर सकता है लेकिन मूल कारण का समाधान नहीं कर सकता है। उदाहरण के लिए, NullPointerException को null चेक के साथ लपेटने से क्रैश रुक जाएगा, लेकिन यदि आप यह नहीं समझ पाते हैं कि मान null क्यों है तो वास्तविक तर्क त्रुटि जारी रहेगी। बीमारी का इलाज करें, लक्षण का नहीं।

मूल कारण विश्लेषण

पेशेवर डिबगिंग का उद्देश्य त्रुटि को शांत करना नहीं बल्कि मूल कारण का पता लगाना है। मैंने एआई से पूछा "यह शून्य क्यों हो सकता है, यह डेटा प्रवाह में कहां खो गया होगा?" asking, “how do I silence this?” It is much more valuable than asking. एक बार मूल कारण मिल जाने पर, एक ही त्रुटि के दर्जनों प्रकार एक ही बार में हल हो जाते हैं। एआई इस श्रृंखला तर्क में अच्छा है: इनपुट से आउटपुट तक डेटा का पालन करें और यह सोचने के लिए कहें कि यह कहां टूटता है।

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

Case 1 — 2 hours of work in 10 minutes. एक डेवलपर ने उस बग को खोजने में 2 घंटे बिताए जो केवल एक विशिष्ट सैमसंग मॉडल पर क्रैश हुआ था। एआई को क्रैश लॉग (व्यक्तिगत क्षेत्रों को साफ़ करना) दिया; YZ ने कहा कि त्रुटि एक मेमोरी ओवरफ्लो की ओर इशारा करती है जो उस डिवाइस के एक अलग कैमरा रिज़ॉल्यूशन के साथ होती है। सुराग से 10 मिनट में कारण का पता चल गया। एआई ने खोज को तेज किया, मानव ने समाधान का सत्यापन किया।

केस 2 - खामोश बग वापस आ गया है। एक टीम ने बार-बार होने वाली दुर्घटना को पकड़ने के लिए एआई सुझाव का उपयोग करके उसे शांत कर दिया। क्रैश होना बंद हो गया, लेकिन उपयोगकर्ताओं ने शिकायत करना शुरू कर दिया कि "डेटा सेव नहीं हो रहा है"; क्योंकि वास्तविक समस्या (डेटाबेस कनेक्शन) अभी भी वहीं थी, वह अदृश्य हो गई थी। एक बार मूल कारण मिल जाने पर, दुर्घटना और डेटा हानि दोनों का समाधान हो गया। सबक: चुप रहने से समाधान नहीं होता.

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

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

ख़राब संकेत: "यह त्रुटि क्यों होती है? [स्टैक ट्रेस]"

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

कॉपी करने योग्य टेम्पलेट

क्रैश विश्लेषण टेम्पलेट: "निम्नलिखित क्रैश का विश्लेषण करें। संदर्भ: [आप क्या कर रहे हैं, कौन सा डिवाइस/संस्करण]। प्रासंगिक कोड: [कोड]। क्रैश लॉग (व्यक्तिगत डेटा साफ़ किया गया): [ट्रेस]। 3 सबसे संभावित मूल कारण और सत्यापन + प्रत्येक के लिए स्थायी समाधान दें। साथ ही उन समाधानों को भी चिह्नित करें जो लक्षण को शांत करते हैं।"

मूल कारण टेम्पलेट: "यह मान अप्रत्याशित रूप से [शून्य/गलत] आता है। इनपुट से इस बिंदु तक डेटा प्रवाह का पालन करें: यह कहां खो सकता है या दूषित हो सकता है? मुझे बताएं कि मुझे प्रत्येक चरण में कहां जांच करनी चाहिए। [कोड]"

लॉग रीडिंग टेम्प्लेट: "इस लॉग आउटपुट की व्याख्या करें: कौन सी घटनाएँ क्रम में हुईं, असामान्यता कहाँ है, त्रुटि से पहले अंतिम स्वस्थ कदम क्या था? [लॉग - व्यक्तिगत डेटा साफ़ किया गया]"

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

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

• Giving context-free stack trace. प्रासंगिक कोड और परिदृश्य के बिना, एआई सामान्य भविष्यवाणी करता है।
• लॉग के साथ व्यक्तिगत डेटा को एआई में चिपकाना। गोपनीयता में विच्छेद; पहले मुखौटा.
• लक्षण को शांत करें. ट्राई-कैच के साथ क्रैश को छिपाने से मूल समस्या खत्म हो जाती है और नई समस्याएं पैदा हो जाती हैं।
• पहले सुझाव को बिना सत्यापित किये लागू करना। The diagnosis of AI is a hypothesis; कोड में पुष्टि करें.
• Trying to reproduce it in the emulator. कुछ त्रुटियाँ केवल वास्तविक डिवाइस/स्थिति पर दिखाई देती हैं।
• Not retesting after correction. The fix might have broken something else; प्रतिगमन की जाँच करें.

सारांश

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

आवेदन कार्य

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

चेकलिस्ट

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