क्या कोड के भीतर बगफिक्स टिप्पणियों को रखना अच्छा है?

Question

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

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

सबसे अच्छा अभ्यास क्या है?

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

Comments

असली सवाल यह है कि वे ऐसा क्यों करते हैं। स्रोत नियंत्रण से पहले यह एक बहुत पुरानी प्रक्रिया हो सकती है।

@anderson - मुझे लगता है कि जब यह पेश किया गया था, तो वे क्लियरकेस का उपयोग करने के बारे में उचित समझ रखते हैं। ताकि अभ्यास आगे बढ़े ....

— शरत

पता लगाना?

के संभावित डुप्लिकेट वहाँ जब आप संस्करण नियंत्रण का उपयोग कर रहे एक "परिवर्तन लॉग" हर कोड फ़ाइल में शामिल करने के लिए एक बिंदु है?

— Péter Török

मैं यह नहीं कहूंगा कि यह एक बुरा अभ्यास है। वैसे भी सॉफ़्टवेयर गुणवत्ता माप में से एक स्रोत कोड के माध्यम से टिप्पणी प्रतिशत है।

— रूडी

Answer 1

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

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

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

Comments

बहुत बढ़िया जवाब। मैंने अपने प्रश्न में कुछ और बिंदु जोड़े हैं। कृपया अपना उत्तर जांचें और अपडेट करें। धन्यवाद। BTW, क्या आप एक विशिष्ट शाखा से कमिट लॉग प्राप्त करने के लिए क्लीयर कमांड के साथ मेरी मदद कर सकते हैं?

— शरत २६'११

@ सारथ मुझे डर है कि मैंने पहले कभी ClearCase का इस्तेमाल नहीं किया। दूर पूछने के लिए सुपरसुअर का उपयोग करने के लिए स्वतंत्र महसूस करें। मुझे यकीन है कि मदद करने के इच्छुक लोगों में बहुत सारे लोग हैं।

— डाइसैस्टर

JIRA जैसे अच्छे बग ट्रैकर आपके SCM के कमिट लॉग में देख सकते हैं और बग के लिए जानकारी निकाल सकते हैं। ज़रा सोचिए कि आप बग के लिए कुछ करते हैं, और बग ट्रैकर स्वतः बग रिपोर्ट में एक नोट जोड़ता है जो एक्स को बग के लिए संदर्भित करता है।

@Andersen - धन्यवाद हम JIRA का उपयोग कर रहे हैं। लेकिन मुझे यह सुनिश्चित करने की आवश्यकता है कि यह ठीक से उपयोग कर रहा है या नहीं।

— शरत २६'११

@ Thorbjørn आह, आपको यह आसान लगा। मुझे इसे सीवीएस / बुग्जिला कॉम्बो (और बाद में एसवीएन / बुग्जिला) के साथ मैन्युअल रूप से दिन में वापस करना पड़ा। मेरी ओर से Bugfix संदर्भ जोड़ें, और Bugzilla के लिए प्रतिबद्ध संदर्भ जोड़ें। त्रुटि प्रवण प्रक्रिया, और डेवलपर्स को एक या दूसरे को भूलने की प्रवृत्ति थी। लेकिन सूचना कई अवसरों पर बहुत काम आई।

— डिसास्टर

Answer 2

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

Comments

माना। महत्वपूर्ण मूल्य जोड़ने पर इस तरह की टिप्पणियाँ जोड़ें। हालांकि, एक हैंडल को मोड़ने के लिए उन्हें मत करो।

— जल्‍दी से जल्‍दी से

अच्छा लगा, यह टिप्पणियों का विचार बता रहा है कि "क्यों" कुछ कोड है। प्रोग्रामर

— गेब्रियल

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

— बजे एक CVn

Answer 3

बुरा अभ्यास। टिप्पणियाँ तारीख से बाहर हो जाएगा और कोड को अव्यवस्था। यदि आवश्यक हो तो जानकारी अभी भी आपके SCC सिस्टम के संस्करण इतिहास में उपलब्ध है।

Answer 4

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

Comments

यह एक गलत द्वंद्व है। जब आवश्यक हो तो आप टिप्पणी नहीं कर सकते ("यही कारण है कि हमने xy z" किया) और प्रतिबद्ध संदेशों में बग आईडी का उल्लेख करते हैं?

— मैथ्यू फ्लैशेन

यह कहां कहता है कि आप नहीं कर सकते हैं? मैं कोड में बग आईडी का उल्लेख कर रहा था, न कि वीसीएस के संदेश।

— fejd

माफ़ कीजिए मैंने गलत समझा। मुझे लगा कि आप कह रहे हैं कि बग आईडी लगाना कहीं भी उपयोगी नहीं था।

— मैथ्यू फ्लेशेन

कोई बात नहीं, इसका मतलब है कि मेरा जवाब पर्याप्त नहीं था। :)

— fejd

Answer 5

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

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

Comments

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

— जूलियन रोंकागेलिया

सहमत हैं, लेकिन सूत्रों के अनुसार इसे लागू करने का प्रयास करें: डी हमारी परियोजना टीम में हम समीक्षाओं के साथ काम कर रहे हैं, इसलिए अब उन ब्लॉकों को समीक्षक द्वारा अस्वीकार कर दिया गया है।

— रेफरी

ओह सोर्ससेफ़ ... आप और आपकी टीम के लिए खेद है।

— जूलियन रोनाग्लिया

मत बनो, इसके कुछ भी नहीं से बेहतर है। और इस समय सभी नए विकास को तोड़फोड़ के साथ किया जाता है, इसलिए हर महीने मुझे स्रोत के साथ कम करना पड़ता है।

— refro

Answer 6

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

Answer 7

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

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

vcs blame file.ext

आप उपयोगी जानकारी देख सकते हैं, आमतौर पर प्रत्येक पंक्ति को किसने बदल दिया, जब उन्होंने इसे बदल दिया, और आईडी। प्रतिबद्ध आईडी से, आप पूरा संदेश प्राप्त कर सकते हैं, जिसमें बग आईडी शामिल होना चाहिए।

अच्छा वीसीएस सिस्टम आपको एक पंक्ति को संशोधित करते समय गणना करते समय व्हाट्सएप को अनदेखा करने देगा।

मुझे नहीं पता कि इस सुविधा के लिए क्लियर केस क्या है।