अधिकांश लोग विज्ञान के बजाय डिबगिंग को एक कला मानते हैं। यहां उन लोगों के लिए जो इसे एक कला के बजाय एक विज्ञान के रूप में मानते हैं - एक नई समस्या / बग / समस्या का सामना करने पर आप किस प्रक्रिया (तों) का उपयोग करते हैं?
अधिकांश लोग विज्ञान के बजाय डिबगिंग को एक कला मानते हैं। यहां उन लोगों के लिए जो इसे एक कला के बजाय एक विज्ञान के रूप में मानते हैं - एक नई समस्या / बग / समस्या का सामना करने पर आप किस प्रक्रिया (तों) का उपयोग करते हैं?
जवाबों:
बहुत सामान्य शब्दों में, मैं क्या करूँ:
समस्या को अलग करने का प्रयास करें। जब बग पहली बार दिखाई दिया तो क्या बदल गया है, इसके बारे में सोचो। आप कहाँ पर काम कर रहे हैं? आप किस कोड का हिस्सा बदल रहे थे? मेरे कीड़े के 99% इस तरह से हल कर रहे हैं। यह आमतौर पर कुछ मूर्खतापूर्ण है।
अगर मुझे इस बात का अंदाजा है कि समस्या कहां है, तो उस कोड को अच्छे से देख लें जो इसका कारण लगता है। इसे पढ़ें। इसे भी जोर से पढ़ें। अपने आप से पूछें: "मैं क्या हासिल करने की कोशिश कर रहा हूं?"। कुछ प्रकार की समस्याओं के लिए: क्या इसके कुछ दुष्प्रभाव हो सकते हैं या क्या यह किसी अन्य स्थान पर कोड से प्रभावित हो सकता है जिस तरह से मैंने नहीं सोचा था?
क्या गलत है, कहां और कब (नीचे देखें) का विश्लेषण करने के लिए विभिन्न तरीकों से प्रयास करें।
यदि मेरे पास अभी भी कोई सुराग नहीं है, तो मैं यह जांचता हूं कि क्या मेरे स्रोत के पुराने संस्करण में भी यही समस्या है, यह जानने की कोशिश करें कि मेरे विकास के समय में समस्या पहली बार सामने आई थी। ऐसा करने के लिए आपको एक अच्छा संस्करण नियंत्रण प्रणाली के साथ काम करने की आवश्यकता है, जैसे कि गिट (git में इस तरह के डिबगिंग के लिए बाइसेक्ट नामक एक विशेषता है)।
यदि अब भी कोई सुराग नहीं है, तो एक ब्रेक लें .... यह वास्तव में अक्सर मदद करता है।
ड्राइंग बोर्ड पर वापस जाएं - समीक्षा करें कि आपके कार्यक्रम को कैसे काम करना है और क्या यह वास्तव में समझ में आता है।
यह वास्तव में समस्या की तरह पर निर्भर करता है, लेकिन मुझे लगता है कि जहां समस्या हो सकती है की एक सामान्य विचार है, तो:
यदि मुझे संदेह है कि समस्या कोड / हाल के बदलाव के किसी हिस्से में है, तो मैं सबसे पहले कोड हटाने / बदलने या जो भी बग प्राप्त करने की कोशिश करता हूं, वह कोड को सरल बनाकर गायब हो जाता है, और फिर समस्याग्रस्त कोड को वापस लाकर एक अच्छा देखो।
ब्रेकपॉइंट के साथ डिबगर चलाएं (यदि संभव हो तो) और इस बात पर एक नज़र डालें कि मेरे डेटा को यह देखने की कोशिश करना कि यह कब बुरा काम करना शुरू कर देता है, जहां बेहतर तरीके से यह पता चलता है कि चीजें गलत हैं।
bzr qdiffकमांड के साथ देखने के लिए बहुत छोटी और आसान है ।
मैं परीक्षण-संचालित विकास ( टीडीडी ) का उपयोग करने का प्रयास करता हूं । मैं एक परीक्षण लिखता हूं जो बग को दोहराता है, फिर परीक्षण पास करने के लिए प्रयास करें। कभी-कभी परीक्षण लिखने की क्रिया बग को खोजने में मदद करती है।
यह मुझे अधिकांश समय डिबगर से बाहर रखता है, और बग को फिर से प्रस्तुत करने से रोकने के लिए प्रतिगमन परीक्षण प्रदान करता है।
कुछ लिंक:
विज्ञान शब्द के लिए कई परिभाषाएँ हैं, लेकिन ऐसा लगता है कि आप संभवतः " वैज्ञानिक पद्धति " को और अधिक सटीक रूप से संदर्भित कर सकते हैं । वैज्ञानिक पद्धति को कुछ घटनाओं को देखते हुए (संभवतः एक बग या अप्रत्याशित कार्यक्रम व्यवहार) के रूप में संक्षेपित किया जा सकता है, व्यवहार की व्याख्या करने के लिए एक परिकल्पना या परिकल्पना तैयार की जाती है, और इसे साबित करने के लिए प्रयोग किए जाने की सबसे अधिक संभावना है (एक परीक्षण लिखना समस्या को मज़बूती से पुन: पेश करता है)।
बग (घटना) के प्रकार व्यावहारिक रूप से अंतहीन हो सकते हैं और कुछ को एक अच्छी तरह से परिभाषित प्रक्रिया की आवश्यकता नहीं होती है। उदाहरण के लिए, कभी-कभी आप बग का निरीक्षण करते हैं और आपको तुरंत पता चल जाता है कि इसका क्या कारण है क्योंकि आप कोड से बहुत परिचित हैं। दूसरी बार, आप जानते हैं कि कुछ इनपुट (कार्रवाई, चरणों की श्रृंखला, आदि) को देखते हुए, एक गलत परिणाम होता है (क्रैश, खराब आउटपुट, आदि)। उन मामलों के लिए, इसे अक्सर "वैज्ञानिक" सोच की आवश्यकता नहीं होती है। कुछ विचार खोज स्थान को कम करने में मदद कर सकते हैं, लेकिन एक सामान्य तरीका यह है कि कोड को डिबगर में रखा जाए और देखें कि चीजें कहां-कहां गड़ गईं।
हालांकि, परिस्थितियां, जो मुझे सबसे दिलचस्प लगती हैं और संभवतः एक वैज्ञानिक प्रक्रिया के योग्य हैं, जहां आपको कुछ अंतिम परिणाम दिए जाते हैं और यह बताने के लिए कहा जाता है कि यह कैसे हुआ। इसका एक स्पष्ट उदाहरण क्रैश डंप है। आप क्रैश डंप को लोड कर सकते हैं और सिस्टम की स्थिति का निरीक्षण कर सकते हैं और आपका काम यह बताना है कि यह उस राज्य में कैसे मिला। क्रैश (या कोर) डंप एक अपवाद, गतिरोध, आंतरिक त्रुटि या कुछ "अवांछनीय" स्थिति दिखा सकता है जैसा कि उपयोगकर्ता द्वारा परिभाषित किया गया है (उदाहरण के लिए, सुस्ती)। इन स्थितियों के लिए, मैं आमतौर पर इन पंक्तियों के साथ चरणों का पालन करता हूं:
संकीर्ण अवलोकन : यदि लागू हो तो सीधे विशिष्ट समस्या के बारे में अध्ययन करें। यहां स्पष्ट चीजें कॉल स्टैक हैं, स्थानीय चर यदि आप उन्हें देख सकते हैं, तो समस्या के आसपास कोड की लाइनें। इस प्रकार का विशिष्ट स्थान अध्ययन हमेशा लागू नहीं होता है। उदाहरण के लिए, "धीमी" प्रणाली का अध्ययन करने के लिए इस तरह का एक स्पष्ट प्रारंभिक स्थान नहीं हो सकता है, लेकिन एक दुर्घटना या आंतरिक त्रुटि स्थिति में ब्याज की तत्काल और स्पष्ट बिंदु होगा। यहां एक विशिष्ट कदम विंडबग जैसे उपकरण का उपयोग करना हो सकता है (एक लोडेड क्रैश डंप पर रन-एनालिसिस -v! और जो इसे बताता है उसे देखें)।
वाइड ऑब्जरवेशन : सिस्टम के अन्य हिस्सों का अध्ययन करें। सिस्टम में सभी थ्रेड्स की स्थिति की जांच करें, किसी भी वैश्विक जानकारी (उपयोगकर्ता / संचालन / आइटम, सक्रिय लेनदेन / प्रक्रिया / विगेट्स, आदि), सिस्टम (ओएस) की जानकारी आदि को देखें, यदि उपयोगकर्ता कोई बाहरी विवरण प्रदान करता है। , जो आपने देखा है उसके साथ संयोजन के बारे में सोचें। उदाहरण के लिए, यदि उन्होंने आपको बताया कि समस्या प्रत्येक मंगलवार दोपहर को होती है, तो अपने आप से पूछें कि इसका क्या मतलब हो सकता है।
परिकल्पना बनाना: यह वास्तव में मज़ेदार हिस्सा है (और मैं इसे लेकर मज़ेदार नहीं हूँ)। यह अक्सर रिवर्स में तार्किक सोच का एक बड़ा सौदा की आवश्यकता है। यह सोचना बहुत सुखद हो सकता है कि वर्तमान स्थिति में यह व्यवस्था कैसे हुई। मुझे संदेह है कि यह वह हिस्सा है जो बहुत से लोग एक कला के रूप में सोचते हैं। और मुझे लगता है कि यह हो सकता है कि प्रोग्रामर बस बेतरतीब ढंग से चीजों को फेंकना शुरू कर देता है यह देखने के लिए कि क्या चिपक जाता है। लेकिन अनुभव के साथ, यह एक काफी अच्छी तरह से परिभाषित प्रक्रिया हो सकती है। यदि आप इस बिंदु पर बहुत तार्किक रूप से सोचते हैं, तो अक्सर उन रास्तों के संभावित सेट को परिभाषित करना संभव है जो दिए गए राज्य का नेतृत्व करते हैं। मुझे पता है कि हम राज्य S5 में हैं। ऐसा होने के लिए, S4a या S4b को होने की जरूरत है और शायद S4a से पहले S3, आदि। अधिक बार ऐसा नहीं है, कई आइटम हो सकते हैं जो किसी दिए गए राज्य का नेतृत्व कर सकते हैं। कभी-कभी यह एक खरोंच पैड पर एक साधारण प्रवाह या राज्य आरेख या समय-संबंधित चरणों की एक श्रृंखला लिखने में मदद कर सकता है। इस स्थिति के आधार पर यहां वास्तविक प्रक्रियाएं बहुत भिन्न होंगी, लेकिन इस समय गंभीर विचार (और पिछले चरणों में पुन: परीक्षा) अक्सर एक या अधिक प्रशंसनीय उत्तर प्रदान करेगा। यह भी ध्यान दें कि इस कदम का एक अत्यंत महत्वपूर्ण हिस्सा उन चीजों को खत्म करना है जो असंभव हैं। असंभव को दूर करने से समाधान स्थान को ट्रिम करने में मदद मिल सकती है (याद रखें कि असंभव को खत्म करने के बाद शर्लक होम्स ने क्या कहा है। यह भी ध्यान दें कि इस कदम का एक अत्यंत महत्वपूर्ण हिस्सा उन चीजों को खत्म करना है जो असंभव हैं। असंभव को दूर करने से समाधान स्थान को ट्रिम करने में मदद मिल सकती है (याद रखें कि शर्लक होम्स ने असंभव को खत्म करने के बाद जो कुछ बचा है उसके बारे में कहा था)। यह भी ध्यान दें कि इस कदम का एक अत्यंत महत्वपूर्ण हिस्सा उन चीजों को खत्म करना है जो असंभव हैं। असंभव को दूर करने से समाधान स्थान को ट्रिम करने में मदद मिल सकती है (याद रखें कि असंभव को खत्म करने के बाद शर्लक होम्स ने क्या कहा है।
प्रयोग : इस चरण में, पिछले चरण में प्राप्त परिकल्पनाओं के आधार पर समस्या को पुन: उत्पन्न करने का प्रयास करें। यदि आपने पिछले चरण में गंभीर सोच रखी है, तो यह बहुत सीधा होना चाहिए। कभी-कभी मैं "धोखा" देता हूं और दिए गए परीक्षण में मदद करने के लिए कोड आधार को संशोधित करता हूं। उदाहरण के लिए, मैं हाल ही में एक दुर्घटना की जांच कर रहा था जो मैंने निष्कर्ष निकाला था कि एक दौड़ की स्थिति थी। इसे सत्यापित करने के लिए, मैंने कोड की कुछ पंक्तियों के बीच एक स्लीप (500) लगाई, ताकि "खराब" समय पर इसके खराब सामान को करने के लिए एक और धागा दिया जा सके। मुझे नहीं पता कि यह "वास्तविक" विज्ञान में अनुमति है, लेकिन यह कोड में पूरी तरह से उचित है जो आपके पास है।
यदि आप इसे पुन: प्रस्तुत करने में सफल होते हैं, तो संभावना है कि आप लगभग पूर्ण हो चुके हैं (जो कुछ बचा है वह इसे ठीक करने का सरल चरण है ... लेकिन यह एक और दिन के लिए है)। प्रतिगमन परीक्षण प्रणाली में नए परीक्षण की जाँच करना सुनिश्चित करें। और मुझे यह बताना चाहिए कि मैंने उस पिछले बयान को ठीक करने के बारे में कहा था कि यह जीभ-गाल होने के लिए सरल है। एक समाधान की खोज और इसे लागू करने के लिए व्यापक काम की आवश्यकता हो सकती है। यह मेरी राय है कि बग को ठीक करना डिबगिंग प्रक्रिया का हिस्सा नहीं है, बल्कि विकास है। और अगर यह सब शामिल है, तो इसके लिए डिजाइन और समीक्षा की कुछ मात्रा चाहिए।
परीक्षण के मामले को कम करने की कोशिश करें। जब यह पर्याप्त छोटा होता है तो आमतौर पर संबंधित कोड का पता लगाना आसान होता है जो समस्या पैदा कर रहा है।
यह संभावना है कि एक नया चेक-इन समस्या पैदा कर रहा है और पिछले दैनिक निर्माण ठीक था। उस स्थिति में स्रोत नियंत्रण से आपका परिवर्तन-लॉग आपको यह तय करने में मदद करेगा कि किसको पकड़ा जाए।
इसके अलावा, यदि आप C / C ++ में हैं, तो चल रहे वैग्राइंड पर विचार करें या मेमोरी से संबंधित मुद्दों को अलग करने के लिए शुद्ध करें।
डिबगिंग का सबसे कठिन हिस्सा समस्या को अलग कर रहा है, खासकर जब समस्या कई परतों के नीचे दबी हुई है। कॉलेज में मैंने संगीत रिकॉर्डिंग का अध्ययन किया, और अजीब तरह से एक स्टूडियो इलेक्ट्रॉनिक्स वर्ग था जो सीधे यहां लागू होता है। मैं स्टूडियो डिबगिंग को व्यवस्थित डिबगिंग प्रक्रिया के दृष्टांत के रूप में उपयोग करने जा रहा हूं।
डिबगिंग कोड वास्तव में इतना अलग नहीं है। डिबगिंग बहुत आसान है जब कोड एक अपवाद फेंक रहा है। आप उस अपवाद के स्टैक ट्रेस से पीछे की ओर ट्रेस कर सकते हैं और प्रमुख स्थानों पर ब्रेक पॉइंट सेट कर सकते हैं। आमतौर पर आपके द्वारा चर सेट करने के बाद, या उस विधि को कॉल करने वाली पंक्ति पर जो अपवाद को फेंकता है। आप पा सकते हैं कि एक या अधिक मूल्य सही नहीं हैं। यदि यह सही नहीं है (एक शून्य जब वहाँ नहीं होना चाहिए, या मूल्य सीमा से बाहर है), तो इसकी खोज की एक प्रक्रिया है कि यह सही क्यों है। एक आईडीई में ब्रेक पॉइंट इलेक्ट्रॉनिक टेस्ट पॉइंट (सर्किट की जांच के लिए मीटर की जांच के लिए डिज़ाइन किए गए) के बराबर हैं।
अब, एक बार जब मैं अपनी वास्तविक समस्या का पता लगाने के उस कठिन हिस्से से गुज़रा, तो मैं भविष्य में इसके लिए जाँच करने के लिए कुछ इकाई परीक्षण लिखूँगा।
अधिक व्यावहारिक aproach के लिए:
यदि बग एक अखंड अपवाद से संबंधित है - स्टैक ट्रेस देखें। अशक्त संदर्भ, सीमा से बाहर सूचकांक आदि और आपके स्वयं के परिभाषित अपवाद सबसे आम हैं, आप इस बग को कनिष्ठ देव को सौंप सकते हैं, शायद यह आसान और एक अच्छा सीखने की अवधि है।
यदि यह हर मशीन पर नहीं होता है, तो यह शायद रेस कंडीशन / थ्रेडिंग समस्या का एक रूप है। ये नीचे ट्रैक करने के लिए सुपर मजेदार हैं, अपने ऊब वरिष्ठ प्रोग्रामर को इस पर रखें। लॉगिंग, अच्छा ज्ञान और अच्छे टूल के बहुत सारे काम हो जाते हैं।
बग का एक और बड़ा वर्ग तब होता है जब परीक्षण टीम या क्लाइंट (एस) को एक विशेष व्यवहार पसंद नहीं होता है। उदाहरण के लिए, उन्हें यह पसंद नहीं है कि आप उपयोगकर्ता आईडी प्रदर्शित करने का निर्णय लेते हैं या खोजते समय आपको ऑटो-पूर्ण नहीं मिलता है। ये वास्तविक कीड़े हैं, बेहतर उत्पाद प्रबंधन और एक व्यापक दृष्टिकोण के साथ देवता पर विचार करें। यह एक डेवलपर को अपेक्षाकृत कम समय लेना चाहिए ताकि इसे "ठीक" किया जा सके यदि वह सिस्टम को विस्तार से ध्यान में रखता है।
अन्य सभी बगों का 80% एक अच्छा लॉगिंग सिस्टम होने और उन्हें हल करने के लिए पर्याप्त जानकारी एकत्र करके हल किया जाता है। Log4Net / Log4J जैसे जटिल लॉगिंग सिस्टम के कई स्तरों के साथ अंतर्निहित अनुरेखण का उपयोग करें
प्रदर्शन बग उनकी खुद की एक श्रेणी है, यहां गोल्डर नियम "पहले मापें, बाद में ठीक करें!", और आपको यह देखकर आश्चर्य होगा कि कितने देवता केवल अनुमान लगाते हैं कि समस्या कहां है और इसे देखने के लिए केवल इसे ठीक करने के लिए सही जाना बाद में प्रतिक्रिया समय में केवल 3-4% की कमी।
मेरे पास दो दृष्टिकोण हैं:
Divide and Conquerप्रतिमान के बाद प्रत्येक छोटे भागों को जीतें ।इस दृष्टिकोण ने मुझे सबसे अधिक बार मदद की है।