पैच नोट्स में बग आईडी का हवाला देते हुए इसे एक बुरा अभ्यास क्यों माना जा सकता है?

Question

बग के बाद एक टिप्पणी और बाद के उभार के आधार पर नया बनाम :

पैच नोट्स में बग आईडी का हवाला देते हुए बस .. बहुत ही अमित्र है। - झगड़ा

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

Comments

पैच नोट्स में बग आईडी का हवाला नहीं दिया गया है ... बहुत अव्यवसायिक है। एक मुद्दा पर नजर

— gnat

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

— बेन ली

Answer 1

मेरे विचार से, यह एक अच्छा अभ्यास है, यह मानते हुए कि आपके उपयोगकर्ता आपके बग डेटाबेस तक पहुँच पढ़ चुके हैं। ऐसे कई बार होते हैं जब लोग एक निश्चित बग पर इंतजार कर रहे होते हैं ताकि तय किया जा सके कि कब अपग्रेड करना है।

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

Comments

आप एक सार संदर्भ रिज़ॉल्वर, उर्फ ​​URL पुनर्निर्देशन के माध्यम से उद्धृत कर सकते हैं।

— डोनल फैलो

जैसा कि आप कहते हैं, "फिक्स्ड बग" (या समान) अनुभाग में आईडी और शीर्षक शामिल होना चाहिए ताकि पाठक को यह समझने के लिए बग को देखना न पड़े कि क्या शामिल है और क्या नहीं है।

— स्टुपरयूजर

@StuperUser - आईडी और शीर्षक, न्यूनतम पर ।

— ओडेड

जब बग या आवश्यकता आईडी सिस्टम अब उपयोग में नहीं है, तो टिप्पणियों में बग आईडी को केवल टिप्पणियों में ढूंढना कष्टप्रद है।

— jfrankcarr

Answer 2

यह है, जैसा कि उद्धृत टिप्पणी में कहा गया है ... अमित्र।

अपने आप से दोस्ती करें

निम्नलिखित परिदृश्य की कल्पना करें। आप स्रोत नियंत्रण में लॉग देख रहे हैं। आप सोच रहे हैं कि आखिर क्या बदला। इसे सादे अंग्रेजी में समझाने के बजाय, यह आपको बताता है:

हल # 1307

आप बग ट्रैकिंग सिस्टम चलाते हैं, कुछ उपयोगी होने की उम्मीद करते हैं। बग # 1307 को हल के रूप में सूचित किया गया है। विवरण में, आप देखते हैं:

समान बग # 1284

धन्यवाद, इसकी बहुत मददगार। अब आपको बग रिपोर्ट # 1284 पर नेविगेट करने के लिए पढ़ना होगा कि यह बग # 1113 का डुप्लिकेट है जो बग # 1112, # 1065 और # 1067 को संदर्भित करता है।

पांच मिनट बाद, आपको पता नहीं है कि आप शुरुआत में क्या खोज रहे हैं।

एक और अधिक उपयोगी संस्करण नियंत्रण लॉग संदेश होगा:

उपयोगकर्ताओं के साथ एक समस्या का समाधान किया जा रहा है, जो पासवर्ड के साथ 25 अक्षरों (# 1307 देखें) से अधिक समय तक पासवर्ड के साथ लॉग इन करने में असमर्थ है, उसी पासवर्ड लंबाई नीति को डेटा एक्सेस लेयर पर लागू करने से हटाकर, जैसा कि वेबसाइट में उपयोग किया गया है।

उसी तरह, बग ट्रैकिंग सिस्टम में, रिपोर्ट # 1307 अधिक आत्म-व्याख्यात्मक हो सकती है , यह याद करते हुए कि बग रिपोर्ट क्या थी # 1284 के बारे में, और नया कैसे पुराने से अलग है।

ग्राहकों के साथ मित्रता

यह केवल मित्रता का मुद्दा नहीं है।

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

यहाँ फिर से, एक संदर्भ की तुलना में अधिक विस्तृत संदेश बहुत उपयोगी हैं। ध्यान दें कि आप अभी भी संदर्भ रखना चाहते हैं: एक बग से ज्यादा कुछ भी गलत नहीं है, जो एक बग के समान है जो आपने दो सप्ताह पहले सामना किया था, लेकिन इसकी आईडी को याद न करें।

---

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

Comments

यह रिलीज़ दस्तावेज़ के साथ कोई समस्या नहीं है; यह बग में विस्तार के स्तर के साथ एक समस्या है। एक शीर्षक को वास्तविक समस्या का वर्णन करना चाहिए और प्रत्येक बग के शरीर में अपेक्षित परिणाम और वास्तविक परिणाम हैं। आपके द्वारा बताए गए बग को डुप्लिकेट के रूप में बंद नहीं किया जाना चाहिए?

— स्टुपरयूजर

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

— स्टुपरयूजर

@ स्टॉपरUser: बिल्कुल। स्पष्टीकरण प्रदान करने से उन लोगों को मदद मिलती है जो केवल यह जानना चाहते हैं कि संदर्भित सामग्री को पढ़ने के बिना दस मिनट खर्च किए बिना कमिट लॉग / पैच नोट / बग रिपोर्ट क्या है। ट्रैकिंग के लिए अभी भी आईडी की आवश्यकता होती है और जिन लोगों को बहुत विस्तृत, सटीक और पूर्ण जानकारी की आवश्यकता होती है।

— आर्सेनी मूरज़ेंको

Answer 3

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

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

Comments

"जहां पढ़ने वाला व्यक्ति नहीं जा सकता है और विवरण नहीं देख सकता है" एक ऐसे व्यक्ति के रूप में , मैं इसे वास्तव में अमित्र नहीं कहूंगा। मैंने समर्थन / देव टीम से संवाद करने के लिए इशू आईडी का उपयोग किया, जिसके पास ट्रैकर जारी करने की पहुंच थी। यह तथ्य कि यह मेरे लिए व्यक्तिगत रूप से अदृश्य था, केवल

— gnat

Answer 4

यह स्पष्ट रूप से निर्भर करता है कि पैच नोट्स पढ़ने वाले लोग कौन हैं, और सॉफ़्टवेयर के लक्षित उपयोगकर्ता।

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

बग आईडी का हवाला देकर मुझे रोकना और सोचना, और मैं - एक उपयोगकर्ता के रूप में - सोचना नहीं चाहता। यह एक प्रयोज्य मुद्दे की तरह है।

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

पुनश्च: मैं उस टिप्पणी का लेखक था जिसने सवाल को उछाला

Comments

ईमानदारी से मुझे उस लिंक के अंत में दस्तावेज़ीकरण मददगार लगता है। यह एक सारांश के साथ शुरू होता है और फिर मुझे विवरणों तक निर्देशित करता है। Microsoft अक्सर KB लेखों में एक समान लिंकिंग करता है, ऐसा नहीं है कि उनका ऐसा करना अच्छा व्यवहार करता है, लेकिन यह निश्चित रूप से व्यापक है और स्पष्ट रूप से कई उपयोगकर्ताओं को मूल्य प्रदान करता है।

— जोशुआ ड्रेक

Answer 5

एक बिंदु के संदर्भ के लिए एक बग आईडी अनिवार्य है । कारण:

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

3052 पहले से तय था, फिर भी 3077 पर काम कर रहा था

से अधिक सुविधाजनक है:

"एप्लिकेशन बटन पर एप्लिकेशन क्रैश" को ठीक किया गया था, फिर भी "चेंज यूजर पर क्लिक करने पर NullReferenceException" पर काम कर रहा था।

Comments

(१) मेनमा द्वारा सुझाए अनुसार आपको इसे संयोजित करने से क्या रोकता है? (२) आप डेढ़ तयशुदा कीड़े क्यों मार रहे हैं? 3052 तय होने के बाद आप ऐसा क्यों नहीं करते, इससे पहले कि आप 3077 पर भी काम करना शुरू करें?

— जेन्स जी

Answer 6

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

लेकिन अगर मैं एक ऐसी प्रणाली पर था जहां यह उपलब्ध नहीं है, तो मैं अभी भी टिकट आईडी (जिस तरह से आप टिकट आईडी से लॉग में जल्दी खोज सकते हैं) का उल्लेख कर सकते हैं, साथ ही बग का संक्षिप्त विवरण भी।