प्रो डिबगर कैसे बनें

एक डेवलपर होने का मतलब है कि आधे से अधिक समय आपको डिबगर होना पड़ता है, कभी-कभी अपने कोड के लिए, और कभी-कभी कोड समीक्षा में या जोड़ी प्रोग्रामिंग के मामले में अपने साथियों की मदद करने के लिए। डेवलपर्स के लिए एक आवश्यक कौशल होने के बावजूद, डिबगिंग ऐसा कुछ नहीं है जो किसी को उनके करियर में किसी भी समय सिखाया जाता है, जिससे यह विश्वास होता है कि यह बहुत मुश्किल है।

डिबगिंग मुश्किल लगता है, इसके यांत्रिकी के कारण नहीं, बल्कि इसलिए कि यह समझना मुश्किल है कि नौसिखिए के रूप में कहां से शुरू किया जाए। बिना किसी संदेह के, यह एक कला है जिसे समय के साथ अधिक से अधिक कोड बनाकर और समीक्षा करके हासिल किया जा सकता है, लेकिन कुछ सिफारिशों के साथ अंतर्ज्ञान को जल्दी विकसित किया जा सकता है, जिस पर हम आज इस लेख में चर्चा करेंगे।

आएँ शुरू करें।

समस्या का पुनरुत्पादन

किसी भी समस्या को डीबग करते समय सबसे खराब स्थिति तब होती है जब बग को विश्वसनीय रूप से पुन: उत्पन्न नहीं किया जा सकता है। दौड़ की स्थिति, बाहरी सिस्टम, या पर्यावरणीय मुद्दों जैसे कई कारकों के कारण ठग हो सकता है जो तैनात सिस्टम या डेवलपर स्टेज बॉक्स पर अलग-अलग व्यवहार पैटर्न की ओर ले जाते हैं।

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

किसी समस्या को पुन: उत्पन्न करने के चरणों का वर्णन करते समय पालन करने के लिए यहां कुछ सरल युक्तियां दी गई हैं:

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

समस्या को स्वचालित परीक्षण में बदलें

यह कदम हमेशा संभव नहीं होता है; और कभी-कभी यह संभव है लेकिन व्यावहारिक नहीं है या वास्तव में आवश्यक नहीं है, हालांकि, ऐसे मामले भी हो सकते हैं जहां इसे लागू करने लायक है। स्वचालित परीक्षण, इस संदर्भ में, कुछ भी हो सकता है जो आपका विकास उपयोग मामला पहले से ही परीक्षण के लिए उपयोग कर रहा है जैसे इकाई परीक्षण, या एकीकरण परीक्षण। जहां भी संभव हो, यूनिट परीक्षण एक उत्कृष्ट विकल्प है क्योंकि उन्हें अक्सर प्रदर्शन करने के लिए डिज़ाइन किया गया है, इसलिए आपको पता चल जाएगा कि समस्या जल्द ही वापस आती है या नहीं।

आप स्वयं को कई इकाई परीक्षण लिखते हुए पा सकते हैं जो समस्या के स्रोत की पहचान करने का प्रयास करते समय पास हो जाएंगे। आप कभी-कभी खुद को यूनिट परीक्षण लिखते हुए भी पा सकते हैं जो वर्तमान स्थिति के बाहर कोई मतलब नहीं रखते हैं, लेकिन फिर भी, एक परीक्षण होने में कोई हानि नहीं है जो आपको समस्या के स्रोत को इंगित करने में मदद कर सकता है। सिर्फ इसलिए कि यह वर्तमान समस्या नहीं है इसका मतलब यह नहीं है कि इसे बाद में नहीं मिलेगा - और यह कोड के व्यवहार के तरीके के बारे में अधिक दस्तावेज के रूप में भी कार्य करता है। सिस्टम के अंदर कौन सी परत समस्या पैदा कर रही है, यह निर्धारित करने के लिए कार्य इकाई परीक्षण अक्सर एक उत्कृष्ट दृष्टिकोण होता है।

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

यहां तक कि अगर आपको कोई समस्या जल्दी मिलती है और इसे एक ही पंक्ति में हल कर सकते हैं, तो जहां भी संभव हो, इसे सत्यापित करने के लिए एक इकाई परीक्षण बनाएं। कोड को सही करते समय गलतियाँ करना उतना ही सरल है जितना कि इसे पहले स्थान पर विकसित करना, और परीक्षण-प्रथम सिद्धांत अभी भी लागू होते हैं।

यह उम्मीद न करें कि चीजें वैसी ही काम करेंगी जैसी उन्हें करनी चाहिए

