अनिवार्य रूप से, नहीं, लेकिन आपको वैसे भी अपना सर्वश्रेष्ठ प्रदर्शन करना चाहिए। मैं समझाता हूँ कि (या यदि आप पर्याप्त धैर्य नहीं रखते हैं तो निष्कर्ष पर जाएं)
द्विआधारी खोज के कार्यान्वयन के रूप में तुच्छ के रूप में एक समस्या पर विचार करें। एक बहुत ही लोकप्रिय कार्यान्वयन में एक बग था जो लगभग दो दशकों तक अनिश्चित हो गया था। अगर बीस लाइनों को बग-फ्री होने के लिए व्यापक रूप से उपयोग किए जाने और यहां तक कि कथित रूप से सही साबित होने के लिए बीस साल लगते हैं, तो क्या हम वास्तव में बग-फ्री होने के लिए एक विशाल कार्यक्रम की उम्मीद कर सकते हैं?
किसी भी कार्यक्रम में कितने कीड़े होने की उम्मीद कर सकते हैं? एक संख्या जो मुझे मिली वह थी "प्रति 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 गंभीर बग के लिए एक छोटी बग का परिचय देता हूं, जो कि फिक्सिंग बग को रोकने के लिए एक वैध कारण नहीं है। वास्तव में, बग को ठीक करना एक अच्छा कारण है ।
तो कम कीड़े आप को ठीक करते हैं, कम कीड़े भविष्य में आप पर वापस आएंगे
जितने कम कीड़े आप ठीक करते हैं, उतने ही कीड़े आपके सॉफ्टवेयर में बने रहेंगे, जिससे आपके उपयोगकर्ता परेशान होंगे। वास्तव में, वे "भविष्य में आपके पास वापस नहीं आएंगे"। वे वापस नहीं आएंगे क्योंकि वे पहले स्थान पर नहीं थे। "वापस आओ" की धारणा प्रतिगमन से संबंधित है। फिर से, प्रतिगमन के जोखिम को कम करना संभव है।
कुछ कीड़े तय नहीं किए जा सकते हैं क्योंकि वे इतने व्यापक रूप से उपयोग किए जाते हैं कि लोग उन पर निर्भर होने लगे और बग को ठीक करने से उन उपयोगकर्ताओं के लिए कार्यक्रम टूट जाएगा। होता है। हालांकि, क्या वास्तव में उन्हें उस मामले में कीड़े माना जा सकता है?
"एक बग को ठीक करें, एक बग बनाएं" मानसिकता उस भयानक राक्षस से संबंधित हो सकती है - कोड इतना अपठनीय और अचूक है कि केवल छूने से यह कीड़े पैदा करता है। यदि आपके पास अपने कोड बेस में एक राक्षस है, तो आपको कुछ भी करने से पहले इसे अन-मॉनीटाइज करना होगा।
अंत में, यदि आप एक भयानक प्रोग्रामर हैं, तो जोखिम है कि आप जो कुछ भी स्पर्श करते हैं वह नए कीड़े पैदा करता है। यह स्पष्ट रूप से वरिष्ठ प्रोग्रामरों को परेशान करेगा। हालांकि, "कुछ भी मत करो। कुछ भी मत छुओ। सांस भी मत लो।" शायद एक स्वस्थ कार्य वातावरण बनाने का सही तरीका नहीं है। शिक्षा बेहतर है।
निष्कर्ष:
- सॉफ्टवेयर है कि नई सुविधाओं के टन हो रही है, लेकिन कोई बग फिक्स अनिवार्य रूप से चूसना होगा।
- सॉफ्टवेयर जो नई सुविधाओं की एक मध्यम संख्या में हो जाता है, लेकिन इसके बग को ठीक कर दिया जाता है, हमारे उपयोग योग्य होने का एक बेहतर मौका होता है।
- जो कुछ कीड़े होने की कोशिश करते हैं (औसतन) उन लोगों की तुलना में कम कीड़े होते हैं जो परवाह नहीं करते हैं।
- कार्यक्रम को अंततः बग-मुक्त होने की उम्मीद करना उचित नहीं है।
- वरिष्ठ प्रोग्रामर आवश्यक रूप से सक्षम नहीं हैं।
- अपने कीड़े ठीक करो।
- अपने सॉफ्टवेयर की गुणवत्ता में सुधार करने वाले तरीकों को अपनाएं।