किसी ज्ञात बग के साथ उत्पाद को जहाज करना कब ठीक है?

Question

किसी ज्ञात बग के साथ उत्पाद को जहाज करना कब ठीक है?

Comments

सवाल शायद बहुत व्यापक है। कारण अनंत हैं।

— jmq

सवाल यह है: कीड़े के साथ जहाज या बिल्कुल भी नहीं जहाज :)

— Vitor Py

सभी उत्पादों कीड़े के साथ जहाज।

— जोएल एथर्टन

BUG को परिभाषित करें। हमने हाल ही में एक ऐसा उत्पाद भेजा है जो स्थापित नहीं होगा। महान बग: डी

— बारफील्डम

क्या आपका मतलब है 'ज्ञात कीड़े'?

— कोई भी

Answer 1

मुझे लगता है कि आप एक "ज्ञात" बग की बात कर रहे हैं (प्रश्न अन्यथा अर्थहीन है)। खैर, जवाब इन कारकों पर निर्भर करता है:

1) उपयोगकर्ता कौन है और वह कैसे पाया जाता है यदि वह बग को स्वीकार करता है?

2) बग का संभावित प्रभाव (क्षति) क्या है?

3) क्या बग को ठीक करने के लिए सॉफ़्टवेयर के शिपमेंट में देरी करना संभव है?

4) सबसे महत्वपूर्ण: आप अपने सॉफ़्टवेयर से क्या उम्मीद करते हैं? बाजार के लिए समय? गुणवत्ता? क्या आप यह देखना चाहते हैं कि आपके ग्राहक बग को खोजने के लिए सॉफ्टवेयर का लंबे समय तक उपयोग करते हैं या नहीं?

Answer 2

इसे हमेशा ओके करना होगा, क्योंकि बगलेस सॉफ्टवेयर जैसी कोई चीज नहीं है।

Comments

लेकिन ऐसा लगता है कि वह बग से अवगत है ... इसलिए उस समय ऐसा लगता है कि एक प्रोग्रामर इसे ठीक नहीं करने के लिए आलसी हो रहा है ...

— केनेथ

@ केनेथ: आप इसे इस तरह देख सकते हैं, लेकिन उत्पादों को भेजना होगा, और उनके पास हमेशा कीड़े होंगे। यह बग की गंभीरता पर निर्भर करेगा कि क्या आप अपनी समय सीमा पर रहते हैं।

— मैट एलेन

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

— केनेथ

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

— असंतुष्टगीत

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

— कोडेक्सआर्कनम

Answer 3

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

इसलिए इसे लागत / लाभ के दृष्टिकोण से देखें।

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

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

जोखिमों में एक नई समस्या शुरू करने का जोखिम शामिल है, न केवल बग को ठीक करने में, बल्कि ऐसी चीजें भी हैं जो एक नई स्थापना बनाने से उत्पन्न हो सकती हैं।

बग को रिपोर्ट करने वाले ग्राहकों और प्रतिष्ठा की क्षति जैसी चीजों से निपटने में समय और प्रयास दोनों का नकारात्मक प्रभाव पड़ता है।

Comments

'के बारे में' बॉक्स में एक टाइपो कुछ ऐसा है जिसे आपको वास्तव में ठीक करना चाहिए। इसमें लगभग 0.7 सेकंड का समय लगेगा (हम दोनों को एक ही गति से टाइप करते हैं)। हालाँकि यदि आप उस टाइपो को छोड़ देते हैं, तो लोग इसे देख सकते हैं । यदि उपयोगकर्ता इंटरफ़ेस में दृश्यमान गलतियाँ हैं, तो यह आपके सॉफ़्टवेयर में आपके उपयोगकर्ताओं के विश्वास के लिए तत्काल मृत्यु है।

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

— ग्लेनट्रॉन

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

— फॉशी

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

— चाओसपांडियन

मुझे नहीं पता कि आप क्या बात कर रहे हैं ...?)

— एंड्रियास जोहानसन

Answer 4

कीड़े अलग-अलग गंभीरता में आते हैं। किसी भी सॉफ्टवेयर कंपनियों में मैंने काम किया है हमने P0 से P4 तक प्राथमिकता के क्रम में कीड़े को वर्गीकृत किया है।

