डिबगिंग के सिद्धांत

• डिबगिंग वास्तव में डेवलपर की अनिवार्य क्षमताओं में से एक है
• डिबगिंग में समस्या तक कैसे पहुँचना है, यह mindset महत्वपूर्ण है
• डिबगिंग वह प्रक्रिया है जिसमें दी गई स्थिति और डेटा के आधार पर समस्या के कारण को खोजा जाता है
  • लेखक इसे intuition के रूप में व्यक्त करता है
  • intuition का मतलब है जो ज्ञान मुझे है, उसे समस्या से जोड़ना
  • अनुभव उस shortcut की तरह काम करता है जो ज्ञान को intuition से जोड़ देता है
• डेवलपर, अप्रत्याशित व्यवहार के कारण को खोजने के लिए, सहज रूप से संभावनाओं को संकीर्ण करते जाते हैं
• लेखक का मानना है कि सिद्धांतों के साथ एक-एक करके दायरा संकीर्ण करना अधिक प्रभावी है
• समस्या खोजने के लिए चार चरण प्रस्तुत किए गए हैं
  • पहला, संदेह करना
    • कोड, लॉग, एरर संदेश, मॉनिटरिंग डेटा, requirements, hardware आदि—सब कुछ समस्या समाधान के लिए जानकारी इकट्ठा करने का साधन है
    • checklist बनाना अच्छा रहता है
  • दूसरा, वर्गीकृत करना
    • इकट्ठा की गई जानकारी में जो पता है और जो ठीक से पता नहीं है, उन्हें अलग करें
    • जानकारी इकट्ठा करने के चरण में जो जानकारी तुरंत छँट जाती है, वह छोटी intuition के कारण होती है
    • लेखक इसे चार भागों में बाँटता है: logical defect, dependency technology defect, foundational technology defect, और physical defect
  • तीसरा, सीखना
    • इकट्ठा की गई जानकारी के आधार पर ज्ञान की कमी खोजें और उसे सीखें
  • चौथा, जोड़ना
    • जानकारी के आधार पर समस्या के बारे में hypothesis बनाएं और उसका प्रयोग करें
    • इस प्रक्रिया में यदि नई insight मिले, तो फिर से इन चार चरणों के feedback loop का उपयोग करें
• ऊपर बताए गए तरीके, पहले उल्लेख की गई intuition का अभ्यास करने के लिए उपयोगी हैं
• अगर आपके अपने डिबगिंग सिद्धांत नहीं हैं, तो इस लेख के आधार पर उन्हें बना सकते हैं, या नए सिरे से भी बना सकते हैं। यदि आप अच्छे tips साझा करें, तो और भी बेहतर है

[cosine20]

लेखक का मानना है कि सिद्धांतों के साथ एक-एक करके दायरा संकुचित करना अधिक प्रभावी है

मैं इससे बहुत गहराई से सहमत हूँ। और लगता है कि आपने debugging के बारे में एक सामान्य दृष्टिकोण को अच्छी तरह व्यवस्थित करके प्रस्तुत किया है.

वास्तव में debugging की प्रक्रिया में बहुत तरह के कारण और पृष्ठभूमि-ज्ञान जटिल रूप से एक-दूसरे से जुड़े होते हैं, इसलिए उनमें से ज़रूरी संकेत खोजने के लिए focus को धीरे-धीरे संकुचित करने की प्रक्रिया सचमुच बहुत महत्वपूर्ण है।
लेख में कहा गया है कि ऐसी प्रक्रिया में intuition और insight को निखारना चाहिए, और ऐसा लगता है कि सहज रूप से यह पकड़ने में कि कारण कहाँ है और जाँच किस बिंदु को केंद्र में रखकर शुरू करनी चाहिए, अनुभव और समझ से तराशी हुई intuition की यहाँ बहुत बड़ी भूमिका होती है.

[kciter1]

सहमत हूँ। मैं आपकी बताई गई भावना को अच्छी तरह व्यक्त करना चाहता था, लेकिन अब लगता है कि पूरे लेख में 직관 की जगह 통찰력 शब्द का इस्तेमाल करके एकरूपता रखना बेहतर होगा।

[halfenif]

ऐसा लगता है कि कुछ लोग तर्क से डिबग कर लेते हैं और कुछ लोग नहीं कर पाते।