यदि आप अपने आप को स्पष्ट रूप से जारी रखने के लिए किसी भी मुद्दे को डीबग कर रहे हैं तो आपको थोड़ा पागल होना होगा क्योंकि कहीं कुछ काम नहीं कर रहा है, अन्यथा कोई समस्या नहीं होगी। आपको इस बारे में खुले विचारों वाला होना चाहिए कि समस्या कहां हो सकती है, और इसमें शामिल सिस्टम के बारे में अपने ज्ञान के साथ नेविगेट करें।

यहां प्रमुख लक्ष्य आपको यह दावा करने से रोकना है, "समस्या वहां नहीं हो सकती।" विश्वास न हो तो सिद्ध करो। यदि यह प्रतीत होता है, चाहे वह कितना भी असंभव क्यों न हो, इसमें और अधिक खुदाई करें।

कोड के उद्देश्य के बारे में स्पष्ट रहें

यदि किसी कोड का उद्देश्य आपके लिए अस्पष्ट है, भले ही वह समस्या का कारण हो या न हो, इसे समझने के लिए कुछ समय दें। आप हमेशा इसके चारों ओर कुछ परीक्षण कर सकते हैं, और यह दस्तावेज करने का प्रयास कर सकते हैं कि यह क्या करता है। यदि आप सुनिश्चित नहीं हैं कि व्यवहार सही है या नहीं, तो मदद मांगें। एक बार जब यह स्पष्ट हो जाए, तो आप जो कुछ भी जानते हैं उसे दस्तावेज करने का प्रयास करें, चाहे परीक्षण, एक्सएमएल दस्तावेज या किसी बाहरी दस्तावेज़ के साथ।

एक समय में एक समस्या को ठीक करें

यदि कोड का एक टुकड़ा असाधारण रूप से खराब है, तो आप मूल को डीबग करते समय अन्य मुद्दों की खोज कर सकते हैं। ऐसे उदाहरण में, यह तय करना महत्वपूर्ण है कि पहले किस समस्या से निपटना है और फिर केवल उस समस्या पर ध्यान केंद्रित करना है।

एक आदर्श दुनिया में, आप एक समस्या को हल करेंगे, अपने कोड को संस्करण नियंत्रण में सत्यापित करेंगे, फिर अगले को ठीक करेंगे, और इसी तरह। इससे यह निर्धारित करना आसान हो जाता है कि कोड में कौन से परिवर्तन के कारण बाद में व्यवहार में कौन से परिवर्तन हुए, जो महत्वपूर्ण है जब एक समस्या का समाधान कुछ और तोड़ देता है।

अपने कोड को डिबग करने में मदद करें

डिबगिंग में लॉग अविश्वसनीय रूप से उपयोगी हो सकते हैं। वे आपको उस जमीन से जानकारी दे सकते हैं जहां डिबगर्स सहायक नहीं हो सकते हैं। हालाँकि, लॉगिंग, डिबगिंग की तरह, एक सावधान कला भी है। यदि आप इसे सही तरीके से नहीं करते हैं, तो हो सकता है कि यह आपकी सर्वोत्तम तरीके से मदद करने में सक्षम न हो। इसलिए, जब भी कोड में कोई अपवाद फेंका जाता है, तो इसे न केवल अपवाद के संदेश को लॉग करने के लिए बल्कि स्टैक ट्रेस को भी एक बिंदु बनाएं।

अपवादों को अनिवार्य रूप से लॉग किए बिना चुपचाप निगलना नहीं चाहिए। वे कभी-कभी उपयोगकर्ता इनपुट या कॉन्फ़िगरेशन सेटिंग्स को सत्यापित करने का सबसे आसान तरीका हो सकते हैं। इन स्थितियों में, लॉगिंग वास्तव में आपका मित्र हो सकता है।

इसी तरह, अपने कोड को खराब इनपुट के लिए प्रतिरोधी बनाएं। जितनी जल्दी खराब इनपुट का पता लगाया जाता है, समस्या का पता लगाना उतना ही आसान होता है। किसी समस्या की जड़ को ट्रैक करना मुश्किल हो सकता है यदि आप कई तरीकों से किसी मूल्य को संभालने के बाद ही उम्मीद प्राप्त करते हैं। अनुबंध यहां की बाधाओं को परिभाषित करने में सहायक हो सकते हैं, अन्यथा, आपको सतर्क रहना चाहिए और भविष्य में किसी समस्या पर संदेह होने पर सत्यापन जोड़ना चाहिए।

अपने डीबगर के बारे में जानें

जैसे एक जेडी अपने लाइट सेबर के बिना महान नहीं हो सकता, आप अपने डिबगर की क्षमताओं के बारे में जाने बिना एक महान डेवलपर नहीं हो सकते। आधुनिक डिबगर्स में बहुत सी विशेषताएं होती हैं जिनका अधिकतर उपयोग नहीं किया जाता है क्योंकि डेवलपर्स उनसे अनजान हैं। उदाहरण के लिए, सशर्त ब्रेकप्वाइंट या डेटा संरचनाओं का उपयोगकर्ता-परिभाषित प्रतिनिधित्व एक डिबगिंग सत्र के बीच अंतर कर सकता है जो पूरे दिन तक चलता है या जो सिर्फ 10 मिनट तक चलता है।