P0 क्या सॉफ्टवेयर काम नहीं करता / क्रैश करता है और ग्राहकों के व्यवसाय को नुकसान पहुंचा सकता है। P1 यह डिजाइन के रूप में काम नहीं कर रहा है और कोर कार्यक्षमता में लगातार क्रैश होता है P2 यह कभी-कभी क्रैश हो जाता है और या साइड कार्यक्षमता का एक टुकड़ा काम नहीं कर सकता है। P3 सॉफ़्टवेयर का कुछ तत्व डिज़ाइन किए गए / अपेक्षित P4 कॉस्मेटिक समस्या के रूप में काम नहीं कर रहा है।

मैंने उन जगहों पर काम किया है जहां पी 4 की बस ठीक नहीं होती है क्योंकि सॉफ्टवेयर पर उनका इतना कम प्रभाव होता है।

यदि आपका सॉफ़्टवेयर P3 / P4 मुद्दों को जानता है, तो मैं इसे शिप करना ठीक हूं, मैं इसे रिलीज़ नोटों में रखूंगा और ध्यान दूंगा कि उन पर काम किया जा रहा है।

मैं एक P0, P1 या P2 मुद्दे के साथ सॉफ्टवेयर जारी नहीं करूंगा, जिसके बारे में मुझे पता था।

Answer 5

इसे " ज्ञात समस्या " कहा जाता है । Google, Microsoft, Apple, आदि सभी जहाज उत्पादों को बग के साथ जानते हैं और अज्ञात दोनों हैं। उन्हें कम से कम करने की कोशिश करें, लेकिन पूर्णता की प्रतीक्षा न करें। जहाज तेज, जहाज अक्सर।

Answer 6

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

Answer 7

जब यह एक "सुविधा" है! ;)

---

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

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

Answer 8

जब तक आप अपने ग्राहकों के प्रति ईमानदार होते हैं तब तक आप बग के साथ जहाज बना सकते हैं। सभी मौजूदा बग्स के बारे में बताने से उन्हें पता चलता है कि आपको अपने सॉफ़्टवेयर के बारे में अच्छी जानकारी है, और यह वास्तव में अच्छी तरह से परखा हुआ है (यदि यह है ..)। :)

जाहिर है सबसे अच्छी बात कीड़े के साथ शिपिंग से बचने के लिए है।

Answer 9

यह समय पर उत्पाद जहाज रखने के लिए अक्सर बेहतर होता है, ज्ञात मुद्दों की सूची के साथ, बिल्कुल भी जहाज नहीं।

प्रोग्रामिंग दुनिया है कि एक परियोजना में लोगों को यह विश्वास देता है में चीज़ों में से एक है कि वे रिलीज के लिए कि क्या है अनुसूचित और समय है कि क्या रखती है ।

यही कारण है कि उबंटू जहाज हर आधे साल जारी करते हैं, भले ही अभी भी खुले मुद्दे हों।

Answer 10

मैं कहूंगा कि अंगूठे का एक अच्छा नियम है, "क्या यह बग एक शोस्टॉपर है?"

यदि बग "ख़ुशी-पथ परिदृश्य" को विफल करने का कारण बनता है, तो बिल्कुल उस बग के साथ जहाज न करें।

यदि बग विफल होने के लिए "स्पर्शरेखा-से-खुशहाल परिदृश्य" का कारण बनता है और कोई वर्कअराउंड नहीं है, तो उस बग के साथ जहाज न करें।

यदि किसी बग को प्रलेखित किया गया है और कोई ज्ञात समाधान है, तो संभवतः उस बग के साथ जहाज करना ठीक है।

Answer 11

उपभोक्ताओं की दृष्टि से ... कभी नहीं। मेरी बात यह है कि जब तक आप जानते हैं कि सॉफ्टवेयर में एक प्रमुख बग है तब आपको इसे कभी भी शिप नहीं करना चाहिए। हालांकि प्रकृति की ताकतें (व्यवसाय) इसे ओवरराइड करती हैं यदि सॉफ्टवेयर का उत्पादन चक्र अब उस स्तर पर है जहां यह व्यवसाय मॉडल को नुकसान पहुंचा सकता है और वे मामूली कीड़े हैं जो अभ्यस्त नहीं हैं: (i) सॉफ़्टवेयर की सुरक्षा से समझौता (ii) प्रभाव प्रयोज्य

Answer 12

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

Answer 13

FMEA (विफलता मोड और प्रभाव विश्लेषण) नामक कुछ ऐसा है जो यह तय करना बहुत उपयोगी है कि एक ज्ञात बग महत्वपूर्ण है या नहीं आधारित है:

1. घटना
2. तीव्रता
3. खोज

Answer 14

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

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

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