क्या कभी ऐसा हुआ है कि प्रोग्राम अजीब ढंग से चल रहा हो और आप घंटों कोड देखते रहने के बाद बगल में बैठे सहकर्मी से मदद माँगें? लेकिन हैरानी की बात है कि अक्सर “यहाँ यह मान लेते हैं, फिर इसे इस तरह आगे भेजते हैं…” समझाते हुए आप खुद ही “अरे, गलती तो यहाँ है” कहकर जवाब ढूँढ़ लेते हैं। जबकि सहकर्मी ने बस सिर हिलाया होता है। डेवलपरों के बीच इस अनुभव का जानबूझकर इस्तेमाल करने का तरीका बहुत पहले से प्रचलित है। यही है ‘रबर डक डिबगिंग (Rubber Duck Debugging)’।
सरल शब्दों में रबर डक डिबगिंग का अर्थ है ‘मेज़ पर रखी रबर की बतख को कोड की हर पंक्ति बोलकर समझाते हुए समस्या ढूँढ़ने की डिबगिंग विधि’। सुनने वाले को कुछ भी कहने की ज़रूरत नहीं होती, और समझाने की प्रक्रिया ही दिमाग में मौजूद गलत धारणाओं और कमियों को उजागर कर देती है।
इस लेख में हम क्रम से देखेंगे कि रबर डक डिबगिंग नाम कहाँ से आया, इसे व्यवहार में कैसे किया जाता है, समझाने से समस्या कैसे सामने आती है, और सॉफ़्टवेयर विकास से आगे दैनिक जीवन में इसका उपयोग कैसे किया जा सकता है।
बतख से बात करने पर बग क्यों नज़र आने लगते हैं
‘The Pragmatic Programmer’ में दर्ज किस्सा
यह नाम 1999 में प्रकाशित सॉफ़्टवेयर विकास की पुस्तक ‘द प्रैग्मैटिक प्रोग्रामर (The Pragmatic Programmer)’ से व्यापक रूप से प्रचलित हुआ। एंडी हंट (Andy Hunt) और डेव थॉमस (Dave Thomas) की सहलिखित यह पुस्तक आज भी एक क्लासिक मानी जाती है, जिसे कई डेवलपर पढ़ने की सलाह देते हैं।
- किस्से के मुख्य पात्र (Greg Pugh): पुस्तक के अनुसार, ग्रेग प्यू नाम के एक शोध सहायक हमेशा अपने साथ रबर की बतख रखते थे और किसी समस्या में अटकने पर उसे बतख को समझाते थे।
- पुस्तक में दिया गया विवरण (Explaining the Problem): इसमें बताया गया है कि सुनने वाले को एक शब्द भी कहने की ज़रूरत नहीं होती, और कोड को क्या करना चाहिए, यह क्रम से समझाने भर से अक्सर समस्या स्क्रीन पर अपने आप उभर आती है।
- अलग-अलग रूप (Other Objects): बतख होना ज़रूरी नहीं है; टेडी बियर या पालतू जानवर, यहाँ तक कि कागज़ काटकर बनाई गई कुत्ते की आकृति को समझाने के किस्से भी सुनने को मिलते हैं।
आखिरकार, मुख्य बात बतख नाम की वस्तु नहीं, बल्कि किसी को शुरू से अंत तक समझाने का काम है।
हर पंक्ति बोलकर समझाने का तरीका
रबर डक डिबगिंग का तरीका सरल है, इसलिए इसके क्रम का पालन करना महत्वपूर्ण है। मोटे तौर पर इसे निम्न तीन चरणों में किया जाता है।
(1) पहले बतख को लक्ष्य बताएँ
सबसे पहले एक-दो वाक्यों में समझाएँ कि इस कोड को मूल रूप से क्या करना चाहिए। लक्ष्य को शब्दों में स्पष्ट करते ही कभी-कभी पता चलता है कि आपने शुरू से ही आवश्यकताओं को गलत समझा था।
(2) कोई पंक्ति छोड़े बिना एक-एक पंक्ति पढ़ें
कोड को ऊपर से एक-एक पंक्ति पढ़ें और बोलकर बताएँ कि यह पंक्ति क्या करती है तथा चर में कौन-सा मान होगा। “यह तो ज़रूर ठीक चल रहा होगा” सोचकर जिन हिस्सों को आप छोड़ देते थे, उन सभी को समझाना इस विधि का मुख्य आधार है।
(3) कही गई बात और वास्तविक परिणाम की तुलना करें
वह जगह खोजें जहाँ आपके समझाए गए विवरण और प्रोग्राम के वास्तविक परिणाम में अंतर आता है। आम तौर पर वही असंगत पंक्ति बग के छिपे होने की जगह होती है।
इस दौरान केवल मन में पढ़ने के बजाय वास्तव में मुँह से बोलना अच्छा है, और यदि यह कठिन हो तो वाक्यों में लिखकर देखें। बोलने पर गति स्वाभाविक रूप से धीमी हो जाती है, जिससे आप उस एक अल्पविराम या असमानता चिह्न की दिशा तक दोबारा जाँचने लगते हैं, जिसे नज़र दौड़ाते समय छोड़ देते थे। दफ़्तर जैसी जगहों पर, जहाँ बोलना मुश्किल हो, नोटपैड में समझाते हुए लिखते जाने से भी वही प्रभाव मिलता है।
बतख ऐसा श्रोता है जो कुछ न जानने का अभिनय करते हुए आपकी बात सुनता है। इसलिए यह मानकर कि सामने वाले को कुछ भी नहीं पता, आप जितनी सरल भाषा में विस्तार से समझाएँगे, उतना ही अधिक असर होगा।
समझाने से समस्या कैसे सामने आती है
जब हम केवल मन में सोचते हैं, तो उन हिस्सों को अपने आप छोड़ देते हैं जिन्हें हम पहले से समझने का विश्वास रखते हैं। लेकिन बोलकर समझाने के लिए विचारों को एक-एक करके क्रम से सामने रखना पड़ता है।
- कमियाँ उजागर करना (Explicit Reasoning): बोलना सोचने से धीमा होता है और उसका क्रम स्पष्ट होता है, इसलिए मन में जैसे-तैसे जोड़े गए तर्क की खाली जगहें साफ़ दिखाई देने लगती हैं।
- दृष्टिकोण बदलना (Shift in Perspective): किसी और को समझाने की स्थिति में आने पर आप कोड को उसके लेखक की बजाय पहली बार देखने वाले व्यक्ति की नज़र से दोबारा देखते हैं।
- स्व-व्याख्या प्रभाव (Self-Explanation Effect): अधिगम विज्ञान में लगातार ऐसे शोध सामने आए हैं जिनके अनुसार सीखी गई बातों को स्वयं समझाने वाले विद्यार्थी अपनी समझ को अधिक गहराई से पुख्ता करते हैं।
खास तौर पर बग अक्सर कोड के गलत हिस्सों से अधिक उन जगहों पर छिपे होते हैं जिनके बारे में हमें विश्वास होता है कि ‘यह गलत हो ही नहीं सकता’। समझाते समय उस विश्वास का आधार बताना पड़ता है, और जिस क्षण हम उसका आधार नहीं बता पाते, वही जगह दोबारा देखने लायक होती है।
यह भी दिलचस्प है कि अकेले बुदबुदाने की तुलना में किसी सुनने वाले के मौजूद होने पर यह बेहतर काम करता है। सामने बतख ही क्यों न हो, उसे रखने से ठीक तरह से समझाने का भाव पैदा होता है और हम कुछ छोड़े बिना अपनी बात कहते हैं।
सॉफ़्टवेयर विकास से आगे दैनिक जीवन में उपयोग
रबर डक डिबगिंग अब डेवलपर संस्कृति के एक प्रतीक के रूप में स्थापित हो गई है। हार्वर्ड विश्वविद्यालय के कंप्यूटर विज्ञान के परिचयात्मक पाठ्यक्रम CS50 ने अपने शिक्षण उपकरणों में बतख का एक पात्र शामिल किया, और सवाल-जवाब वाली साइट स्टैक ओवरफ़्लो (Stack Overflow) ने 2018 में अप्रैल फूल दिवस पर उपयोगकर्ताओं के सवाल सुनकर केवल “क्वैक” की आवाज़ निकालने वाली बतख दिखाकर लोगों को हँसाया भी था।
यह तरीका कोड से इतर समस्याओं पर भी वैसे ही इस्तेमाल किया जा सकता है। रिपोर्ट का तर्क उलझ जाए, गणित का प्रश्न हल करते समय आप अटक जाएँ, या प्रस्तुति की बातें सहज ढंग से न जुड़ रही हों, तो सामने खाली कुर्सी या खिलौना रखकर शुरू से समझाने पर अटकाव की जगह स्पष्ट हो जाती है। सहकर्मी को सवाल भेजने से पहले बतख को समझाने पर अक्सर खुद ही जवाब मिल जाता है, और जवाब न भी मिले तो सवाल कहीं अधिक स्पष्ट हो जाता है।
कुछ गलतियाँ बोलकर सामने रखने पर ही दिखाई देती हैं। जिस समस्या में आप अटके हैं, उसे बतख को क्रम से समझाने की आदत अपने दम पर जवाब खोजने वाली समस्या-समाधान प्रक्रिया का पहला कदम है।
