क्या बड़े पैमाने पर सॉफ़्टवेयर के लिए पूर्ण शून्य बग स्थिति तक पहुंचना संभव है?


71

मैं कोड के 20-30 + लाखों लाइनों के बारे में बात कर रहा हूं, उदाहरण के लिए ऑटोडेस्क माया के पैमाने और जटिलता पर सॉफ्टवेयर।

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

क्योंकि कुछ धारणा है कि आपके द्वारा किया गया प्रत्येक फिक्स अधिक बग बनाता है, लेकिन मुझे नहीं लगता कि यह सच है।

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


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

51
यदि आप नहीं जानते कि एक बग अभी तक मौजूद है, तो क्या यह अभी भी एक बग है?
Blrfl

5
@Blrf: इससे भी महत्वपूर्ण बात, अगर अंतिम उपयोगकर्ता बग के बारे में नहीं जानता है, तो क्या यह मौजूद है?
mattnz

40
“सॉफ्टवेयर डिजाइन के निर्माण के दो तरीके हैं। एक तरीका यह है कि इसे इतना सरल बनाया जाए कि जाहिर तौर पर कोई कमी न रहे। और दूसरा तरीका यह है कि इसे इतना जटिल बना दिया जाए कि कोई स्पष्ट कमी न रहे। ”- कार होरे
एंड्रयू लुईस

5
यह है, लेकिन बहुत से लोग नहीं चाहते कि उनकी मौलिक मान्यताओं पर सवाल उठाया जाए।
जोन वेंज

जवाबों:


92

जैसा कि मिकी ने उल्लेख किया है, बगलेस कोड लिखना लक्ष्य नहीं है। यदि आप ऐसा कर रहे हैं, तो मेरे लिए आपके लिए बहुत बुरी खबर है।

मुख्य बिंदु यह है कि आप सॉफ्टवेयर की जटिलता को बहुत कम कर रहे हैं।

पहली चीजें पहले - आप अपने कार्यक्रम को चलाने के तरीके की बड़ी तस्वीर को अनदेखा कर रहे हैं। यह एक पूर्ण प्रणाली पर अलगाव में नहीं चलता है। यहां तक ​​कि "हैलो वर्ल्ड" कार्यक्रमों का सबसे बुनियादी एक ऑपरेटिंग सिस्टम पर चलता है, और इसलिए, यहां तक ​​कि कार्यक्रमों का सबसे सरल उन बगों के लिए अतिसंवेदनशील है जो ऑपरेटिंग सिस्टम में मौजूद हो सकते हैं।

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

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

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

नीचे पंक्ति: क्या आप "बग फ्री सॉफ्टवेयर" लिख सकते हैं?

नहीं

जो कोई भी आपको बताता है अन्यथा क्लूलेस है।

बस ऐसे सॉफ्टवेयर लिखने की कोशिश करें जो समझने और बनाए रखने में आसान हो। एक बार जब आप ऐसा कर लेते हैं, तो आप इसे एक दिन कह सकते हैं।


संपादित करें: कुछ लोगों ने एक उत्कृष्ट बिंदु के बारे में टिप्पणी की जिसे मैंने पूरी तरह से अनदेखा कर दिया था: संकलक।

जब तक आप असेंबली में नहीं लिख रहे हैं, यह पूरी तरह से संभव है कि कंपाइलर आपके कोड को गड़बड़ कर देगा (भले ही आप साबित करें कि आपका कोड "सही" है)।

GCC में बग की एक सूची, जो आमतौर पर उपयोग किए जाने वाले कंपाइलरों में से एक है: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution----


8
जवाब अभी भी "नहीं" है, क्योंकि हमेशा "बग" होगा जहां कुछ काम करता है - बस ग्राहक या उत्पाद के मालिक की तरह यह काम नहीं करेगा। हममें से कुछ लोग इन सुविधाओं के अनुरोधों, या व्यवहार को बदलने या कार्यक्षमता को जोड़ने का अनुरोध कर सकते हैं - लेकिन उस व्यक्ति को जो हर दिन कुछ "बग" से परेशान हो रहा है, जो चीज उन्हें गुस्सा दिलाती है वह बग है। (यह कहने का एक लंबा तरीका है कि कुछ कीड़े देखने वाले की नजर में हैं।) बग फ्री कोड असंभव है। कोड के लिए लक्ष्य जो अपने इच्छित उद्देश्य को पूरा करने के लिए पर्याप्त है।
जल्दी से जल्दी

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

11
@ JohnR.Strohm मुझे यकीन नहीं है कि आपको क्यों लगता है कि 'संदेश प्रवाह न्यूनाधिक' कार्यक्रम, 556 लाइनों के कोड वाला एक कार्यक्रम, सैद्धांतिक 20 मिलियन लाइन प्रणाली के बारे में एक प्रश्न के साथ कुछ भी है। सिवाय, शायद, यह प्रदर्शित करने के लिए कि हालांकि यह छोटे कार्यक्रम की शुद्धता को साबित करने के लिए कठिन था, यह एक बड़े पैमाने की शुद्धता को साबित करने के लिए खगोलीय रूप से कठिन होगा।
एरिक किंग

9
हालांकि मूल प्रश्न ऐसा नहीं करता था, मैं यह बताना चाहता हूं कि 'सैद्धांतिक रूप से संभव' और 'व्यावहारिक रूप से संभव' के बीच एक बड़ा अंतर है। जबकि बग-मुक्त 20 मिलियन-लाइन कोड आधार यकीनन सैद्धांतिक रूप से संभव है, आज के बाजार में यह लगभग निश्चित रूप से एक व्यावहारिक असंभव है। किसे पता है कि भविष्य के गर्भ में क्या है।
एरिक किंग

4
@ JohnR.Strohm आपको कागज को अधिक ध्यान से पढ़ना चाहिए। वे खुद कहते हैं: It is important to note, however, that even all of these steps provide no guarantee of absolute security. It is tempting to believe that a formally specified and proved program should be absolutely correct, but there are several reasons why a proved program may not behave exactly as expected.- अर्थ, यह बग मुक्त साबित नहीं किया जा सकता है, बल्कि कीड़े होने की संभावना कम है। बल्कि TDD की तरह।
इज़काता

27

गणितीय यह शायद , इस तरह जटिलता के 'bugless' सॉफ्टवेयर लिखने के लिए आपको 'बग' कैसे परिभाषित के आधार पर संभव हो सकता है। यह साबित हो सकता है भी गणितीय संभव हो सकता है, एक परीक्षण प्रणाली है कि हर संभव तरीके से कोड के प्रत्येक पंक्ति व्यायाम होता डिजाइन द्वारा - हर संभव उपयोग के मामले। लेकिन मुझे यकीन नहीं है - यदि आप एक ऐसी प्रणाली के साथ काम कर रहे हैं जो जटिल गणना करता है, तो आप एक 'अनंत समस्या' में भाग सकते हैं ...

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

IMO आपका प्रश्न थोड़ा गलत है: डेवलपर्स के रूप में हमारा लक्ष्य 'बगलेस' सॉफ्टवेयर लिखना नहीं है। हमारा लक्ष्य USABLE, FLEXIBLE, EASILY MAINTAINABLE सॉफ्टवेयर लिखना है ।

उपयोग करने योग्य: सिस्टम उन आवश्यक आवश्यकताओं को पूरा करता है जिनके लिए इसे डिज़ाइन किया गया था। कीड़े हो सकते हैं - लेकिन वे 'किनारे के मामलों' में होंगे - आउटलेयर, या झुंझलाहट, न कि बग जो सिस्टम की बुनियादी बातों को मजबूत करते हैं - मजबूत।

बनाए रखने: कीड़े आसानी से अलग और तय किया जा सकता है और नए कीड़े नहीं बना सकते हैं।

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

अच्छा डिजाइन अभ्यास, अच्छा नियंत्रण अभ्यास, अच्छा टीमवर्क, कर्तव्यनिष्ठ डेवलपर्स - यही GOOD सॉफ़्टवेयर का सूत्र है । ( सही नहीं है - लेकिन अच्छा )


3
"यह साबित करना कि मैथ्यू भी गणितीय रूप से संभव है, एक परीक्षण प्रणाली को डिजाइन करके जो हर संभव तरीके से कोड की हर लाइन का उपयोग करेगा - हर संभव उपयोग का मामला।": इस तरह के एक कार्यक्रम सामान्य रूप से मौजूद नहीं है (और यह साबित किया जा सकता है!)। तो शुद्धता साबित करने के लिए एक सामान्य एल्गोरिथ्म मौजूद नहीं है।
जियोर्जियो

3
सुधार: बग-मुक्त सॉफ़्टवेयर, पूर्णतः व्यावसायिक योग्यता के साथ पूर्ण संकलन, प्राप्त किया है। यह 1982 में किया गया था। Google "संदेश प्रवाह न्यूनाधिक"।
जॉन आर। स्ट्रॉहम

6
@ JohnR.Strohm: सच नहीं है। यहाँ सिर्फ एक उद्धरण है - कई कागजात और कई जगह हैं जहां वे समान चिंताओं को संबोधित करते हैं: "एक सवाल जो अक्सर सामने आता है" क्या आपने सत्यापनकर्ता का सत्यापन किया है? "शायद आश्चर्यजनक रूप से, यह मेटामैटैमिकल प्रश्न अक्सर इंजीनियरों द्वारा पूछा जाता है न कि केवल नुकीले द्वारा? शिक्षाविदों। बेशक, अगर कोई मशीन कभी सवाल का जवाब देती है "क्या आप कभी झूठ बोलते हैं?" इसका उत्तर तब और अधिक जानकारीपूर्ण नहीं होगा जब मानव प्रश्न का उत्तर देता है। "
वेक्टर

