सैद्धांतिक रूप से बग-मुक्त कार्यक्रम

12

मैंने बहुत से लेख पढ़े हैं जो बताते हैं कि कोड बग-मुक्त नहीं हो सकता है, और वे इन प्रमेयों के बारे में बात कर रहे हैं:

दरअसल राइस का प्रमेय हॉल्टिंग समस्या के एक निहितार्थ जैसा दिखता है और हॉल्टिंग समस्या गोडेल के अपूर्णता प्रमेय के साथ घनिष्ठ संबंध में है।

क्या इसका मतलब यह है कि हर कार्यक्रम में कम से कम एक अनपेक्षित व्यवहार होगा? या इसका मतलब यह है कि इसे सत्यापित करने के लिए कोड लिखना संभव नहीं है? पुनरावर्ती जाँच के बारे में क्या? मान लेते हैं कि मेरे दो कार्यक्रम हैं। दोनों के पास कीड़े हैं, लेकिन वे एक ही बग को साझा नहीं करते हैं। अगर मैं उन्हें समवर्ती रूप से चलाऊंगा तो क्या होगा?

और निश्चित रूप से ज्यादातर चर्चा ट्यूरिंग मशीनों के बारे में हुई। लीनियर-बाउंड ऑटोमेशन (वास्तविक कंप्यूटर) के बारे में क्या?

bug theory

— user2443423
स्रोत

10

मुझे पूरा यकीन है कि यह अजगर कार्यक्रम वह सब कुछ करता है जो इसे करने का इरादा है और अधिक नहीं: print "Hello, World!"... क्या आप थोड़ा अधिक स्पष्ट हो सकते हैं?

— डुर्रोन 597

2

@ durron597: क्या इस तरह के सॉफ्टवेयर के लिए कोई बाजार है? हैलो वर्ल्ड प्रिंटर, पुनः लोड किया गया संस्करण? अब और अधिक नरक और अधिक दुनिया के साथ?

— जेन्सजी

1

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

— डुर्रोन 597

2

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

— डोभाल

11

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

— चार्ल्स ई। ग्रांट

18

यह इतना नहीं है कि कार्यक्रम बग-मुक्त नहीं हो सकते हैं; यह है कि यह साबित करना बहुत मुश्किल है कि वे हैं, यदि आप जिस कार्यक्रम को साबित करने की कोशिश कर रहे हैं वह गैर-तुच्छ है।

कोशिश की कमी के लिए नहीं, तुम मन हो। टाइप सिस्टम कुछ आश्वासन प्रदान करने वाले हैं; हास्केल में एक उच्च-परिष्कृत प्रकार की प्रणाली है जो एक हद तक ऐसा करती है। लेकिन आप कभी भी अनिश्चितता को दूर नहीं कर सकते।

निम्नलिखित कार्य पर विचार करें:

int add(int a, int b) { return a + b; }

इस समारोह में क्या गलत हो सकता है? मुझे पहले से ही पता है कि तुम क्या सोच रहे हो। मान लीजिए कि हमने सभी आधारों को कवर कर लिया है, जैसे अतिप्रवाह के लिए जाँच करना, अगर कोई कॉस्मिक किरण प्रोसेसर से टकराती है तो क्या होता है, जिससे यह निष्पादित होता है

LaunchMissiles();

बजाय?

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

मैं जानता हूं तुम क्या सोच्र रहे हो। "लेकिन मैं सॉफ्टवेयर की बात कर रहा हूं, हार्डवेयर की नहीं।"

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

क्यों? क्योंकि आपके पास इन चीजों को एज केस कहा जाता है ।

और एक बार जब आप सादगी से थोड़ा आगे निकल जाते हैं return a + b, तो प्रोग्राम की शुद्धता को साबित करना मुश्किल हो जाता है ।

इसके अलावा पढ़ना
वे एरियन 5 धमाका सही स्टफ लिखते हैं

— रॉबर्ट हार्वे
स्रोत

6

पूरी तरह से सही फ़ंक्शन पर विचार करें: int add(int a, int b) { return a - b; }...

— डोनल फेलो

@ डोनल फेलो: जो वास्तव में कारण है जिसमें मैंने एरियन 5 के बारे में लिंक शामिल किया है

— रॉबर्ट हार्वे

2

@ डोनल फेलो - गणितीय लक्षण वर्णन समस्या को हल नहीं करता है, यह केवल इसे कहीं और ले जाता है। आप कैसे साबित करते हैं कि गणितीय मॉडल वास्तव में ग्राहक की आवश्यकता का प्रतिनिधित्व करता है?

— मौवीसील

1

@ जॉनघन ने कहा कि मॉड्यूल के बीच अन्योन्याश्रयता है। ऐसे मॉड्यूल जिन्हें सही और एक-दूसरे से स्वतंत्र साबित किया गया है, को देखते हुए, आप उन्हें पुन: बड़े मॉड्यूल में पुन: रचना कर सकते हैं जिन्हें सही और स्वतंत्र विज्ञापन इन्फिनिटम भी कहा जाता है।

— डोभाल

1

@ जॉनघन अगर मॉड्यूल का एकीकरण बग का कारण बनता है तो आप यह साबित करने में विफल रहे हैं कि वे स्वतंत्र हैं। नए सबूतों को स्थापित प्रमाणों से बनाना किसी भी तरह से स्वयंसिद्ध सबूतों के निर्माण से कठिन नहीं है। अगर गणित तेजी से कठिन हो गया, तो गणितज्ञों पर शिकंजा कसा जाएगा। आपकी बिल्ड स्क्रिप्ट में बग हो सकते हैं, लेकिन यह एक अलग कार्यक्रम है। कोई भी ऐसा गुप्त तत्व नहीं है जो गलत हो जाए जब आप चीजों की रचना करने की कोशिश करते हैं, लेकिन दुष्प्रभावों की संख्या के आधार पर यह साबित करना मुश्किल हो सकता है कि कोई साझा स्थिति नहीं है।

— डोभाल

12

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

मैंने बहुत सारे लेख पढ़े हैं जो बताते हैं कि कोड बग-मुक्त नहीं हो सकता है

मुझे उम्मीद है कि नहीं, क्योंकि ऐसा बयान गलत है। हालांकि यह आमतौर पर स्वीकार किया जाता है कि अधिकांश बड़े पैमाने पर अनुप्रयोग मेरे ज्ञान और अनुभव के लिए बग-मुक्त नहीं हैं ।

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

एक गैर-सबूत हाल्टिंग समस्या का एक सहज विस्तार है, जिसे हर रोज के अनुभव के अवलोकन डेटा के साथ जोड़ा जाता है।

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

क्या इसका मतलब यह है कि हर कार्यक्रम में कम से कम एक अनपेक्षित व्यवहार होगा?

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

या इसका मतलब यह है कि इसे सत्यापित करने के लिए कोड लिखना संभव नहीं है?

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

अधिक विवरण के लिए, देखें कि Coq एक ऐसा उपकरण / भाषा / प्रणाली है।

पुनरावर्ती जाँच के बारे में क्या?

मुझे नहीं पता। मैं इससे परिचित नहीं हूं, और मुझे यकीन नहीं है कि यह एक संगणना समस्या या संकलक अनुकूलन समस्या है।

— mctylr
स्रोत

1

औपचारिक विनिर्देशों और प्रमाण सहायकों के बारे में पहली बात करने के लिए +1। यह एक महत्वपूर्ण बिंदु है, जो पिछले उत्तरों में गायब है।

— आर्सेनी मूरज़ेंको

6

मैं पूछना चाहता हूं, क्या इसका मतलब यह है कि हर कोड को कम से कम एक अनपेक्षित व्यवहार मिलेगा?

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

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