शायद यह करीब 30 साल पहले की बात है।

सीनियर लोग कहा करते थे कि IT में लगभग 3 साल काम कर लो, तो सबकी क्षमता लगभग एक जैसी हो जाती है।

अब सोचता हूँ तो ....

[savvykang]

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

बाकी suspicion, classification, और learning के बारे में मैं सहमत हूँ, क्योंकि मैंने अनुभव किया है कि जैसे-जैसे अनुभव और background knowledge जमा होते हैं, ये बेहतर होते जाते हैं।

[savvykang]

मैंने लेख को एक बार फिर पढ़कर यह बात जोड़ रहा/रही हूँ

ऐसा लगता है कि लेखक जिस intuition की परिभाषा दे रहे हैं, वह समाज में आम तौर पर प्रचलित intuition की परिभाषा से अलग है। मेरी समझ में intuition की सामान्य परिभाषा यह है कि बिना किसी विचार-प्रक्रिया के समस्या को समझ लेना। लेख पढ़ते-पढ़ते मुझे एक पल के लिए लगा कि कहीं मैं intuition का अर्थ ही गलत तो नहीं समझ रहा/रही, इसलिए मैंने फिर से जाकर इसकी पुष्टि की। मुझे यह भी लगता है कि यह debugging में विचार की प्रक्रिया आवश्यक होने वाली पूरे लेख की मुख्य दलील से भी मेल नहीं खाता। अगर debugging सचमुच पूरी तरह intuition से की जा सकने वाली प्रक्रिया है, तो क्या यह दावा भी सही नहीं होना चाहिए कि debugging करते समय logs या data की जाँच, configuration management बिल्कुल भी आवश्यक नहीं है?

[kciter1]

नमस्ते। मेरी पोस्ट में रुचि लेने के लिए धन्यवाद।

जैसा आपने कहा, सामान्यतः intuition का मतलब बिना किसी प्रत्यक्ष सोच-विचार की प्रक्रिया के किसी चीज़ को समझ लेना होता है। लेकिन मेरा यह भी मानना है कि बिल्कुल बिना किसी ज्ञान के सही उत्तर तक पहुँचना संभव नहीं है।

पहले intuition शब्द के बारे में अपनी सोच बताऊँ तो, debugging की बात करते समय हम अक्सर सहकर्मियों से या खुद से ऐसी बातें सुनते हैं जैसे 'अचानक दिमाग में आया', 'किसी वजह से लगा कि दिक्कत उसी हिस्से में है'। मैंने इसी हिस्से को intuition माना था। जब उस अचानक आए विचार को यूँ ही नज़रअंदाज़ न करके एक-एक करके जाँचा, तो अंत में यह समझ आया कि उस हिस्से से जुड़ा पहले का अनुभव था या संबंधित ज्ञान अच्छी तरह समझा हुआ था। इसलिए मैंने intuition शब्द का उपयोग किया, और क्योंकि इससे गलतफ़हमी हो सकती थी, मैंने यह वाक्य भी जोड़ा: 'मैं जो ज्ञान जानता हूँ, उसे समस्या से जोड़ना ही intuition है।'

इसलिए, आपने जो कुछ प्रश्न उठाए, उन पर अपनी राय कहूँ तो,
'यह debugging में सोच की प्रक्रिया की आवश्यकता वाले पूरे तर्क से भी विरोधाभासी है' इस बिंदु पर, मैंने लेख में intuition को ऐसी चीज़ के रूप में व्यक्त किया था जहाँ पहले से अनुभव की हुई या ज्ञात बातों के कारण बड़े सोच-विचार के कुछ हिस्से छोड़े जा सकते हैं। इसलिए मेरा मतलब यह नहीं था कि सोचने की प्रक्रिया की ज़रूरत ही नहीं है, बल्कि मैं इसे सोच को तेज़ी से करने वाले एक उपकरण की तरह व्यक्त करना चाहता था.