1
मेरा मतलब था कि कोई सामान्य एल्गोरिथ्म नहीं है जो किसी भी इनपुट प्रोग्राम और किसी भी इनपुट विनिर्देश के लिए काम करेगा। आप केवल विशिष्ट मामलों (उदाहरण के लिए) को संभाल सकते हैं।
जियोर्जियो

1
@Giorgio - इसलिए IMO, अच्छी डिजाइन प्रथाओं का पालन गणितीय शुद्धता के साथ खुद के विषय में बहुत अधिक महत्वपूर्ण है: अपने कोड को यह सुनिश्चित करने के लिए डिज़ाइन करें कि यह पहले से ही क्या है के साथ अच्छी तरह से एकीकृत और अनुरूप हो सकता है - और आसानी से दोषों को संभालने के लिए पर्याप्त मजबूत है। प्रकाश में आना (जो वे करेंगे)।
वेक्टर

27

इस लेख के अनुसार , स्पेस शटल के लिए ऑन-बोर्ड सॉफ्टवेयर बहुत करीब आ गया था - 420,000 लाइन प्रोग्राम के अंतिम तीन संस्करणों में सिर्फ एक त्रुटि थी। सॉफ्टवेयर 260 पुरुषों और महिलाओं के एक समूह द्वारा बनाए रखा गया था। इन लोगों की एक बड़ी संख्या सत्यापनकर्ता थी, जिनका एकमात्र उद्देश्य त्रुटियों को खोजना था।

ग्लोबल पोजिशनिंग सैटेलाइट्स के साथ नेविगेट करने के लिए शटल को अनुमति देने के लिए सॉफ़्टवेयर का अपग्रेड, प्रोग्राम के सिर्फ 1.5% या कोड की 6,366 लाइनों को प्रभावित करता है। उस बदलाव के लिए चश्मा 2,500 पृष्ठों का था। समग्र कार्यक्रम के लिए चश्मा ने 30 खंड भरे और 40,000 पृष्ठ, या प्रति पृष्ठ कोड की दस पंक्तियों की एक औसत रेखा।

बजट कोई समस्या नहीं थी - प्रति वर्ष $ 35 milli0n पर, वे चीजों को सही करने के लिए खर्च कर सकते थे।


25
एक-एक त्रुटि का पता चला । कौन जानता है कि कितनी अनिर्धारित त्रुटियां हैं? :)
एंड्रेस एफ।

8
वह "एक त्रुटि" एक विशेष मामला था। द शटल को मूल रूप से डिज़ाइन किया गया था, और दो रोबोट हथियारों के लिए निर्दिष्ट सॉफ्टवेयर। "त्रुटि" यह थी कि दूसरे हाथ का समर्थन करने के लिए अभी भी वहां कोड था।
बजे जॉन आर। स्ट्रॉहम

4
+1 1981 से 2011 तक 135 मिशनों के लिए त्रुटियों के बिना Ran
MarkJ

5
@ मर्कज: हम शायद नहीं जानते होंगे कि स्पेस शटल में वास्तव में त्रुटियां नहीं थीं। हर स्पेस शटल मिशन पर लगातार सैकड़ों लोगों द्वारा भारी निगरानी रखी जाती है, और कोडिंग में किसी भी त्रुटि को मैन्युअल रूप से ठीक किया जाएगा / क्रिडेन।
रेयान

2
@LieRyan कौन सी अच्छी तरह से मजबूत प्रणालियों की एक बड़ी संपत्ति को दर्शाता है - अगर वे भयावह रूप से विफल नहीं होते हैं और हमेशा मैनुअल ट्विकिंग की अनुमति देते हैं, तो आप इसके बजाय काम करने के लिए अनावश्यक सिस्टम (जैसे नियंत्रण केंद्र पर) का उपयोग कर सकते हैं। बेशक, यह केवल तभी समझ में आता है जब आपके पास ऐसे निरर्थक सिस्टम हों, और यदि आप वास्तव में शुद्धता और स्थिरता सुनिश्चित कर सकते हैं। एक विशिष्ट व्यवसाय एप्लिकेशन पर, एक दुर्घटना अक्सर असंगत स्थिति पर काम करने के लिए बेहतर होगी - यह एक झुंझलाहट के बीच का अंतर है, और कहते हैं, गलत आदमी को पैसा भेजना। या इसे भेजे बिना पैसा मिल रहा है ...
लुआं

