Debugging: इसे स्वयं खोजना

अधिकांश शुरुआती लोग बग को दीवार की तरह मानते हैं। वे इसे मारते हैं, रुकते हैं, और किसी और को इसे पार करने के लिए कहते हैं। जो आदत वास्तव में कौशल बनाती है वह अलग है: आप बग को एक ऐसे सवाल की तरह देखना सीखते हैं जिसका जवाब मिल सकता है, और आप इसे खोजते हैं इससे पहले कि आप पूछने लगें।

त्रुटि संदेश को गड़बड़ी की तरह नहीं, सबूत की तरह पढ़ें

Stack traces लगातार छोड़े जाते हैं क्योंकि वे डरावने दिखते हैं। लेकिन वे आमतौर पर आपको बता रहे हैं कि कुछ कहाँ और क्यों टूटा। अगर आप Python में TypeError: 'NoneType' object is not subscriptable प्राप्त करते हैं, तो यह यादृच्छिक बकवास नहीं है — इसका मतलब है कि एक चर जिसे आप list या dict रखने की उम्मीद करते हैं, वह वास्तव में None है। लाइन नंबर आपको बताता है कि यह कहाँ है। आपका काम उस लाइन से पीछे की ओर ट्रेस करना और यह पता लगाना है कि मान को कहाँ सेट किया जाना चाहिए था लेकिन नहीं किया गया।

कुछ भी ऑनलाइन खोजने से पहले ऐसा करें: पहले traceback की आखिरी लाइन पढ़ें, फिर ऊपर की ओर काम करें। आखिरी लाइन आमतौर पर वास्तविक exception का नाम बताती है। इसके ऊपर की लाइनें call chain दिखाती हैं जो आपको वहाँ ले गई।

इसे जानबूझकर दोहराएँ

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

समस्या को आधे में काटें, फिर फिर से आधे में

Binary search केवल sorted arrays के लिए नहीं है — यह लंबे फ़ंक्शन या pipeline में टूटे कोड को खोजने का सबसे तेज़ तरीका है। अपने लॉजिक के दूसरे आधे हिस्से को कमेंट करें या बाईपास करें और जांचें कि क्या पहला आधा अभी भी बग पैदा करता है। अगर हाँ, तो समस्या पहले आधे में है। अगर नहीं, तो यह दूसरे में है। दोहराएँ। यह 200-लाइन स्क्रिप्ट के लिए उतना ही काम करता है जितना यह multi-stage data pipeline के लिए काम करता है जहाँ आप print() या df.head() के साथ प्रत्येक चरण पर आउटपुट की जांच कर रहे हैं।

यह यादृच्छिक रूप से लाइनों को बदलने और फिर से चलाने के लिए बेहतर है, जो अधिकांश लोग दबाव में करते हैं और यह समय बर्बाद करता है जो इसे बचाता है।

जब print() काम करना बंद कर दे तो debugger का उपयोग करें

print() statements सरल मामलों के लिए ठीक हैं, लेकिन एक बार जब आप कई फ़ंक्शन कॉल्स में state को ट्रैक कर रहे हैं, तो एक वास्तविक debugger वास्तविक समय बचाता है। Python में, suspicious लाइन से पहले import pdb; pdb.set_trace() डालें, स्क्रिप्ट चलाएँ, और आपको एक live prompt मिलता है जहाँ आप चर का निरीक्षण कर सकते हैं, n के साथ लाइन दर लाइन चल सकते हैं, और s के साथ फ़ंक्शन कॉल्स में step कर सकते हैं। VS Code का built-in debugger एक ही काम करता है breakpoints के साथ जो आप type करने के बजाय क्लिक करते हैं। किसी भी तरह से, लक्ष्य समान है: अपने प्रोग्राम की वास्तविक state को देखें अनुमान लगाने के बजाय कि यह शायद क्या है।

इसे अपने बाकी प्रोजेक्ट से अलग करें

अगर कोई बग बड़े codebase के अंदर होता है, तो इसे बड़े codebase के अंदर डीबग न करें। संबंधित फ़ंक्शन को एक नई फ़ाइल में नकली, न्यूनतम इनपुट के साथ कॉपी करें जो एक ही विफलता को trigger करता है। अगर बग गायब हो जाता है, तो आस-पास का context — एक global variable, एक import, stale state — असली कारण है, और आपने अभी कुछ महत्वपूर्ण सीखा है। अगर बग isolation में बना रहता है, तो अब आपके पास एक छोटा, शेयरेबल, testable case है, और आप वास्तविक fix के बहुत करीब हैं।

अपनी मानताओं की जांच memory के खिलाफ नहीं, reality के खिलाफ करें

डीबगिंग का एक बड़ा हिस्सा समय unchallenged assumptions के लिए जाता है: