जब एक ज्ञात बग को हल किया जाता है तो कहीं और नए कीड़े दिखाई देने का कारण क्या हो सकता है?

Question

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

मैं सोचने लगा कि यह कैसे हो सकता है, लेकिन इसका पता नहीं लगा सकता।

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

तो एक एकल डेवलपर द्वारा लिखित एक ताजा, छोटे आकार के कोडबेस पर इस तरह के मुद्दे का कारण क्या हो सकता है जो अपने काम पर केंद्रित रहता है ?

क्या मदद कर सकता है?

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

Comments

आह, अच्छा राजभाषा "" असफलता की लहरों का चकनाचूर "डिजाइन पैटर्न। :-)

— ब्रायन नोब्लुक

मैं इसे संपर्क की शीट में एक बुलबुले की तरह मानता हूं। इसे नीचे धक्का, यह कहीं और चबूतरे। मेरी कोडिंग

— जितनी अच्छी होगी

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

— उदयकाल

... और यह एक बुरा सपना था।

— उदयकाल

Answer 1

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

Comments

यह गरीब या कोई प्रतिगमन परीक्षण के साथ संयुक्त है

— रायथल

यह सच है, @ रयाथल, हालांकि प्रतिगमन परीक्षण उन प्रकार के कीड़ों को नहीं रोक पाएगा, बस आपको जल्द ही उनके बारे में बता देना चाहिए।

— कार्ल बेज़ेलफेल्ट

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

— bdsl

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

उम्मीद है की यह मदद करेगा।

Answer 5

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

Answer 6

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

दोनों ही मामलों में एक बेहतर स्वचालित परीक्षण आहार सहायक हो सकता है। ऐसा लगता है कि आपके सहकर्मी को वर्तमान कोड आधार का परीक्षण करने की आवश्यकता है। भविष्य में प्रतिगमन परीक्षण सत्यापित करेगा कि मौजूदा कोड कार्य करना जारी रखे हुए है।

Answer 7

अपने स्वचालित परीक्षण की चौड़ाई में सुधार करें । हमेशा कोड परिवर्तन करने से पहले परीक्षणों का पूरा सेट चलाते हैं। इस तरह, आप अपने परिवर्तनों के भयानक प्रभाव का पता लगा लेंगे।

Answer 8

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

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

Answer 9

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

तो मूल रूप से आप लगभग खुद को जवाब दिया:

• ढीला युग्मन
• परीक्षणों की कमी

बस TDD सिद्धांत (कम से कम नई सुविधाओं के लिए) को अनुकूलित करना सीखें और हर संभव स्थिति का परीक्षण करने का प्रयास करें जो हो सकता है।

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

Answer 10

मान लीजिए कि डेवलपर A ने बग के साथ कुछ कोड लिखा है। कोड बिल्कुल वैसा नहीं है जैसा कि वह करने वाला है, लेकिन कुछ अलग है। डेवलपर B ने वह कोड लिखा है जो A के कोड पर निर्भर करता है, जो वास्तव में यह करने के लिए विशिष्ट है, और B का कोड काम नहीं करता है। बी जांच करता है, ए के कोड में गलत व्यवहार पाता है, और इसे ठीक करता है।

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

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