15

अनिवार्य रूप से, नहीं, लेकिन आपको वैसे भी अपना सर्वश्रेष्ठ प्रदर्शन करना चाहिए। मैं समझाता हूँ कि (या यदि आप पर्याप्त धैर्य नहीं रखते हैं तो निष्कर्ष पर जाएं)

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

किसी भी कार्यक्रम में कितने कीड़े होने की उम्मीद कर सकते हैं? एक संख्या जो मुझे मिली वह थी "प्रति 1000 लाइनों में 10 दोष" (कोड पूरा 2 संस्करण, पृष्ठ 517 - केवल एक उदाहरण का उपयोग किया, किसी भी डेटा को उद्धृत नहीं किया गया) जो हमें आपके सॉफ़्टवेयर में लगभग 200 000 से 300 000 बग देता है। सौभाग्य से, हमारे पास कार्यक्रम की गुणवत्ता में सुधार करने के तरीके हैं। यूनिट परीक्षण, कोड समीक्षा और साधारण मैनुअल परीक्षण कीड़े की संख्या को कम करने के लिए जाने जाते हैं। फिर भी, संख्या अभी भी अधिक होगी।

यदि हम सभी बगों के 95% को हल कर सकते हैं जो अविश्वसनीय होगा। और फिर भी हमारे पास सॉफ्टवेयर में 10 000 से 15 000 बग होंगे।

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

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

यह स्पष्ट नहीं है कि कोड प्रूफ उपकरण वास्तव में छोटी गाड़ी सॉफ्टवेयर की समस्या को हल कर सकते हैं या नहीं। किसी भी कार्यक्रम के लिए हॉल्टिंग समस्या को हल करना निश्चित रूप से संभव नहीं है , लेकिन यह साबित करना संभव हो सकता है कि एक कार्यक्रम निर्दिष्ट के रूप में व्यवहार करता है ... लेकिन क्या? हो सकता है कि प्रूफ प्रोग्राम में बग हो। शायद विनिर्देश ही एक बग है।

तो स्पष्ट रूप से, हम बग की संख्या को बहुत कम कर सकते हैं, लेकिन यह वास्तव में कभी भी शून्य होने की संभावना नहीं है।

क्योंकि कुछ धारणा है कि आपके द्वारा किया गया प्रत्येक फिक्स अधिक बग बनाता है, लेकिन मुझे नहीं लगता कि यह सच है।

(महत्व दिया)

तुम सही हो। यह कथन गलत है। यहाँ एक उदाहरण है:

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

अब, इस बग को ठीक करते हैं:

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

देख? हमने एक बग तय किया और कोई नई शुरुआत नहीं की।

हालांकि, यह निश्चित रूप से सही है कि हर बार जब आप बग को ठीक करते हैं तो आप एक नया निर्माण करने का जोखिम उठाते हैं, हालांकि इस जोखिम को कम किया जा सकता है (जैसे इकाई परीक्षण के साथ)।

मान लीजिए कि मैं ठीक करने वाले प्रत्येक 100 बगों के लिए, मैं गलती से एक नया परिचय देता हूं। इसलिए अगर मैं 10 000 बग्स को ठीक करता हूं, तो मैं 100 नए बगों को पेश करता हूं। और अगर मैं उन नए कीड़े को ठीक करता हूं, तो मैं एक बग का परिचय देता हूं। लेकिन तो क्या? कार्यक्रम में अब 9 999 कम बग हैं, इसलिए यह संभवतः इससे बेहतर था (नए बग को मानते हुए पिछले लोगों की तुलना में 10 000 गुना खराब नहीं है)।

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

मैं कुछ शीर्ष प्रोग्रामर द्वारा पुराना था कि ओपी में उल्लेखित धारणा के कारण बहुत से कीड़े ठीक नहीं करना बेहतर है।

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

तो कम कीड़े आप को ठीक करते हैं, कम कीड़े भविष्य में आप पर वापस आएंगे

जितने कम कीड़े आप ठीक करते हैं, उतने ही कीड़े आपके सॉफ्टवेयर में बने रहेंगे, जिससे आपके उपयोगकर्ता परेशान होंगे। वास्तव में, वे "भविष्य में आपके पास वापस नहीं आएंगे"। वे वापस नहीं आएंगे क्योंकि वे पहले स्थान पर नहीं थे। "वापस आओ" की धारणा प्रतिगमन से संबंधित है। फिर से, प्रतिगमन के जोखिम को कम करना संभव है।

कुछ कीड़े तय नहीं किए जा सकते हैं क्योंकि वे इतने व्यापक रूप से उपयोग किए जाते हैं कि लोग उन पर निर्भर होने लगे और बग को ठीक करने से उन उपयोगकर्ताओं के लिए कार्यक्रम टूट जाएगा। होता है। हालांकि, क्या वास्तव में उन्हें उस मामले में कीड़े माना जा सकता है?

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

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