या, क्या इसका मतलब है कि मैं कोड लिखने में सक्षम नहीं हूं, जो इसकी जांच करेगा?

ऊपर दिए गए बयान में सामान्य मामले का संदर्भ लें और आप सही हैं।

आप एक प्रोग्राम लिखने में सक्षम हो सकते हैं जो यह जांचता है कि क्या कोई विशिष्ट X प्रोग्राम सही है। उदाहरण के लिए, यदि आप एक "हैलो वर्ल्ड" प्रोग्राम को अनुक्रम में दो निर्देशों के साथ एक के रूप में परिभाषित करते हैं, अर्थात् print("hello world")और exit, आप एक प्रोग्राम लिख सकते हैं जो यह जांचता है कि क्या उसका इनपुट अनुक्रम में इन दो निर्देशों से बना एक प्रोग्राम है, इस प्रकार रिपोर्टिंग यदि यह एक है सही "हैलो वर्ल्ड" कार्यक्रम या नहीं।

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

— थियागो सिल्वा
स्रोत

4

एक ही प्रोग्राम के दो या दो से अधिक वेरिएंट चलाने से एन-वेरिएंट (या एन-संस्करण) प्रोग्रामिंग नामक एक प्रसिद्ध दोष सहिष्णुता तकनीक है। यह सॉफ्टवेयर में बग की मौजूदगी की एक स्वीकारोक्ति है।

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

दो कमजोर लिंक बने रहते हैं, सामान्य मोड बग के लिए अग्रणी:

केवल एक विनिर्देश है।
मतदान प्रणाली या तो अद्वितीय है या जटिल है।

— mouviciel
स्रोत

5

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

— mctylr

@mctylr - यह बहुत अच्छी बात है। लेकिन वास्तव में, हाल ही में, एक अंतरिक्ष यान पर एक सॉफ्टवेयर के एक से अधिक प्रकार को संग्रहीत करने के लिए स्मृति में पर्याप्त जगह नहीं थी। उनका जवाब परीक्षण, परीक्षण, परीक्षण, कुल्ला, दोहराना है।

— मौविइल

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

4

एक कार्यक्रम के कुछ विनिर्देश हैं और कुछ वातावरण में चलते हैं।

^{(बदलते दूसरों जवाब में कॉस्मिक किरण उदाहरण addके लिए FireMissiles सोचा जा सकता है "पर्यावरण" का हिस्सा)}

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

विशेष रूप से, आप ध्वनि स्थिर स्रोत विश्लेषक का उपयोग कर सकते हैं, जैसे कि Frama-C ।

^{(लेकिन इस तरह के विश्लेषणकर्ताओं की कला की वर्तमान स्थिति पूरे कार्यक्रम विश्लेषण और जीसीसी संकलक या फ़ायरफ़ॉक्स ब्राउज़र या लिनक्स कर्नेल जैसे बड़े पैमाने पर कार्यक्रमों के प्रमाण की अनुमति नहीं देती है; और मेरा विश्वास है कि इस तरह के प्रमाण मेरे जीवनकाल में नहीं होंगे ; । मैं 1959 में पैदा हुआ था)}

हालाँकि, आपने जो साबित किया है, वह प्रोग्राम के सही व्यवहार है, जो कुछ विशेष (कुछ) वातावरण (वर्ग) में कुछ विशेष विनिर्देश प्रदान करता है।

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

सरल शब्दों में, यदि आपका अंतरिक्ष यान रोबोट कुछ ET से मिलता है और आपने यह निर्दिष्ट नहीं किया है, तो आपके रोबोट के साथ ऐसा व्यवहार करने का कोई तरीका नहीं है जैसा आप वास्तव में चाहते हैं ...।

J.Pitrat की ब्लॉग प्रविष्टियाँ भी पढ़ें ।

BTW, हॉल्टिंग समस्या या गोडेल की प्रमेय संभवतः मानव मस्तिष्क, या यहां तक कि मानव प्रजातियों पर भी लागू होती है।

