क्या आप जानबूझकर कोई बग बना सकते हैं?

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

तथ्य यह है कि बग टूटे हुए कोड के समान नहीं है । बग एक त्रुटि है, आम तौर पर एक दोष है

कार्य कार्यक्रम.

समस्या क्या है?

गणित के सूत्रों द्वारा संसार का भली-भांति वर्णन किया जाना ज्ञात होता है। और सूत्र वास्तव में एल्गोरिदम हैं। इसलिए, यदि हम गणितीय रूप से किसी घटना का वर्णन करने में सक्षम थे, तो परिणामी सूत्र को सही करना ताकि यह केवल कभी-कभी गलत परिणाम दे, एक गैर-तुच्छ कार्य है। फिर भी, यह निराशा का समय नहीं है। यहां सीमा संबंधी स्थितियां हमारी मदद के लिए आ सकती हैं। if index == 0 {…} else if index == n-1 {…} हम सभी ने ये देखा है। सीमाओं में हमेशा कुछ न कुछ गड़बड़ होती है ‍♀️। तो, आइए बग बनाने के पहले विचार पर ध्यान दें - किनारे के मामलों को अनदेखा करें ।

सामान्य तौर पर, सरणियों के माध्यम से पुनरावृत्ति संभावित बग का भंडार है। और उनमें से सबसे आम है सीमा से बाहर सूचकांक । यदि आपने कभी ऐसी किसी चीज़ पर ठोकर नहीं खाई है, तो आपने कभी कोड नहीं किया है। दुर्भाग्य से, यह बग इतना लोकप्रिय है कि लोगों ने सरणियों के लिए सुरक्षित रैपर लिखना शुरू कर दिया, कुछ-कुछ array[safe: index] जैसा। इसलिए आज, आपके सहकर्मी इस चीज़ के बिना शायद ही किसी कोड को स्वीकृत करेंगे। आप कोशिश कर सकते हैं, लेकिन इसकी संभावना नहीं है...

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

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

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

सामान्य सलाह

यह हास्यास्पद है कि जब बग लिखने की बात आती है तो चैटजीपीटी भी मदद करने से इनकार कर देता है। शायद मुझे बस एक प्रीमियम सदस्यता की आवश्यकता है… 🤔

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

बग बनाने की समस्या को हल करते समय, उपकार्यों को निर्धारित करना उचित है। सबसे पहले, हमें कुछ दुर्लभ किनारे वाले मामलों के साथ आने की जरूरत है। दूसरे, हमें बग को नियमित कोड के रूप में छिपाने की जरूरत है ताकि यह कोड समीक्षा में सफल हो सके। तीसरा, हमें QA विभाग का ध्यान कुंद करना होगा। चौथा, तुरंत पकड़े न जाएं। लेकिन यह पहले से ही वैकल्पिक है.

मेरी सामान्य सलाह इस प्रकार है (और आप अपनी राय टिप्पणियों में साझा करें):

• पहुंच स्तर में हेरफेर करें . डबल बैक करने के लिए, सबसे अप्रत्याशित स्थानों से महत्वपूर्ण मापदंडों के मान बदलें। इसे कई कक्षाओं के माध्यम से करें जैसे कि आप एक वीपीएन थे।

• चाइल्ड क्लास में कुछ अप्रत्याशित तर्क लागू करें। संक्षेप में, SOLID में L सिद्धांत को तोड़ें ।

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• बड़े कार्यों में अपने घातक परिवर्तन छिपाएँ। जितनी अधिक पंक्तियाँ, उतना अच्छा - भीड़ में खो जाएँ।

• पुल अनुरोधों में समान सिद्धांत का उपयोग करें। एक छोटे पीआर में, ध्यान दिए जाने की संभावना अधिक होती है।

• बग को भागों में तोड़ने और उन्हें अलग-अलग पुल अनुरोधों में डालने का प्रयास करें। यदि संभव हो तो अलग-अलग समीक्षकों को भी।

• अपने क्यूए की कमजोरियों का पता लगाएं और उसका विश्वास जीतें। या जाँच के दौरान बातचीत से उनका ध्यान भटकाएँ।

वैसे, क्या आपने हाइजेनबग के बारे में सुना है? यह एक बग है जो शोध/ डिबगिंग के दौरान गायब हो जाता है या अपना व्यवहार बदल देता है। श्रोडिंगर की बिल्ली की तरह. यदि समाधान समस्या आपको नहीं सौंपी जाएगी तो बिल्कुल सही।

तुम कर सकते हो

अपने आप पर यकीन रखो! इतिहास ऐसे उदाहरण जानता है जब एक बग को बहुत गंभीर कंपनियों में उत्पादन के लिए स्वीकार किया गया था।

एरियन 5 फ़्लाइट 501: सबसे महंगे सॉफ़्टवेयर बगों में से एक 1996 में हुआ जब क्लस्टर मिशन ले जाने वाला एरियन 5 रॉकेट उड़ान भरने के केवल 40 सेकंड बाद फट गया। विफलता का पता रॉकेट के मार्गदर्शन प्रणाली में एक सॉफ़्टवेयर बग से लगाया गया था।

नासा का मार्स क्लाइमेट ऑर्बिटर: 1999 में, नासा ने एक सॉफ्टवेयर त्रुटि के कारण मार्स क्लाइमेट ऑर्बिटर खो दिया। सॉफ़्टवेयर ने मीट्रिक इकाइयों (न्यूटन-सेकंड) के बजाय शाही इकाइयों (पाउंड-सेकंड) का उपयोग किया, जिससे अंतरिक्ष यान मंगल ग्रह के वातावरण में जल गया।

इसके अलावा, कुछ बग फीचर बन सकते हैं, जैसे मारियो में दीवार से कूदना या सभ्यता में महात्मा गांधी का व्यवहार...शायद।

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