निष्कर्ष:

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

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

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

1
@JoanVenge मैंने यह दिखाने के लिए उदाहरण दिया कि ट्रिकी बग्स को कैसे ढूंढा जा सकता है। इस मामले में कॉपी पेस्ट करना वास्तव में सही काम था क्योंकि यह सही साबित हुआ था और स्क्रैच से लिखे जाने वाले कार्यान्वयन में अधिक कीड़े होने की संभावना थी । हम एक उद्योग के रूप में - जो उपकरण और प्रथाएं उपयोग कर रहे हैं, वह निश्चित रूप से इष्टतम नहीं है। सर्वोत्तम प्रथाओं को अनदेखा करना आसान है और बुरी आदतों को रखना आसान है। अंततः, कीड़े हमेशा मौजूद रहेंगे क्योंकि मनुष्य परिपूर्ण नहीं हैं। लेकिन हम अपना सर्वश्रेष्ठ प्रदर्शन करके और उच्च-गुणवत्ता वाली शिक्षा पर जोर देकर बग्स की संख्या को कम कर सकते हैं।
लुइसुबल 23

7
मुझे लगता है कि बाइनरी सर्च कोड में बग दर्शाता है कि यह प्रश्न कितना जटिल है। खोज में अंतर्निहित बग एक अतिरिक्त पूर्णांक ओवरफ़्लो था। इस तरह की "त्रुटियां" सर्वव्यापी हैं क्योंकि ज्यादातर लोग एक अंतर्निहित (और कभी-कभी गलत) धारणा पर भरोसा करते हैं कि इनपुट अतिप्रवाह का कारण नहीं होगा। क्या यह वास्तव में एक बग या सिर्फ एक खराब दस्तावेज इंटरफेस अनुबंध है? वह आखिरी बार कब था जब आपने सीमा को पूर्णांक जोड़ में जांचा था या तथ्य के बाद अतिप्रवाह के लिए जाँच की थी?
चार्ल्स ई। ग्रांट

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

12

बग-मुक्त कार्यक्रम नहीं लिखने के कारण ज्यादातर किफायती हैं।

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

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

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

(आमतौर पर, सिर्फ इसलिए कि आप किसी गणितीय प्रमेय की सच्चाई को स्वचालित रूप से तय करने के लिए एक कार्यक्रम नहीं लिख सकते हैं , इसका मतलब यह नहीं है कि आप एक विशिष्ट गणितीय प्रमेय साबित नहीं कर सकते हैं ।)

समस्या, इसके बजाय, यह है:

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

सभी लागतों को ध्यान में रखते हुए, एक विशिष्ट ग्राहक एक सस्ते सॉफ़्टवेयर के साथ अधिक खुश है जो 99% समय (और अतिरिक्त अद्यतनों को स्थापित करने के बाद 99.9%) का काम करता है, शायद एक हजार गुना अधिक महंगा सॉफ्टवेयर है जो 100% अच्छी तरह से काम करता है समय। इसके अलावा, ग्राहक इस सॉफ़्टवेयर को अब और दस या बीस वर्षों में नहीं चाहता है ।

इसलिए, लोग जानबूझकर सॉफ़्टवेयर का उत्पादन करते हैं, जिसमें बग्स के कुछ अवसर होते हैं, इष्टतम संयोजन को हिट करने की कोशिश करते हैं जहां बग बहुत बार-बार नहीं होते हैं और बहुत गंभीर नहीं होते हैं, और उत्पादन तेजी से और काफी सस्ता होता है। संयोजन जो वास्तविक जीवन में सबसे अधिक लाभ प्रदान करता है। (कभी-कभी इसका अर्थ यह भी होता है कि आपके प्रतिस्पर्धियों को कुछ भी जारी करने से पहले बग्स से भरा एक सॉफ़्टवेयर जारी करना, और केवल एक अधिक सभ्य संस्करण 2.0 जारी करना जब आपके प्रतियोगी अपना पहला सभ्य संस्करण जारी करने के लिए तैयार हों।)

यदि आप विकास को तब तक के लिए फ्रीज कर देते हैं जब तक इसकी आवश्यकता है, तो क्या आप वास्तव में सभी बग्स को ठीक कर सकते हैं जब तक कि केवल एक बग न हो, अगर इस तरह की चीज़ों को कंप्यूटर द्वारा सत्यापित किया जा सकता है?

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

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


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

1
"महंगा" रिश्तेदार है। कई रोगियों को मारने और कई अन्य लोगों की मौत की तरह एक रेडियोथेरेपी मशीन की लागत के साथ कीड़े को खोजने और ठीक करने की लागत की तुलना करें। (Google "थेरैक 25"।)
जॉन आर। स्ट्रॉहम

