ऐतिहासिक उद्देश्यों के लिए कोड पर टिप्पणी करने के विकल्प

Question

क्या किसी के पास खोजने योग्यता कारणों के लिए भंडार में चेक किए गए टिप्पणी कोड का उपयोग करने के लिए एक वैध विकल्प है?

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

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

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

केवल विकल्प मैं के बारे में सोच सकते थे:

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

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

भयानक शीर्षक के लिए क्षमा करें, मैं एक बेहतर एक

Answer 1

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

Answer 2

मैं समझता हूं कि कोड अब उपयोग नहीं किया गया है, लेकिन इसमें ऐसे विचार शामिल हैं जो भविष्य के लिए दिलचस्प हो सकते हैं।

मैं नियंत्रण संस्करण प्रणाली में स्टोर करता हूं लेकिन मैं इसे एक अलग फ़ोल्डर में रखूंगा, जैसे removed-code-to-review-later। फिर, मैं इसे हटा दूंगा क्योंकि मैं इसकी समीक्षा करता हूं।

Answer 3

ब्रांचिंग यहां उपयोगी हो सकती है। एससीएम का उपयोग करने का एक मॉडल प्रत्येक सुविधा के लिए एक शाखा बनाना है। यह लोकप्रिय है जब शाखा विलय दर्द रहित है - आसानी से सभी एससीएम द्वारा बर्दाश्त नहीं किया जाता है ... :-)

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

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

के विपरीत टिप्पणी की कोड, इन जांच कोड में परिवर्तन कोड विश्लेषण उपकरण, रिफैक्टरिंग आदि

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

खोज के रूप में, कुछ एससीएम के पास एक खोज फ्रंट-एंड होता है। उदाहरण के लिए, एसवीएन में एसवीएनएसएआर - http://sourceforge.net/projects/svn-search/ है। svnquery भी है, जो इतिहास और साथ ही सिर खोज सकता है।

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

बाहर टिप्पणी की कोड वह अभी भी में जाँच कुछ काम वह भविष्य में ठीक करने के लिए चाहते हैं सचित्र के कुछ

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

टिप्पणी की गई कोड किसी भी अन्य टिप्पणी की तरह है: अगर सही तरीके से बनाए रखा नहीं जाता है तो यह कोड के साथ इसकी स्थिरता खो देता है और इस प्रकार इसकी उपयोगिता।

Answer 7

आपका कथन "भले ही यह वर्तमान में संकलित नहीं होगा, फिर भी यह वैश्विक लाइनों में इसे हल करने का सही तरीका दिखाता है।"

<>

अपने बयान "मेरे तर्क है कि बाहर टिप्पणी की कोड वैसे भी बेकार है।"

मुझे टिप्पणियां छोड़ने में हानि दिखाई नहीं देती है, क्योंकि वे अक्सर मूल डेवलपर्स के इरादे पर मौजूदा डेवलपर्स के इरादे पर अंतर्दृष्टि प्रदान करेंगे, और मौजूदा कोड में कोई मौजूदा सीमाएं। एक अलग प्रणाली में भंडारण इस अवसर को बढ़ाता है कि वे भविष्य के डेवलपर्स के लिए खो जाएंगे। बाइट सस्ते हैं, एक और डेवलपर्स इरादा बनाने के लिए जो समय लगता है वह $$$ है।