सॉफ्टवेयर अभी भी ज्ञात बग के साथ क्यों जारी किया गया है? [बन्द है]

Question

ऐसा लगता है कि अक्सर बड़ी परियोजनाओं में बग के साथ बग ट्रैकर को जारी किया जाता है। अब मैं फीचर अनुरोधों को समझ सकता हूं, लेकिन कई बार मैंने बड़ी संख्या में बगों को अभी भी अनसुलझा देखा है, समीक्षा नहीं की है, या समाप्त नहीं हुई है लेकिन एक रिलीज अभी भी बाहर धकेल दी गई है।

क्यों? एक खुले स्रोत परियोजना या सामान्य रूप से एक परियोजना को ज्ञात बग के साथ क्यों जारी किया जाएगा ? बग ट्रैकर 0 बग खोले जाने तक वे इंतजार क्यों नहीं करेंगे?

Comments

दुपट्टे की तरह महक।

— नौकरी '

बग के बिना हमें कुछ प्रयोग करने योग्य सॉफ़्टवेयर दिखाएं।

— जोएल एथरटन

क्योंकि समय अनंत है, लोग नहीं हैं?

— जो

इस पोस्ट के लिए धन्यवाद, इसने मुझे एक अच्छी हंसी दी ... मुझे यह देखकर आश्चर्य नहीं हुआ कि आप अपनी प्रोफ़ाइल में 18 वर्ष के हैं। : D आप स्पष्ट रूप से अभी तक सॉफ्टवेयर टीम प्रबंधकों के साथ काम नहीं किया है।

— यम मारकोविच

अधिक सामान्य कारणों में से एक: रिलीज महत्वपूर्ण कीड़े या कीड़े को ठीक करता है जो वास्तविक दुनिया के ग्राहकों को प्रभावित कर रहे हैं और कम से कम जहां तक ​​ज्ञात है, कोई नया बग नहीं जोड़ते हैं जो ऐसा करने की संभावना रखते हैं।

— डेविड श्वार्ट्ज

Answer 1

कारणों की संख्या, सहित:

1. कंपनी ने किसी विशेष समय पर रिलीज के लिए उपयोगकर्ता आधार के लिए प्रतिबद्धता बनाई थी
2. कीड़े मिशन-क्रिटिकल नहीं थे, या यहां तक ​​कि प्रमुख भी नहीं थे
3. नई सुविधा विकास को अधिक महत्वपूर्ण के रूप में देखा गया था (चाहे सही ढंग से या नहीं)

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

Comments

+1, लेकिन मैं जोड़ना चाहता हूं: 4) विचित्र अप्राप्य प्रतीत होता है कि एक बार होने वाली बग्स क्यूए लॉग करती हैं। इस प्रकार की चीजों को ट्रैक किया जाना चाहिए, लेकिन यह एक अकथनीय नेटवर्क आउटेज, अनियोजित पर्यावरण डाउनटाइम या क्यूए का परिणाम हो सकता है, बस QA ने इसके लिए संभवतः पर्याप्त डिबग होने के लिए पर्याप्त जानकारी प्रदान नहीं की। 5) मामूली बग जो हल करने के प्रयास का एक अनुपातहीन राशि लेते हैं, जैसे। एक विशिष्ट मॉड्यूल का पूरा रिफ्लेक्टर।

— maple_shaft

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

— पलक

यह भी हो सकता है कि बग्स को कंपनी द्वारा मिशन महत्वपूर्ण या प्रमुख के रूप में नहीं देखा गया था । ग्राहक अन्यथा कह सकते हैं, लेकिन आप केवल तब जानते हैं जब आपके ग्राहक आपको बताते हैं।

— joshin4colours

Answer 2

क्योंकि बग वाला सॉफ्टवेयर किसी भी सॉफ्टवेयर से बेहतर है।
एक ही कारण के लिए:

• परिवहन कंपनियां शेड्यूल बनाने में परेशान करती हैं, भले ही हमेशा देरी हो।
• फार्मास्युटिकल कंपनियां ज्ञात (और अधिकतर प्रलेखित) दुष्प्रभावों के साथ दवा बेचती हैं।
• दुनिया भर के स्कूल न्यूटोनियन भौतिकी पढ़ाते हैं, हालांकि इसकी सीमाएँ ज्ञात हैं।

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

या इसे वोल्टेयर के शब्दों के साथ कहना है: "ले मिक्स एस्ट ल'नेमी डु बिएन।"

Answer 3

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

Comments

मैं इस बात पर ध्यान दूंगा कि यदि आपका सॉफ़्टवेयर बगों से भरा हुआ है, तो किया गया प्रभाव लाभदायक नहीं हो सकता है;)

— Matthieu M.

Answer 4

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

इसलिए यह सवाल हर विकास टीम का सामना करता है जब एक रिलीज होती है: 1) बग # आई है लागत को तय करने के लायक है और अतिरिक्त मूल्य और 2) सभी खुली बग के लिए i = 0 से एन तक दोहराता है।

ध्यान रखें कि ऐसा सॉफ्टवेयर उत्पाद जो जारी नहीं किया गया है, उसका मूल्य किसी के पास नहीं है। सॉफ़्टवेयर उत्पाद जिसमें 200 बकाया बग हैं, लेकिन इसकी कार्यक्षमता का 90% काम कर रहा है, उन सभी लोगों के लिए मूल्य है जो रिलीज के समय काम करता है।

मैं किसी भी कंपनी में कभी भी किसी भी उत्पाद पर नहीं था जिसे 0 बग के साथ जारी किया गया था और मुझे लगता है कि यह पूरी तरह से सामान्य है। कुछ बिंदु पर, आप सिर्फ अपने नुकसान में कटौती करते हैं और किन कार्यों पर पूंजी लगाते हैं। अन्यथा, आप कभी भी कुछ भी जारी नहीं करेंगे।

Answer 5

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

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

Comments

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

— मलाई

Answer 6

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

Answer 7

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

Answer 8

संभावित उत्तर:

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

Answer 9

मुझे यकीन है कि आदर्श रूप से अधिकांश डेवलपर्स अपने अनुप्रयोगों में शून्य बग देखना चाहेंगे, दुख की स्थिति यूटोपिया की ऐसी स्थिति के लिए अनुमति नहीं दे सकती है।

मेरा मानना ​​है कि यह इसलिए है क्योंकि उपयोगकर्ता आधार नई सुविधाओं की मांग करता है और अतिरिक्त कार्यक्षमता के लिए एक ही या अधिक बग्स लेने के लिए तैयार है।

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

मेरे मन में कम आशावादी, संभवतः क्योंकि डेवलपर्स आलसी हैं?

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

Answer 10

सबसे सरल प्रोग्रामेटिक टेस्ट में:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

सब कुछ हमेशा एक व्यापार बंद है, चाहे वह कीड़े, समय / स्थान / स्मृति, या सुरक्षा / प्रयोज्य को ठीक कर रहा हो। ट्रेडऑफ़ गणना के बारे में सोचें जो किया गया था। आप इससे असहमत हो सकते हैं, लेकिन अगर आप इसे नहीं समझते हैं तो आप मुश्किल में हैं।

इसके अलावा, एक घंटी वक्र में उन गणनाओं के बारे में सोचें ... कुछ लोग वास्तव में दोनों तरफ खराब कर देंगे। वक्र के एक छोर के लिए ड्यूक नुकेम फॉरएवर देखें।