6

नहीं।

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

इनमें से कोई भी प्रैक्टिसिंग प्रोग्रामर को हमारे बीच बगैर किसी कीड़े के प्रयास से मुक्त नहीं करता है। इसका सीधा सा मतलब है कि हम सामान्य रूप से सफल नहीं हो सकते।


9
अविवेक केवल सामान्य रूप से लागू होता है - ऐसे कार्यक्रम हैं जिनके लिए आप न तो सही साबित कर सकते हैं और न ही गलत। लेकिन किसी विशिष्ट कार्यक्रम के लिए, शुद्धता (या अधिक बार: गलतता) अक्सर साबित हो सकती है। यह मान रहा है कि आपके पास एक औपचारिक भाषा विनिर्देश है, और एक सही रूप से सही संकलक है - बाद वाला किसी भी उच्च स्तरीय प्रोग्रामिंग भाषा के लिए मौजूद नहीं है, हालांकि कॉम्पर्ट पास आता है।
डैनियल

प्रासंगिक सैद्धांतिक पृष्ठभूमि के उद्धरण के लिए +1। मुझे अभी तक यह नहीं पता था कि "एनट्सचेइडंगस्प्रोब्लेम" को अंग्रेजी में जर्मन में ही कहा जाता है!
पीपुलवेयर

5
डैनियल के साथ सहमत हूँ। चुनौती एक एकल उदाहरण के बारे में है; रुकने की समस्या सभी संभावित उदाहरणों से संबंधित है। तुच्छ int main() { return 0; } हाल्ट और बग-मुक्त है।
MSalters

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

6

एरेरे ह्यूमनम एस्ट

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

यहां तक ​​कि अगर आप एक औपचारिक विनिर्देश भाषा का उपयोग करते हैं,

हमेशा एक मानवीय कदम होता है जिसमें उपयोगकर्ता की जरूरतों को एक या एक से अधिक दिमागों को कंप्यूटर से निकालने में शामिल होता है।

यह मानव कदम त्रुटि-प्रवण है, और कीड़ा सेब में है।


1
क्या यह अभी भी एक बग है जब एक कार्यक्रम वही करता है जो पूछा गया था, इसके बजाय क्या इरादा था?
MSalters

मुझे लगता है कि यह है ..
जोन वेंज

4
@MSalters - बेशक यह है। अनुबंध के दृष्टिकोण से नहीं, लेकिन अंत में ग्राहक ने अपनी समस्या हल नहीं की है। क्या आप एक ऐसे विमान में बैठेंगे जिसका कंप्यूटर वही करता है जो पूछा नहीं जाता है लेकिन क्या इरादा है?
मूविसील

3

"बग" का एक उचित अनुपात जो मैंने सामना किया है उसे सिस्टम डिजाइन और ग्राहक की अपेक्षा के बीच बेमेल के रूप में वर्णित किया जा सकता है।

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

यहां तक ​​कि अगर कोई प्रणाली तकनीकी रूप से, किसी मीटिंग को पूरा करने के अर्थ में "सही" है, (हालांकि वास्तविक दुनिया के वाणिज्यिक सॉफ्टवेयर के लिए यह असंभव हो सकता है), तो आपके पास अपने ग्राहक के लिए सॉफ्टवेयर के कार्य के मिलान की समस्या अभी भी होगी- स्थानांतरण और खराब परिभाषित अपेक्षाएं।

संक्षेप में:

नहीं।


+1 एक डेवलपर और एक ग्राहक एक 'बग' को परिभाषित करने पर व्यापक रूप से भिन्न विचार रख सकते हैं।
ग्रैंडमास्टरबी

लेकिन क्या होगा अगर डेवलपर भी उपयोगकर्ता है? मुझे उन लोगों से प्रयोज्यता के संदर्भ में आमतौर पर सबसे अच्छा सॉफ्टवेयर मिलता है क्योंकि वे जानते हैं कि वास्तव में कुछ कैसे काम करना चाहिए, आदि
Joan Venge

2

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


1

मैंने जिम शोर के खंड नो बग्स को इस विषय पर बहुत उपयोगी रीडिंग पाया । संक्षिप्त रूप: बग उत्पन्न किए बिना इसका विकास संभव नहीं है - लेकिन हम इस तरह से काम कर सकते हैं कि हम उनका पता लगा सकें।

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

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


1

कंप्यूटर भाग द्वारा सत्यापन के बारे में।

कंप्यूटर का उपयोग करके प्रोग्राम को सत्यापित करने के दो तरीके हैं। एक परीक्षण कर रहा है, दूसरा प्रूफ सिस्टम का उपयोग कर रहा है।