— बेसाइल स्टारीनेवविच
स्रोत

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

— डेविड हैमेन

3

क्या इसका मतलब यह है कि हर कार्यक्रम में कम से कम एक अनपेक्षित व्यवहार होगा?

नहीं।

रुकने की समस्या कहती है कि यह एक प्रोग्राम लिखना असंभव है जो परीक्षण करता है कि क्या प्रत्येक कार्यक्रम एक सीमित समय में रुकता है। इसका मतलब यह नहीं है कि एक प्रोग्राम को लिखना असंभव है जो कुछ कार्यक्रमों को रोकने के रूप में वर्गीकृत कर सकता है, कुछ को गैर-ठहराव के रूप में। इसका मतलब यह है कि हमेशा कुछ कार्यक्रम मौजूद रहेंगे जो एक रोकने वाला विश्लेषक एक तरह से या दूसरे को वर्गीकृत नहीं कर सकता है।

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

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

नोट: औपचारिक विधियाँ एक ब्रह्मांडीय किरण की संभावना को बढ़ाती हैं और प्रोसेसर के launch_missiles()बजाय क्रियान्वित होती हैं a+b। वे वास्तविक मशीनों के बजाय एक अमूर्त मशीन के संदर्भ में कार्यक्रमों का विश्लेषण करते हैं जो रॉबर्ट हार्वे के कॉस्मिक किरण जैसे एकल घटना अपसेट के अधीन हैं।

— डेविड हैमेन
स्रोत

1

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

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

राइस के प्रमेय के साथ भी यही सच है। हां, किसी भी कार्यक्रम की गैर-तुच्छ संपत्ति के लिए हम एक ऐसा कार्यक्रम लिख सकते हैं जिसमें न तो वह संपत्ति सही साबित हो सकती है और न ही गलत; हम इस तरह के कार्यक्रम को लिखने से भी बच सकते हैं क्योंकि हम यह निर्धारित करने में सक्षम हैं कि क्या कोई कार्यक्रम साबित हो सकता है।

— जूल्स
स्रोत

0

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

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

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

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

अंत में, एप्लिकेशन / सिस्टम की श्रृंखला जो डेटा का उपभोग करती है, जो उसके तर्क को खिलाती है, वे सभी तर्क के भीतर या तो संभावित बग के स्रोत हैं, या सॉफ़्टवेयर के भीतर लॉजिक की सवारी करने वाले शीर्ष पर, या अपस्ट्रीम सिस्टम, जिसमें वह डेटा का उपभोग करता है।

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

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

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

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

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

— थॉमस कार्लिस्ले
स्रोत

-2

मेरा मानना है कि कोड कभी भी 100% बग मुक्त है क्योंकि कोड कभी भी समाप्त नहीं होता है। आप जो लिखते हैं उस पर हमेशा सुधार कर सकते हैं।

प्रोग्रामिंग विज्ञान और गणित का एक क्षेत्र है, जिसमें दोनों अंतहीन हैं। डेवलपर होने के बारे में बड़ी बात यह है कि हमारा काम अंतहीन है।

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

तो क्या कोड कुशल हो सकता है? हाँ।
क्या कोड अंतहीन रूप से अनुकूलित किया जा सकता है? हाँ।
क्या कोड बग मुक्त हो सकता है? नहीं, आपने अभी-अभी इसे तोड़ने का कोई तरीका नहीं खोजा है।
यह कहा जा रहा है, यदि आप अपने आप को और अपने कोड लेखन प्रथाओं को बेहतर बनाने का प्रयास करते हैं, तो आपके कोड को तोड़ना मुश्किल होगा।

— होम्स
स्रोत

इस पोस्ट को पढ़ना मुश्किल है (पाठ की दीवार)। क्या आप बेहतर आकार में आईएनजी को संपादित करेंगे ?

— gnat