अगला, 'अगर debugging सचमुच पूरी तरह intuition से किया जा सकने वाला काम है, तो क्या यह दावा भी सही नहीं होना चाहिए कि debugging के समय logs या data की जाँच, version control की बिल्कुल ज़रूरत नहीं है?' — इस बारे में मैंने यह नहीं कहा था कि इसे पूरी तरह intuition से किया जा सकता है। बल्कि मैंने उल्टा यह वाक्य जोड़ा: 'debugging वह प्रक्रिया है जिसमें दी गई स्थिति और data के आधार पर समस्या के कारण को खोजा जाता है।' हालाँकि, मेरा मानना है कि हर debugging के समय लेख में बताए गए चार-चरणीय inference process से गुजरने वाले developers लगभग नहीं के बराबर होंगे। कुछ अनुभव और ज्ञान होने पर लोग अपने निर्णय से कुछ चरण छोड़ भी सकते हैं। आपने जिन logs, data आदि का ज़िक्र किया, मेरे विचार में अनुभव या ज्ञान होने पर वे उन्हें याद दिलाने का काम करते हैं, और अगर अनुभव या ज्ञान न हो तो inference में मदद करते हैं। इसलिए, लेख में जिस intuition का उल्लेख है, उसके लिए भी ये ऐसी महत्वपूर्ण जानकारी हैं जिनके बिना काम नहीं चल सकता।

मुझे लगता है कि इस लेख में इस्तेमाल किया गया intuition शब्द अपने आप में अस्पष्ट हो सकता है। शायद मेरी सोच को व्यक्त करने के लिए लेख की संरचना या buildup उतना अच्छा नहीं रहा होगा। फिलहाल जो हिस्से पर्याप्त ठोस नहीं थे, उन्हें मैं संशोधित करना चाहता हूँ। लेकिन intuition शब्द को बदलना बेहतर होगा या नहीं, इस पर अभी भी मैं निश्चित नहीं हूँ। क्योंकि लिखते समय से ही मैंने intuition शब्द को मुख्य अवधारणा माना था, इसलिए उसके बदले कोई दूसरा शब्द सूझ नहीं रहा। अगर आपके पास कोई अच्छा सुझाव हो, तो कृपया बताइएगा। :)

[savvykang]

मेरा मानना है कि अगर प्रस्तावना में यह पृष्ठभूमि जोड़ी जाए कि debugging में intuition और reasoning दोनों की ज़रूरत होती है, और मुख्य भाग में समस्या खोजने के तरीकों तथा intuition/reasoning के संबंध को जोड़ा जाए, तो लेख की पूर्णता बेहतर हो सकती है.

बदलाव से पहले

1. debugging दी गई स्थिति और डेटा के आधार पर समस्या के कारण को खोजने की प्रक्रिया है
2. debugging के ज़रिए समस्या समाधान आमतौर पर developer की intuition से निकलता है
3. समस्या खोजने के लिए चार चरण मौजूद हैं

बदलाव के बाद

प्रस्तावना

1. debugging दी गई स्थिति और डेटा के आधार पर समस्या के कारण को खोजने की प्रक्रिया है
2. debugging में क्रमवार दो उप-कार्य आवश्यक होते हैं: समस्या की पहचान और समस्या का समाधान
3. समस्या की पहचान में intuition, और समस्या समाधान में reasoning काम करती है. इसे समर्थन देने वाला सिद्धांत dual process theory है
4. यदि समस्या की पहचान की प्रक्रिया में केवल reasoning का उपयोग किया जाए, तो system की संरचना जैसी तकनीकी बारीकियों को एक-एक करके जांचना और सत्यापित करना पड़ता है, जिससे productivity बढ़ाने में सीमाएँ आती हैं. इसके बजाय समस्या पहचान की प्रक्रिया में intuition का सहायक रूप से उपयोग करना debugging रणनीति के लिए अधिक लाभदायक है
5. intuition की प्रभावशीलता बढ़ाने के लिए सामान्य रूप से अनुभव और अंतर्दृष्टि, यानी heuristic, का संचय करना महत्वपूर्ण है.
6. intuition के गलत होने या स्थिति के अनुरूप न होने की संभावना हमेशा रहती है, और cognitive bias से बाहर निकलने का अभ्यास भी महत्वपूर्ण है

मुख्य भाग (debugging प्रक्रिया)

1. जानकारी एकत्र करना
2. वर्गीकरण - यहाँ intuition और heuristic काम करते हैं
3. सीखना
4. hypothesis बनाना और सत्यापित करना - यहाँ reasoning काम करती है