जैसे ही थकावट का परीक्षण संभव नहीं है, परीक्षण यह दिखाने में असमर्थ हो जाता है कि किसी कार्यक्रम में बग नहीं है, बस यह कुछ है। (और आपके पास यह दिखाने के लिए मुद्दा है कि आपके परीक्षण स्वयं बग की उपस्थिति के लिए परीक्षण नहीं कर रहे हैं)।

एक सबूत प्रणाली का उपयोग करने के लिए, आप औपचारिक आवश्यकताओं से शुरू करते हैं (और वे स्वयं बग हो सकते हैं, उम्मीद है कि आवश्यकताओं के लिए उपयोग की जाने वाली भाषा अपने आप को समझाने के लिए अधिक उपयुक्त होगी कि प्रोग्रामिंग भाषा के साथ कोई बग नहीं है) और निर्माण / सिद्ध करें प्रूफ सिस्टम की मदद से प्रोग्राम बग फ्री होता है (और प्रूफ सिस्टम में बग्स का सवाल होता है, लेकिन उन्होंने खुद को सही साबित किया)। कला की वर्तमान स्थिति एक सी सबसेट के लिए एक संकलक है (और सबसेट अकादमिक नहीं है, "कॉम्पर्ट M CRA के सभी MISRA-C 2004 के सबसेट का समर्थन करता है, साथ ही MISRA द्वारा बाहर की गई कई विशेषताएं")।


डोनाल्ड नुथ (स्मृति से) को उद्धृत करने के लिए: आप साबित कर सकते हैं कि एक कार्यक्रम बग मुक्त है, लेकिन इसका मतलब यह नहीं है कि इसमें कोई बग नहीं है :-)
gnasher729

1

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

हार्डवेयर और OS के अलावा, अधिकांश महत्वपूर्ण ऐप्स के नीचे कई मिडलवेयर उत्पाद भी हैं जो आपके नियंत्रण से बाहर भी विकसित होंगे, और जैसे ही आप अपना कोड एक शून्य दोष अवस्था में प्राप्त करते हैं, उसके नीचे की परतें आपको EOL'ed मिलती हैं।

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

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


0

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

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


-2

पर्याप्त अनुशासन और साझा टीम संस्कृति को देखते हुए बग-मुक्त सॉफ़्टवेयर को लगातार वितरित करना संभव है । "

लेकिन ऐसा करते हुए, आप आम तौर पर 20 MLOC सिस्टम बनाने के लिए तैयार नहीं होते हैं। यदि बग-मुक्त कोड लिखना आपका लक्ष्य नहीं है, तो न ही कई एमएलओसी प्रणाली का निर्माण किया जाना चाहिए।

मेरा अपना तर्क इस प्रकार है:

किसी व्यक्ति को पूरा करने की आवश्यकता है। कुछ व्यक्ति (संभवतः एक ही, संभवतः एक अलग एक) के पास लेखन सॉफ्टवेयर के माध्यम से आवश्यकता को पूरा करने के लिए एक बजट है। इन सभी लोगों को अपने पैसे के लिए कुछ लाभ प्राप्त करने की उम्मीद है।

एक बजट वाला व्यक्ति कुछ लोगों को (संभवतः एक ही, संभवतः अलग-अलग) प्रोग्रामर नामक भुगतान करेगा , ताकि ये प्रोग्रामर अपने समय की मात्रा पर सहमत हुए कुछ सॉफ्टवेयर को जरूरत को पूरा करने में बदल दें।

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

