वह कोड लिखें जिसे हटाना और डीबग करना आसान है

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

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

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

नियम 0: अच्छे कोड में स्पष्ट त्रुटियां हैं।

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

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

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

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

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

नियम 1: कंप्यूटर में हमेशा समस्याएं होती हैं

कंप्यूटर में समस्याएं हैं और अंतिम रन के दौरान प्रोग्राम क्रैश हो गया।

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

उदाहरण के लिए, जब किसी फ़ाइल को पढ़ने या लिखने की स्थिति होती है, तो निम्न समस्याएं हो सकती हैं:

• फाइल गायब है।
• फ़ाइल दूषित है।
• एक पुराने संस्करण की फ़ाइल, या नया।
• फ़ाइल में अंतिम परिवर्तन पूरा नहीं हुआ है।
• फाइल सिस्टम आपके पास पड़ा हुआ है।

ये समस्याएँ नई नहीं हैं; प्राचीन काल से ही इनका सामना किया गया है (1970-01-01)। SQLite जैसी किसी चीज़ का उपयोग करने से कई समान परेशानियों का सामना करने में मदद मिलेगी, लेकिन यदि प्रोग्राम अंतिम निष्पादन में दुर्घटनाग्रस्त हो गया, तो कोड गलत डेटा और / या गलत तरीके से काम कर सकता है।

उदाहरण के लिए, अनुसूचित कार्यक्रमों के साथ, इस सूची में से कुछ होगा:

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

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

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

कोड जो डीबग करना आसान है:

• एक कोड जो यह देखने के लिए जांचता है कि क्या वे इसके लिए पूछने से पहले सब कुछ ठीक है;
• कोड जो एक प्रसिद्ध राज्य में वापस जाना और फिर से प्रयास करना आसान बनाता है;
• साथ ही सुरक्षा स्तरों के साथ कोड जो त्रुटियों को जितनी जल्दी हो सके।

नियम 2: आपका कार्यक्रम खुद से लड़ता है

Google के इतिहास में सबसे बड़ा DoS हमला खुद से हुआ (क्योंकि हमारे सिस्टम बहुत बड़े हैं)। हालाँकि समय-समय पर कोई हमें ताकत के लिए परखने की कोशिश करता है, लेकिन फिर भी हम दूसरों की तुलना में खुद को नुकसान पहुँचा सकते हैं।

यह हमारी सभी प्रणालियों पर लागू होता है।

एस्ट्रिड एटकिंसन, लॉन्ग गेम इंजीनियर

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

बड़ी कठिनाई भी सिस्टम की जाँच का कारण बन सकती है।

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

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

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

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

नियम 3: यदि आप अभी कुछ अस्पष्ट छोड़ते हैं, तो आपको इसे बाद में डिबग करना होगा

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

इसका मतलब यह भी है कि आपको अर्ध-विधेय समस्या से सावधानीपूर्वक बचने की आवश्यकता है, मूल्यों की एक जोड़ी ( boolean , count ) का प्रतिनिधित्व करने के लिए कभी भी एक मान ( count ) का उपयोग न करें। परिणाम के लिए एक सकारात्मक संख्या लौटने से बचने के लिए आवश्यक है और एक ही समय में वापसी -1 अगर कुछ भी मेल नहीं खाता है। तथ्य यह है कि आप आसानी से खुद को ऐसी स्थिति में पा सकते हैं जहां आपको " 0, but true " जैसी किसी चीज़ की आवश्यकता होती है (और यह वही है जो पर्ल 5 में है); या जब आप कोड बनाते हैं जो सिस्टम के अन्य भागों के साथ गठबंधन करना मुश्किल है (प्रोग्राम के अगले भाग के लिए -1 एक त्रुटि नहीं हो सकता है, लेकिन एक वैध इनपुट मूल्य है)।

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

जब एक राज्य ऊपर से नीचे तक नहीं गुजरता है, अर्थात् एक एपिसोडिक चक्र के मामले में, राज्य को अपने स्वयं के चर के साथ प्रदान करना और तर्क को स्पष्ट करना सबसे अच्छा है। यदि आपके पास ऑब्जेक्ट के अंदर बूलियन का एक सेट है, तो उन्हें state नामक एक चर के साथ बदलें और एनम (या कहीं और एक स्ट्रिंग) का उपयोग करें। if अभिव्यक्तियाँ दिखाई देंगी if state == name , if bad_name && !alternate_option नहीं if bad_name && !alternate_option ।

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

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

नियम 4: यादृच्छिक व्यवहार अपेक्षित व्यवहार है।

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

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

दुर्भाग्य से, आपके कार्यक्रम में यादृच्छिकता के किसी भी स्रोत का उपयोग अंततः सांख्यिकीय सिमुलेशन, या इससे भी बदतर - क्रिप्टोग्राफी के लिए किया जाएगा; और छँटाई के लिए किसी भी सॉर्टिंग स्रोत का उपयोग किया जाएगा।

डेटाबेस में, कुछ पहचानकर्ताओं में दूसरों की तुलना में थोड़ी अधिक जानकारी होती है। एक तालिका बनाकर, डेवलपर विभिन्न प्रकार की प्राथमिक कुंजी के बीच चयन कर सकता है। सही विकल्प UUID है, या इससे कुछ अप्रभेद्य है। अन्य विकल्पों का नुकसान यह है कि वे आदेश देने और पहचान की जानकारी का खुलासा कर सकते हैं। यही है, न केवल a == b , लेकिन a <= b , और अन्य विकल्पों का मतलब है ऑटो-इंक्रीमेंट कुंजी।

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

लेकिन UUID को विफल करने का कोई भी प्रयास विफल हो जाएगा: हमने पहले से ही डाक कोड, फोन नंबर और आईपी पते का उपयोग करने की कोशिश की है, और हर बार बुरी तरह विफल रहे। एक UUID आपके कोड को डिबग करना आसान नहीं बना सकता है, लेकिन कम यादृच्छिक व्यवहार का मतलब कम परेशानी है।

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

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

नियम 5: डिबगिंग एक सामाजिक कार्य है, सबसे पहले, एक तकनीकी एक।

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

यह नियोजन, उपकरण, प्रक्रिया और प्रलेखन के साथ तय किया जा सकता है।

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

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

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

दस्तावेज़ीकरण के बिना, कोई दूसरों को सूचित निर्णय लेने की उम्मीद नहीं कर सकता है, या यहां तक ​​कि सॉफ़्टवेयर के उपयोग के परिणामों से सहमत नहीं है। प्रलेखन, उपकरण या प्रक्रियाओं के बिना, रखरखाव के बोझ को साझा करना या कम से कम उन लोगों को प्रतिस्थापित करना असंभव है जो अब समस्या का समाधान कर रहे हैं।

डिबगिंग की सुविधा के लिए इच्छा न केवल कोड के लिए, बल्कि कोड-संबंधित प्रक्रियाओं पर भी लागू होती है, इससे यह समझने में मदद मिलती है कि आपको कोड को ठीक करने के लिए किसकी त्वचा की आवश्यकता है।

डिबग कोड के लिए आसान व्याख्या करना आसान है।

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

यदि केवल कभी-कभी, जब हम मदद मांगते हैं, तो हम पूछते हैं कि क्या जरूरत नहीं है। यह इतना सामान्य है कि इसे द XY प्रॉब्लम कहा जाता है: “ मुझे फ़ाइल नाम के अंतिम तीन अक्षर कैसे मिलते हैं? और? नहीं, मेरा मतलब विस्तार है । "

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

यह एक कंपाइलर त्रुटि नहीं थी।