: यह लेख केवल मनोरंजन के लिए लिखा गया है। कार्यस्थल पर इसे दोहराने की कोशिश न करें. हालाँकि, आप जो चाहें घर पर करें। अस्वीकरण हम, डेवलपर्स, नियमित रूप से सामना करते हैं, यह हमारे काम का हिस्सा है। इसलिए, पहली नज़र में, सवाल "क्या आप जानबूझकर बग बना सकते हैं?" साधारण लग सकता है - "हां, बिल्कुल, मैं एक बग लिख सकता हूं।" हालाँकि, यदि आप इसके बारे में सोचते हैं, तो अब सब कुछ इतना स्पष्ट नहीं लगता है। बग का तथ्य यह है कि । बग एक त्रुटि है, आम तौर पर एक दोष है बग टूटे हुए कोड के समान नहीं है कार्य कार्यक्रम. सॉफ़्टवेयर समस्याओं के संदर्भ में "बग" शब्द की उत्पत्ति 1947 में हुई जब एक कीट के कारण हार्वर्ड मार्क II कंप्यूटर में खराबी आ गई। इंजीनियरों को वस्तुतः एक रिले में एक कीड़ा फंसा हुआ मिला, और उन्होंने इसे "बग पाए जाने का पहला वास्तविक मामला" बताया। समस्या क्या है? गणित के सूत्रों द्वारा संसार का भली-भांति वर्णन किया जाना ज्ञात होता है। और सूत्र वास्तव में एल्गोरिदम हैं। इसलिए, यदि हम गणितीय रूप से किसी घटना का वर्णन करने में सक्षम थे, तो परिणामी सूत्र को सही करना ताकि यह गलत परिणाम दे, एक गैर-तुच्छ कार्य है। फिर भी, यह निराशा का समय नहीं है। यहां हमारी मदद के लिए आ सकती हैं। हम सभी ने ये देखा है। सीमाओं में हमेशा कुछ न कुछ गड़बड़ होती है ♀️। तो, आइए बग बनाने के पहले विचार पर ध्यान दें - । केवल कभी-कभी सीमा संबंधी स्थितियां 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++; } } बड़े कार्यों में अपने घातक परिवर्तन छिपाएँ। - भीड़ में खो जाएँ। जितनी अधिक पंक्तियाँ, उतना अच्छा पुल अनुरोधों में समान सिद्धांत का उपयोग करें। एक छोटे पीआर में, ध्यान दिए जाने की संभावना अधिक होती है। बग को भागों में तोड़ने और उन्हें में डालने का प्रयास करें। यदि संभव हो तो अलग-अलग समीक्षकों को भी। अलग-अलग पुल अनुरोधों अपने क्यूए की कमजोरियों का पता लगाएं और उसका विश्वास जीतें। या जाँच के दौरान बातचीत से उनका ध्यान भटकाएँ। वैसे, क्या आपने हाइजेनबग के बारे में सुना है? यह एक बग है जो शोध/ के दौरान गायब हो जाता है या अपना व्यवहार बदल देता है। श्रोडिंगर की बिल्ली की तरह. यदि समाधान समस्या आपको नहीं सौंपी जाएगी तो बिल्कुल सही। डिबगिंग हाइजेनबग का एक सामान्य उदाहरण एक बग है जो तब दिखाई देता है जब प्रोग्राम को ऑप्टिमाइज़िंग कंपाइलर के साथ संकलित किया जाता है, लेकिन तब नहीं जब उसी प्रोग्राम को ऑप्टिमाइज़ेशन के बिना संकलित किया जाता है (जैसा कि अक्सर डिबगर के साथ जांच करने के उद्देश्य से किया जाता है)। डिबगिंग करते समय, वे मान जो एक अनुकूलित प्रोग्राम आमतौर पर रजिस्टरों में रखता है, अक्सर मुख्य मेमोरी में धकेल दिए जाते हैं। तुम कर सकते हो अपने आप पर यकीन रखो! इतिहास ऐसे उदाहरण जानता है जब एक बग को बहुत गंभीर कंपनियों में उत्पादन के लिए स्वीकार किया गया था। सबसे महंगे सॉफ़्टवेयर बगों में से एक 1996 में हुआ जब क्लस्टर मिशन ले जाने वाला एरियन 5 रॉकेट उड़ान भरने के केवल 40 सेकंड बाद फट गया। विफलता का पता रॉकेट के मार्गदर्शन प्रणाली में एक सॉफ़्टवेयर बग से लगाया गया था। एरियन 5 फ़्लाइट 501: 1999 में, नासा ने एक सॉफ्टवेयर त्रुटि के कारण मार्स क्लाइमेट ऑर्बिटर खो दिया। सॉफ़्टवेयर ने मीट्रिक इकाइयों (न्यूटन-सेकंड) के बजाय शाही इकाइयों (पाउंड-सेकंड) का उपयोग किया, जिससे अंतरिक्ष यान मंगल ग्रह के वातावरण में जल गया। नासा का मार्स क्लाइमेट ऑर्बिटर: इसके अलावा, कुछ बग फीचर बन सकते हैं, जैसे में दीवार से कूदना या में महात्मा गांधी का व्यवहार...शायद। मारियो सभ्यता बग विकसित करना आपके एल्गोरिदम के माध्यम से सोचने और संभावित समस्याओं का पूरी तरह से अनुमान लगाने की क्षमता है। इसलिए, भले ही आपके पास कोड में बग छोड़ने का कोई कारण न हो, फिर भी यह विचार करने लायक है।
