Exceptional Behaviors: How Frequently Are They Tested?
यह शोध पत्र 25 पायथन प्रणालियों का एक अनुभवजन्य अध्ययन प्रस्तुत करता है जो दर्शाता है कि जबकि 21.4% निष्पादित विधियाँ अपवाद (exceptions) उत्पन्न करती हैं, ये अपवादात्मक व्यवहार अक्सर अभ्यास में भी आते हैं (मध्यिका 10 में से 1 कॉल), फिर भी अक्सर अनटेस्टेड रहते हैं, जो बेहतर परीक्षण उपकरणों के लिए सिफारिशें और अपवाद उत्पन्न करने वाले परिदृश्यों की दुर्लभता के पुनर्मूल्यांकन को प्रेरित करते हैं।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक व्यस्त रेस्टोरेंट चलाने वाले शेफ हैं। अधिकांश समय, आप खुश ग्राहकों के लिए बेहतरीन भोजन बना रहे होते हैं (यह सामान्य व्यवहार है)। लेकिन कभी-कभी, चीजें गलत हो जाती हैं: ओवन खराब हो जाता है, कोई ग्राहक ऐसी चीज़ ऑर्डर करता है जो आपके पास नहीं है, या डिलीवरी में देरी हो जाती है (ये अपवाद (exceptions) हैं)।
कंप्यूटर प्रोग्रामिंग की दुनिया में, इन "गलत होने वाली चीजों" को अपवाद (exceptions) कहा जाता है। डेवलपर्स इन त्रुटियों को पकड़ने और उन्हें कुशलता से संभालने के लिए विशेष कोड लिखते हैं, ताकि पूरा रेस्टोरेंट जलकर राख न हो जाए।
यह पेपर एक टीम की तरह है जो 25 अलग-अलग, वास्तविक दुनिया के रेस्टोरेंट्स (सॉफ्टवेयर सिस्टम) में गई थी यह देखने के लिए कि क्या स्टाफ वास्तव में अपने दैनिक अभ्यास (टेस्ट सूट्स) के दौरान इन आपदाओं को संभालने का अभ्यास करता है।
यहाँ उन्होंने जो पाया, उसे सरल रूप में नीचे दिया गया है:
1. "अभ्यास" बनाम "असली चीज़"
निरीक्षकों ने पाया कि जबकि शेफ (डेवलपर्स) बेहतरीन भोजन बनाने का अभ्यास करने में बहुत अच्छे हैं, वे इस बात का अभ्यास बहुत कम करते हैं कि अगर ओवन में आग लग जाए तो क्या करना है।
- आंकड़ा: प्रत्येक 100 कुकिंग स्टेशनों (मेथड्स) में से, केवल लगभग 21 में अभ्यास के दौरान वास्तव में कोई समस्या आई।
- उपमा: यह एक फायर ड्रिल की तरह है जहाँ 100 में से 79 लोग कभी यह नाटक भी नहीं करते कि फायर अलार्म बज रहा है। वे बस खाना बनाना जारी रखते हैं।
2. गलतियाँ वास्तव में कितनी बार होती हैं?
उन स्टेशनों के लिए जहाँ समस्या आई, निरीक्षकों ने देखा कि वह समस्या कितनी बार होती है।
- आंकड़ा: औसतन, एक स्टेशन के लिए जहाँ समस्या हो सकती है, हर 10 प्रयासों में से केवल 1 बार समस्या वास्तव में हुई।
- उपमा: कल्पना कीजिए कि एक शेफ स्टीक जला सकता है। यदि वे 100 स्टीक बनाते हैं, तो वे केवल 10 बार ही उन्हें जलाते हैं। बाकी 90 एकदम सही होते हैं। अधिकांश समय, "जलना" एक दुर्लभ घटना होती है।
3. "दुर्लभ" बनाम "सामान्य" आपदाएँ
निरीक्षकों ने दो बहुत अलग प्रकार के "आपदा-प्रवण" स्टेशनों को देखा:
- "दुर्लभ" आपदाएँ (80% मामले): अधिकांश स्टेशन जिनमें विफलता हो सकती है, वे लगभग कभी विफल नहीं होते। उदाहरण के लिए, एक स्टेशन का नियम हो सकता है: "यदि ग्राहक 'यूनिकॉर्न बर्गर' का ऑर्डर दे, तो गुस्सा करो।" लेकिन चूंकि कोई भी यूनिकॉर्न बर्गर नहीं ऑर्डर करता, इसलिए शेफ को गुस्सा करने की ज़रूरत ही नहीं पड़ती।
- "सामान्य" आपदाएँ (20% मामले): कुछ स्टेशन हर समय विफल होते हैं। कल्पना कीजिए कि एक स्टेशन कहता है, "यदि ग्राहक 'ग्लूटेन-फ्री पिज्जा' का ऑर्डर दे, तो गुस्सा करो।" यदि 90% ग्राहक ग्लूटेन-फ्री पिज्जा ऑर्डर करते हैं, तो यह शेफ लगातार गुस्सा कर रहा है।
- ट्विस्ट: इन दुर्लभ मामलों में, "गुस्सा करना" (एक्सेप्शन थ्रो करना) वास्तव में उस स्टेशन के काम करने का सामान्य तरीका है! पेपर तर्क देता है कि सिर्फ इसलिए कि कंप्यूटर कोड एक एरर थ्रो करता है, इसका मतलब यह नहीं है कि कुछ "टूटा हुआ" या "असामान्य" है। कभी-कभी, एरर ही अपेक्षित परिणाम होता है।
4. "छिपे हुए" एरर (त्रुटियाँ)
सबसे दिलचस्प निष्कर्षों में से एक उन त्रुटियों के बारे में है जो होती हैं लेकिन "मैनेजर" (टेस्ट सुइट) द्वारा कभी देखी नहीं जातीं।
- उपमा: कल्पना कीजिए कि एक सोस-शेफ ने एक प्लेट गिरा दी, लेकिन हेड शेफ ने नॉइज़-कैंसलिंग हेडफ़ोन पहने हुए हैं और उसे सुनाई नहीं दिया। सोस-शेफ जल्दी से उसे उठा लेता है और खाना बनाना जारी रखता है। मैनेजर सोचता है कि सब ठीक है, लेकिन प्लेट गिरी थी।
- वास्तविकता: अध्ययन में पाया गया कि कई त्रुटियाँ कोड के अंदर होती हैं, तुरंत एक सुरक्षा जाल (एक
try/exceptब्लॉक) द्वारा पकड़ी जाती हैं, और टॉप-लेवल टेस्ट तक कभी नहीं पहुँच पातीं। टेस्ट को पता ही नहीं चलता कि ये त्रुटियाँ हुईं, भले ही वे हुई थीं।
5. "महंगे" सुरक्षा जाल
अंत में, पेपर ऊर्जा की बर्बादी की ओर इशारा करता है।
- उपमा: कल्पना कीजिए कि एक शेफ चूल्हे के ठीक बगल में एक विशाल, भारी, महंगा अग्निशामक यंत्र (fire extinguisher) रखता है, बस सावधानी के तौर पर। लेकिन वे इसका उपयोग साल में केवल एक बार करते हैं। यह ले जाने में भारी है और जगह घेरता है।
- सुझाव: पेपर सुझाव देता है कि उन स्टेशनों के लिए जहाँ त्रुटियाँ बहुत कम होती हैं (जैसे "यूनिकॉर्न बर्गर" वाला उदाहरण), खाना पकाने से पहले यह जांच लेना बेहतर हो सकता है कि ऑर्डर वैध है या नहीं, बजाय इसके कि भारी अग्निशामक यंत्र तैयार रखा जाए। इससे किचन तेज़ और अधिक कुशल बनता है।
सारांश
पेपर हमें बताता है कि:
- अधिकांश त्रुटियाँ दुर्लभ हैं: हम "अगर चीज़ें गलत हो गईं तो क्या होगा" वाले परिदृश्यों का परीक्षण कम करते हैं क्योंकि वास्तविक जीवन में वे अक्सर नहीं होते।
- कुछ त्रुटियाँ सामान्य हैं: कुछ विशिष्ट कार्यों के लिए, "विफल होना" वास्तव में सिस्टम के काम करने का मानक तरीका है।
- हम छिपी हुई त्रुटियों को मिस कर देते हैं: कई त्रुटियाँ होती हैं और तुरंत ठीक हो जाती हैं, इसलिए हमारे टेस्ट को पता भी नहीं चलता कि वे हुई थीं।
- हम अधिक कुशल हो सकते हैं: कभी-कभी, हम उन समस्याओं के लिए भारी, महंगे सुरक्षा तंत्रों का उपयोग कर रहे होते हैं जो लगभग कभी नहीं होतीं, और हम उन्हें सरल जाँचों से बदल सकते हैं।
लेखक सुझाव देते हैं कि हमें उन दुर्लभ आपदा परिदृश्यों का अभ्यास करने और यह पता लगाने में मदद करने के लिए बेहतर उपकरणों की आवश्यकता है कि कौन से सुरक्षा जाल बहुत भारी हैं।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।