The Repeat Offenders: Characterizing and Predicting Extremely Bug-Prone Source Methods
यह अध्ययन "ExtremelyBuggy" विधियों—बग्स से बार-बार जुड़े रहने वाली सोर्स कोड इकाइयों—की जांच करता है, जो यह प्रकट करता है कि यद्यपि वे कोड का एक छोटा हिस्सा बनाती हैं फिर भी अत्यधिक संख्या में दोष उत्पन्न करती हैं, तथापि विशिष्ट और आवर्ती विशेषताओं को प्रदर्शित करने के बावजूद, वे आरंभ में ही पूर्वानुमानित होने में कठिन बनी रहती हैं।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल, हलचल भरे कारखाने के प्रबंधक हैं जो जटिल मशीनें (सॉफ्टवेयर) बनाता है। हर दिन, कर्मचारी (डेवलपर्स) इन मशीनों में नए पुर्जे (मेथड्स) जोड़ते हैं। कभी-कभी, एक पुर्जा टूट जाता है और कारखाने को उसे ठीक करने के लिए रुकना पड़ता है। यह महंगा और निराशाजनक है।
वर्षों से, फैक्ट्री मैनेजर यह अनुमान लगाने की कोशिश कर रहे हैं कि कौन से पुर्जे टूट सकते हैं। लेकिन उनके अधिकांश उपकरण एक "पूरे कमरे" की चेतावनी प्रणाली की तरह थे। वे कहते थे, "हे, पूरा असेंबली रूम जोखिम भरा है!" लेकिन यह बहुत उपयोगी नहीं था। मैनेजर को अभी भी उस एक ढीले पेंच को खोजने के लिए पूरे कमरे में घूमना पड़ता था।
हाल ही में, शोधकर्ताओं ने पूरे कमरे के बजाय व्यक्तिगत पुर्जों (मेथड्स) को देखना शुरू किया। लेकिन उन्होंने एक गलती की: उन्होंने हर टूटे हुए पुर्जे के साथ एक जैसा व्यवहार किया। उन्होंने इस बात में अंतर नहीं किया कि एक पुर्जा एक बार टूटा या वह बार-बार टूटता है।
यह पेपर, जिसका शीर्षक "द रिपीट ऑफेंडर्स" (The Repeat Offenders) है, उन विशिष्ट पुर्जों को खोजने के बारे में है जो "पुराने अपराधी" (क्रोनिक ट्रबलमेकर) हैं।
बड़ी खोज: "द रिपीट ऑफेंडर्स"
शोधकर्ताओं ने 98 अलग-अलग ओपन-सोर्स प्रोजेक्ट्स से 1.25 मिलियन से अधिक कोड पार्ट्स का अध्ययन किया। उन्हें एक आश्चर्यजनक बात पता चली:
- "बुरे सेब" दुर्लभ हैं: केवल एक बहुत छोटा हिस्सा (गिनती के आधार पर 1% से 7% के बीच) "एक्सट्रीमली बग्गी" (अत्यधिक त्रुटिपूर्ण) है। ये वे पुर्जे हैं जिन्हें कई बार ठीक किया जाता है।
- लेकिन वे अधिकांश अराजकता का कारण बनते हैं: भले ही वे दुर्लभ हैं, ये "रिपीट ऑफेंडर्स" कारखाने के सभी बग्स में एक बहुत बड़ा हिस्सा पैदा करते हैं। कुछ प्रोजेक्ट्स में, इन कुछ खराब पुर्जों ने 90% से अधिक समस्याओं का कारण डाला।
उपमा: कल्पना कीजिए कि 1,000 छात्रों वाला एक स्कूल है। 990 छात्र अच्छे व्यवहार वाले हैं। 10 छात्र साल में एक बार trouble करते हैं। लेकिन 5 छात्र ऐसे हैं जो हर हफ्ते trouble करते हैं। यदि आप स्कूल को सुचारू रूप से चलाना चाहते हैं, तो आपको उन सभी पर समान रूप से नज़र रखने की ज़रूरत नहीं है। आपको बस उन 5 रिपीट ऑफेंडर्स पर कड़ी नज़र रखने की ज़रूरत है।
क्या हम उनके टूटने से पहले भविष्यवाणी कर सकते हैं?
शोधकर्ताओं ने पूछा: "क्या हम एक नया पुर्जा बनते ही देख सकते हैं और कह सकते हैं, 'हे, यह एक रिपीट ऑफेंडर होने वाला है!'?"
उन्होंने इन समस्या पैदा करने वालों को पहचानने के लिए कंप्यूटर प्रोग्राम (मशीन लर्निंग) का उपयोग करने की कोशिश की, जो कोड के स्वरूप (आकार, जटिलता, पठनीयता) के आधार पर काम करते हैं।
- परिणाम: कंप्यूटर इसमें बहुत खराब थे। वे केवल ब्लूप्रिंट (खाके) को देखकर एक सामान्य पुर्जे और भविष्य के ट्रबलमेकर के बीच अंतर नहीं कर सके।
- क्यों? यह भविष्यवाणी करने जैसा है कि एक बच्चा जन्म प्रमाण पत्र देखकर अपराधी बनेगा या नहीं। ब्लूप्रिंट अस्त-व्यत दिख सकता है, लेकिन असली समस्या अक्सर बाद में शुरू होती है, जैसे-जैसे कोड को संशोधित और उलझाया जाता है।
ये "रिपीट ऑफेंडर्स" वास्तव में कैसे दिखते हैं?
चूंकि कंप्यूटर उनकी भविष्यवाणी नहीं कर सके, इसलिए शोधकर्ताओं ने जासूसी टोपी पहनी और मैन्युअल रूप से 265 इन समस्या पैदा करने वाले भागों का विश्लेषण किया। उन्हें कुछ स्पष्ट पैटर्न मिले, जैसे कि एक अपराधी का प्रोफाइल:
- वे "मेगा-ब्लॉक्स" हैं: ये भाग अक्सर बहुत बड़े होते हैं। कल्पना कीजिए कि एक ही निर्देश पुस्तिका 500 पन्नों की है। इसे पढ़ना, समझना और इसमें गलती करना कठिन है।
- वे "भ्रमित करने वाले भूलभुलैया" हैं: इनके अंदर का लॉजिक घुमावदार है, जिसमें बहुत सारे "यदि यह, तो वह" (if this, then that) लूप हैं। यह एक ऐसी भूलभुलैया की तरह है जिसमें हर जगह डेड एंड (बंद रास्ते) हैं।
- वे मशीन का "हृदय" हैं: ये भाग अक्सर सबसे महत्वपूर्ण लॉजिक (जैसे कार का इंजन) को संभालते हैं। क्योंकि ये इतने महत्वपूर्ण हैं, इसलिए इनमें सबसे अधिक बदलाव किए जाते हैं, जिससे हर बार नए बग्स आते हैं।
- वे "गंदे" हैं: इनका फॉर्मेटिंग खराब है, वेरिएबल के नाम अजीब हैं, और डेवलपर्स अक्सर नोट्स छोड़ देते हैं जैसे "मुझे पता है कि यह बुरा है, मैं इसे बाद में ठीक करूँगा" (जिसे टेक्निकल डेट कहा जाता है)।
- वे "नाजुक" हैं: ये त्रुटियों (जैसे जब डेटाबेस विफल हो जाता है) को बहुत खराब तरीके से संभालते हैं, अक्सर उन्हें अनदेखा करते हैं या पूरे सिस्टम को क्रैश कर देते हैं।
हमें इस पर क्या करना चाहिए?
यह पेपर सॉफ्टवेयर प्रबंधकों और डेवलपर्स को दो मुख्य सलाह देता है:
- शोधकर्ताओं के लिए: हमें बेहतर उपकरणों की आवश्यकता है। चूंकि सरल कोड माप पर्याप्त नहीं हैं, इसलिए हमें कोड के इतिहास को देखना होगा और अधिक स्मार्ट AI का उपयोग करना होगा जो केवल आकार को नहीं, बल्कि संदर्भ (context) को समझता हो।
- प्रैक्टिशनर्स (फैक्ट्री मैनेजरों) के लिए:
- भविष्य की सटीक भविष्यवाणी करने की कोशिश न करें। इसके बजाय, आज के "रेड फ्लैग्स" (चेतावनी के संकेतों) को देखें। यदि आप देखते हैं कि कोई नया कोड बहुत बड़ा, गंदा और मुख्य लॉजिक को संभालने वाला है, तो उसे अत्यंत सावधानी के साथ लें।
- इसे तोड़ें। यदि एक मेथड बहुत बड़ा है, तो उसे छोटे, प्रबंधनीय टुकड़ों में विभाजित करें।
- "मैं इसे बाद में करूँगा" वाले नोट्स को ठीक करें। यदि कोई डेवलपर स्वीकार करता है कि कोई भाग गंदा है (टेक्निकल डेट), तो उसे "रिपीट ऑफेंडर" बनने से पहले तुरंत ठीक करें।
- एज केसेस (edge cases) का परीक्षण करें। ये ट्रबलमेकर अक्सर दुर्लभ, अजीब स्थितियों के कारण विफल होते हैं। विशेष रूप से उन अजीब परिदृश्यों के लिए टेस्ट लिखें।
निष्कर्ष
आप हर बग को होने से नहीं रोक सकते। लेकिन उन "रिपीट ऑफेंडर्स"—अपने कोड के उन कुछ, गंदे, जटिल और महत्वपूर्ण हिस्सों—की पहचान करके, जो बार-बार टूटते रहते हैं, आप अपनी ऊर्जा वहां लगा सकते हैं जहाँ इसकी सबसे अधिक आवश्यकता है। पूरे कारखाने को ठीक करने के बजाय, बस उन पांच समस्या पैदा करने वालों पर कड़ी नज़र रखें, और आप बहुत सारा समय, पैसा और सिरदर्द बचा लेंगे।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।