आपको दिल से सब कुछ जानने की जरूरत नहीं है, लेकिन आपका डिबगर क्या करने में सक्षम है, इसका एक अच्छा विचार है, और बुनियादी कार्यों जैसे कि स्टेप ओवर, स्टेप इन, सेट ब्रेकपॉइंट और फिर से शुरू निष्पादन के लिए शामिल शॉर्टकट कुंजियों का एक अच्छा ज्ञान महत्वपूर्ण है। .

लोगों को शामिल करें

डिबगिंग मुश्किल है क्योंकि इससे मनोबल गिर सकता है, और कोड की खराब प्रलेखित भूलभुलैया के साथ काम करने से जल्दी से शारीरिक थकावट हो सकती है। इस पर विचार करें: यदि आप फंस गए हैं, तो ब्रेक लें, टहलने जाएं, कॉफी खाएं, चॉकलेट बार - जो भी आपकी मदद करे।

यदि आपको किसी और को शामिल करने की आवश्यकता है तो शर्मिंदा न हों - यदि कोड का व्यवहार असंभव प्रतीत होता है, या यदि आप नहीं जानते कि कहां देखना है, तो पूछें। दूसरे व्यक्ति क्या कर रहा है, उस पर नज़र रखें, दोनों उनसे सीखें और उन्हें चेतावनी दें कि क्या वे किसी अंधी गली में जा रहे हैं जिसे आपने पहले देखा है। उन्हें बताएं कि आपने क्या देखा, और आप क्या सोचते हैं, एक चर्चा एक संकेत ला सकती है।

END . का परीक्षण करें

जब आपको लगता है कि आपने समस्या का समाधान कर लिया है, तो इसका परीक्षण करने के लिए हर संभव प्रयास करें (कारण के भीतर)। जाहिर है, यूनिट परीक्षण आपके कॉल का पहला पोर्ट होना चाहिए - समस्या को अलग करने के लिए आपके द्वारा पेश किए गए यूनिट परीक्षण अब पास होने चाहिए, लेकिन अन्य सभी परीक्षणों को भी करना चाहिए।

एक उच्च-स्तरीय समस्या अक्सर कई निम्न-स्तरीय समस्याओं के कारण होती है - पहले निम्न-स्तरीय समस्या को खोजना, उसे ठीक करना, और फिर मान लेना कि उच्च-स्तरीय समस्या दूर हो जाएगी, आसान है। कभी-कभी इसके विपरीत होता है: अधिक महत्वपूर्ण निम्न-स्तरीय समस्या के परिणामस्वरूप उच्च-स्तरीय व्यवहार बिगड़ जाता है। उस स्थिति में, आपको फिक्सिंग और तब तक परीक्षण करते रहना होगा जब तक कि आप यह न देख लें कि सब कुछ ठीक से काम कर रहा है।

संभावित त्रुटियों के लिए ऑडिट

समस्याएँ अक्सर समूहों में होती हैं। उदाहरण के लिए, यदि आप पाते हैं कि कोई व्यक्ति एक उदाहरण में उपयोगकर्ता इनपुट पर पर्याप्त एस्केपिंग/एन्कोडिंग करना भूल गया है, तो वही समस्या दूसरे में उत्पन्न हो सकती है। प्रत्येक मुद्दे को एक अलग समस्या के रूप में उठाने की तुलना में संभावित समस्याओं का एक साथ तेजी से ऑडिट चलाने के लिए यह काफी कम खर्चीला है, हो सकता है कि अन्य इंजीनियरों को उसी जांच में शामिल किया जाए जो आपने अभी-अभी पूरी की है।

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

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

निष्कर्ष

ये अनुशंसाएं आपको एक या दो दिन में एक प्रो डिबगर नहीं बना सकती हैं, लेकिन अगर धैर्य और अच्छे अभ्यास के साथ पालन किया जाए तो यह निश्चित रूप से आपको सही दिशा में आरंभ करने में मदद करेगी। उच्च गुणवत्ता वाला कोड दुर्घटनावश नहीं होता - इसमें धैर्य और सटीकता की आवश्यकता होती है।

इस लेख के लिए बस इतना ही। मुझे बताएं कि आप डिबगिंग के लिए उपरोक्त युक्तियों के बारे में क्या सोचते हैं और नीचे टिप्पणी में प्रो डिबगर बनने के लिए अपना दृष्टिकोण, टिप्स और ट्रिक्स जोड़ने के लिए स्वतंत्र महसूस करें।

पढ़ते रहिये!