यदि बग 5+ वर्ष पुराना है, तो क्या यह एक विशेषता है? [बन्द है]


18

मुझे विवरण जोड़ने की अनुमति दें: मैं संस्थागत स्थान पर कई कोडर, परीक्षक, क्यूए विश्लेषकों, उत्पाद मालिकों, आदि के साथ काम करता हूं और यहां कुछ ऐसा है जो मुझे परेशान करता है:

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

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

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

मुझ में युवा कोडर सोचता है: इस अजीब बात को फिर से लिखना! जैसा कि किसी के पास बिक्री, ग्राहकों के करीब होने का अवसर था, मैं इस दृष्टिकोण के लिए संदेह का लाभ देना चाहता हूं।

मुझे आपकी राय / अनुभव में भी दिलचस्पी है। कृपया जोखिम, लागत-से-लाभ और अन्य गैर-तकनीकी कारकों पर विचार करने का प्रयास करें।


2
मुझे लगता है कि आपका मतलब है "... इस तरह से काम किया है।"
प्याज-नाइट

कभी दोबारा मत लिखो। जब तक खुद पर इसका पतन नहीं हो जाता (आप अधिक टूटती चीजों को नहीं जोड़ सकते) तब आप और अधिक बग का

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

जवाबों:


14

मै तुम्हारा दर्द समझ सकता हू।

लेकिन कुछ ठीक करना क्योंकि यह एक बग है एक अच्छा पर्याप्त कारण नहीं है।

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

बहुत सारे प्रसिद्ध उदाहरण हैं जहां एक पुरानी प्रणाली को बदलने के लिए नया कोड लिखा गया था। जहां उन्हें पुरानी प्रणाली में बग की कार्यक्षमता को स्पष्ट रूप से जोड़ना था क्योंकि उपयोगकर्ता उस बग पर निर्भर थे (नाम नहीं जा रहे हैं लेकिन मुझे यकीन है कि आप इसे Google कर सकते हैं)।

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


प्रतिगमन परीक्षण भाग सही है कि आप वास्तव में परीक्षण कवरेज के उचित स्तर को जानते हैं।
पेमदास

दूसरी ओर, यदि आप एक जीयूआई कोड करते हैं, तो कम निर्भरताएं हैं; उपयोगकर्ता अधिक आसानी से विकसित होते हैं।
मैथ्यू एम।

@ माथिउ एम .: बिल्कुल। आदतों को बदलना आसान है (जब तक आप आदतों को ठीक करने में निवेश करते हैं) स्वचालित प्रणालियों के (बहुत सारे) को ठीक करना है (जिनमें से अधिकांश लोग पीछे के कमरे में भूल गए होंगे)।
मार्टिन यॉर्क

3

बग को ठीक करने के बारे में विचार करने के लिए कुछ चीजें ... किसी भी तरह से सभी समावेशी नहीं।

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

संभावित ग्राहकों को खोने पर - जो मेरे लिए कठिन है, और यहां तक ​​कि बिक्री / विपणन के लिए भी पता है, लेकिन अवधारण दर अधिक है (हालांकि स्विचिंग की लागत अधिक है)। यकीनन आप शायद ही जान सकते हैं कि क्या आप A को B के विपरीत करने से बेहतर हैं, जब तक कि आप A / B परीक्षण ठीक से नहीं कर रहे हैं।
जॉब

1
मुझे यकीन नहीं है कि यह आपके मामले में कितना लागू होता है, लेकिन हम अक्सर (एक बार एक चौथाई) हमारे बिक्री इंजीनियरों के साथ एक बैठक करते हैं ताकि क्षेत्र में उन मुद्दों पर चर्चा की जा सके जिन्होंने उन्हें बिक्री करने से रोका है। इसमें लापता विशेषताएं शामिल हो सकती हैं, या उपयोगकर्ता इंटरैक्शन के दृष्टिकोण से कुछ बुरी तरह से काम करता है ... ect।
पेमदास

3

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

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

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

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


2

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.