इसमें आपके प्रश्न के संबंध में निम्नलिखित निहितार्थ हैं:

  • यह देखते हुए कि सॉफ्टवेयर में एक बग है, क्या आप इसे बिल्कुल ठीक करेंगे? बग को ठीक करने के लिए आपको एक प्रोग्रामर की आवश्यकता होती है, और प्रोग्रामर को पैसे खर्च करने होंगे। एक प्रोग्रामर यह तय नहीं कर सकता है कि इसे करने के लिए पैसा खर्च करना है या नहीं। यह बजट धारण करने वाले व्यक्ति की भूमिका है।
  • क्या मैं अंत में बिना फंसे बग को छोड़कर खरोंच से 20MLOC सॉफ्टवेयर बना सकता हूं? अच्छी तरह से, एक 20MLOC के निर्माण की स्थापना के लिए एक जबरदस्त धनराशि खर्च करने की आवश्यकता है। यह आर्थिक रूप से मूर्खता है। और यह एक दिन में नहीं बनाया गया है। लेकिन सॉफ्टवेयर आज की जरूरतों के लिए है, कल के लिए नहीं। बहुत सारे प्रोग्रामर को काम पर रखने के द्वारा विकास को समानांतर बनाने के लिए एक गुमराह करने की कोशिश की जाएगी । लेकिन फिर, संभावना है कि आपको एक साझा संस्कृति नहीं मिलेगी और बग्स बर्बाद हो जाएंगे, बर्बादी और देरी होगी, और उन्हें ठीक करने के लिए पैसे निकलेंगे। मैंने इस आकार का कोई बग-मुक्त सिस्टम अभी तक नहीं देखा है। (मैंने बग-मुक्त सिस्टम और 20MLOC सिस्टम देखे हैं, लेकिन वे समान नहीं थे)
  • मैं 20MLOC प्रणाली बनाए रखने का प्रभारी हूं, जो मैंने नहीं लिखा था। क्या मैं शून्य ज्ञात कीड़े तक पहुंचने में सक्षम होऊंगा? यह प्रोग्रामर पर निर्भर नहीं करता है। वे बग को ठीक करने का निर्णय नहीं ले सकते क्योंकि यह लाइन पर उनका पैसा नहीं है। क्या शेष कीड़े को ठीक करने के लिए पर्याप्त आरओआई है? ठीक है, सिस्टम पिछले कुछ समय से आसपास है, और उपयोगकर्ताओं को इसकी आदत हो गई है, और अपने दैनिक काम में अपने लाभ के लिए सिस्टम की quirks का उपयोग करते हैं। यदि आप सिद्धांत रूप से बग को ठीक करते हैं, तो पैसे वाले व्यक्ति को कुछ अनिर्दिष्ट सुविधा को पुनर्विकास करने के लिए भुगतान करना पड़ सकता है जो सिस्टम से गायब हो गया, और भी अधिक पैसे खर्च हुए।

यह सब पैसे के बारे में है, और ठीक है।


-2

हाँ।

लेकिन जैसा कि आप जानते हैं, इसके लायक होने के लिए बहुत अधिक प्रयास की आवश्यकता है।

इससे पहले कि मैं अपने जवाब का बचाव कर सकूं, हमें पहले यह परिभाषित करना चाहिए कि बग क्या है:

  • बग एक व्यवहार है जो विनिर्देशन के विपरीत है।
  • हालांकि, विनिर्देश में ग्लिच (जैसे रोबोटिक्स का 0 वां नियम) सॉफ्टवेयर बग के रूप में नहीं गिना जाता है।
  • अतिरिक्त विशेषताओं को बग के रूप में नहीं गिना जाता है, जब तक कि विनिर्देश द्वारा निषिद्ध नहीं किया जाता है।
  • तर्क के लिए, विनिर्देश के भीतर विरोधाभासों को सॉफ़्टवेयर बग के रूप में नहीं गिना जाता है।

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

"लेकिन रुकें!" मैं आपको विरोध सुनता हूं, "क्या होगा अगर एक मॉड्यूल का अप्रत्याशित (लेकिन फिर भी सही) व्यवहार दूसरे में बग का कारण बनता है?" फिर बग दूसरे मॉड्यूल में है। बग-मुक्त मॉड्यूल को एपीआई और एपीआई के रूप में माना जा सकता है, जैसा कि आप जानते हैं, सही तरीके से उपयोग करने के लिए कुछ देखभाल की आवश्यकता होती है।

बुलेट-प्रूफ कोड लिखने के लिए डेवलपर की ओर से किनारे के मामलों और प्रवाह तर्क के व्यापक ज्ञान की आवश्यकता होती है, और अधिकांश सॉफ्टवेयर डेवलपर्स या तो सीखने के लिए स्मार्ट नहीं होते हैं या बस परवाह नहीं करते हैं। या अधिक बार, वे एक समय सीमा पर हैं।

"लेकिन मुझे खड़े होने की जगह दो, और मैं दुनिया को आगे बढ़ाऊंगा।" - आर्किमिडीज


इसमें प्रयास की आवश्यकता होती है, लेकिन जो वापस भुगतान करता है।
लॉरेंट ला रिज़ज़ा

1
यदि आप स्पेसिफिकेशन बग्स को समीकरण से बाहर छोड़ देते हैं, तो आपका पूरा सॉफ्टवेयर बेकार हो जाता है: विनिर्देशों को अपेक्षाकृत औपचारिक तरीके से उपयोगकर्ता की जरूरतों को लिखने के लिए केवल उपकरण हैं, लेकिन अंत में यह उपयोगकर्ता को संतुष्ट करने की आवश्यकता है, विनिर्देश नहीं। और विनिर्देश बनाना सॉफ्टवेयर विकास का उतना ही हिस्सा है जितना कि कोड लिखना। आखिरकार, एक पूर्ण औपचारिक कल्पना प्रणाली के व्यवहार का वर्णन करेगी जैसे कि अंतिम कोड करता है, कल्पना सिर्फ कुशलता से निष्पादन योग्य नहीं है।
cmaster
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.