"बाहर टिप्पणी" कोड में जाँच [बंद]


94

ठीक है, यहाँ कुछ ऐसा है जिसने मेरी वर्तमान नौकरी पर कुछ घर्षण पैदा किया है और मुझे वास्तव में इसकी उम्मीद नहीं थी। घर में सॉफ्टवेयर डेवलपमेंट का आयोजन एक नई अवधारणा है और मैंने कुछ कोडिंग दिशानिर्देशों का पहला मसौदा तैयार किया है।

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

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

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

वैसे भी, आपके विचार क्या हैं? क्या आप मानते हैं कि "टिप्पणी" कोड का भंडार में उपयोगी है?

मुझे इस विषय पर दूसरों से सुनना बहुत पसंद है।

संपादित करें: स्पष्टता के लिए, हम निजी शाखाओं का उपयोग नहीं करते हैं। अगर हमने किया तो मैं कहूंगा कि आप अपनी निजी शाखा के साथ क्या चाहते हैं, लेकिन ट्रंक या किसी भी साझा शाखाओं के साथ कोड का विलय नहीं किया है।

संपादित करें: कोई वैध कारण नहीं है कि हम निजी या प्रति उपयोगकर्ता शाखाओं का उपयोग न करें। यह एक अवधारणा नहीं है जिससे मैं असहमत हूं। हमने अभी तक इसे इस तरह सेट नहीं किया है। शायद यही बीच का रास्ता है। अभी के लिए हम TFS शेलिंग का उपयोग करते हैं।


2
सुनिश्चित करें कि आप अपने डेवलपर्स को टीएफएस के उचित उपयोग पर पूरी तरह से प्रशिक्षित करते हैं। मेरे कार्यसमूह में टीएफएस के साथ महत्वपूर्ण समस्याएं हैं और जिसके परिणामस्वरूप मेरे लिए कोड-नुकसान हुआ है। मई "ID10T" त्रुटि हुई है, लेकिन मुझे अभी भी TFS पर भरोसा नहीं है।
जेम्स स्कैच

@ जॉन: किसी भी कारण से आप निजी शाखाओं की अनुमति नहीं देते हैं? इससे समस्या का समाधान होगा, वह खुशी-खुशी वहां जमा हो सकता है और कुछ भी बचा सकता है, और आप मुख्य शाखा में बिल्कुल भी परेशान नहीं होंगे।
फ्रैंक

@null - जैसा कि संपादन में बताया गया है, मुझे उनसे कोई समस्या नहीं है, हमने अभी तक ऐसा नहीं किया है। इस परिदृश्य में समस्या यह है कि हम एक निजी शाखा से जारी नहीं करेंगे और वह एक आंशिक समाधान तैनात करना चाहते हैं।
जॉन


जवाबों:


123

विभिन्न अनुभवों के साथ अन्य भी हो सकते हैं, लेकिन आधे-अधूरे कोड में खदान की जाँच एक भयानक विचार है, अवधि।

यहां वे सिद्धांत हैं जिन्हें मैंने सीखा है और उनका पालन करने की कोशिश करता हूं:

  • अक्सर जाँच करें - कम से कम एक बार, लेकिन अधिमानतः प्रति दिन कई बार
  • केवल पूर्ण कार्यक्षमता में जांच करें
  • यदि पहला और दूसरा संघर्ष (जैसे कि कार्यक्षमता कार्य करने के लिए एक दिन से अधिक समय लगता है) तो कार्य बहुत बड़ा है - इसे छोटे पूर्ण कार्यों में तोड़ दें।

इसका मतलब है की:

  • टिप्पणी-आउट कोड को कभी भी जांचना नहीं चाहिए क्योंकि यह कार्यात्मक नहीं है
  • टिप्पणी करना एक मान्य अभिलेखीय रणनीति नहीं है, इसलिए चाहे यह कोड अभी तक समाप्त हो गया हो या ऐसा कोड जिसे सेवानिवृत्त किया जा रहा हो, टिप्पणी करना और जांचना किसी भी मायने में नहीं है।

तो सारांश में, नहीं! यदि कोड अगले चरण में जाने के लिए तैयार नहीं है (जो भी आपके लिए है: IntTest / QA / UAT / PreProd / Prod), यह एक ट्रंक या मल्टी-डेवलपर शाखा के लिए प्रतिबद्ध नहीं होना चाहिए। अवधि।

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

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


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

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

2
@Rex M: IMO, टिप्पणियाँ कोड का एक अनिवार्य हिस्सा हैं। मेरे द्वारा बनाए गए किसी भी कोड में, टिप्पणियों को बाकी कोडबेस के साथ सिंक में रहने की गारंटी है। कोड जहां टिप्पणियाँ सिंक से बाहर हैं, टूट गया है। आप अभी इसे नहीं जान सकते।
एडी

2
@ जॉन: ऐसा लगता है कि दोष एक डेवलपर ओवरसाइट के कारण हुआ। कमेंट-आउट कोड में चेकिंग पर प्रतिबंध से उस डेवलपर को यह ओवरसाइट बनाने से कैसे रोका जा सकता है? प्रतिबंध सिर्फ आपको दो चीजों को एक के बजाय सजा देने के लिए देता है। यह ओवरसाइट को नहीं रोकता है।
एडी

9
मैंने लगभग इसे वोट दिया था, लेकिन यह वास्तव में दुर्लभ है कि मुझे कुछ ऐसा मिलता है जो मैं केवल एक दिन के काम में चेक-इन राज्य में काम कर रहा हूं। मुझे लगता है कि यह संभव है कि आप मेरी तुलना में बहुत बेहतर डेवलपर हैं, लेकिन मैं यह मानता हूं कि मैं आपसे ज्यादा कठिन चीजों पर काम करता हूं। :-)
टेड

43

"कभी नहीं" दिशा-निर्देशों में उपयोग करने के लिए शायद ही कभी एक अच्छा शब्द है।

आपके सहकर्मी के पास इस बात का एक बड़ा उदाहरण है कि जब यह टिप्पणी की जाती है तो कोड की जांच करना उचित हो सकता है: जब यह अधूरा है और सक्रिय होने पर जांचे जाने पर आवेदन को तोड़ सकता है।

अधिकांश भाग के लिए, एक अच्छी तरह से प्रबंधित परिवर्तन-नियंत्रित प्रणाली में मृत कोड टिप्पणी करना अनावश्यक है। लेकिन, सभी टिप्पणी कोड "मृत" नहीं है।


9
मैं असहमत हूं। यदि कोड अधूरा है, तो इसे पहले स्थान पर चेक-इन क्यों किया जा रहा है। आधुनिक स्रोत नियंत्रण प्रणालियों में ट्रंक के लिए प्रतिबद्ध किए बिना इन-प्रोग्रेस कार्यक्षमता को अपलोड करने के लिए तंत्र हैं।
रेक्स एम।

9
+1, कभी-कभी ऐसा करना सबसे उपयुक्त होता है। हमेशा नहीं, लेकिन कभी भी नहीं । कहने के लिए कभी आसान नहीं है, लेकिन बहुत प्रतिबंधक है।
एडी

@ मुझे लगता है कि प्रगति में कार्यक्षमता अपलोड करने और ट्रंक को कम करने के बीच अंतर निर्धारित करने के लिए मूल पोस्ट में पर्याप्त जानकारी नहीं है।
जेसन कोको

रेक्स - कौन सा है? अधूरेपन में कभी जांच नहीं? या ट्रंक में कभी भी चेक-इन अधूरा नहीं है? वे एक ही चीज नहीं हैं।
जेम्स स्कैच

@ जैसन "डेवलपर कुछ कोड पर टिप्पणी करने में सक्षम होना चाहेंगे जो वह काम कर रहा है लेकिन अधूरा है"। लगता है कि वह मेरे लिए चेक-इन-प्रोग्रेस कार्यक्षमता को चाहता है।
रेक्स एम।

24

इतिहास को बनाए रखने के उद्देश्य से टिप्पणी कोड को कभी चेक-इन नहीं किया जाना चाहिए । यह स्रोत नियंत्रण का बिंदु है।

लोग यहां बहुत सारे आदर्शों पर बात कर रहे हैं। शायद हर किसी के विपरीत, मुझे "वास्तविक दुनिया" के साथ कई रुकावटों के साथ कई परियोजनाओं पर काम करना पड़ता है।

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

यदि आवश्यक हो, तो मैं आंशिक परिवर्तन करने के लिए अपनी कार्य शाखा बनाऊंगा।


4
@ आपका अंतिम बिट कुंजी है - यदि आप वर्किंग कोड में जांच नहीं कर सकते हैं, तो इसे लगाने के लिए दूसरी जगह खोजें। चाहे वह एक शाखा या एक आश्रय सेट हो या जो भी हो।
रेक्स एम

अगर मैं इसे एक से अधिक बार बढ़ा सकता हूं, तो मैं करूंगा। मेरी भावनाओं को ठीक!
ओला एल्डो

23

एक मामला जहां मैं छोड़ता हूं कोड बाहर टिप्पणी:

// This approach doesn't work
// Blah, blah, blah

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


6
यदि यह एक पंक्ति तक सीमित था तो यह एक अपवाद हो सकता है। मैं बल्कि एक संक्षिप्त ब्लॉक टिप्पणी (कुछ लाइनों में सबसे ऊपर) देखना चाहता हूं जिसमें एक दृष्टिकोण बनाम दूसरे को लेने के कारणों का उल्लेख है। उस स्थिति में मैं उस पर "टिप्पणी नहीं" करने पर विचार नहीं करूंगा, लेकिन प्रलेखित।
जॉन

3
+1। एक उदाहरण मैंने देखा है कि जहां कुछ टूट गया था क्योंकि कोड ने एक soTIMEOUT सेट किया था। इसे ठीक करना था। यदि आप कोड की लाइन को हटाते हैं, तो कोई बाद में इसे दोबारा लागू कर सकता है, यह सोचकर कि वे ऐसा करके एक बग को ठीक कर रहे हैं, लेकिन वास्तव में वे बग को फिर से पेश कर रहे हैं।
एडी

1
हाँ, यह मेरा विचार है - यह सुनिश्चित करना कि बग भविष्य में फिर से प्रस्तुत नहीं किया गया है। वास्तविक कोड को छोड़ कर वे देख सकते हैं कि यह सिर्फ एक बग नहीं था कि मूल कैसे लिखा गया था।
लोरेन Pechtel

इस मामले के लिए, मैं इसे "टिप्पणी से बाहर कोड" नहीं मानता, यह दस्तावेज है।
होवडाल

1
यह एकमात्र उदाहरण है जहां मैंने टिप्पणी-आउट कोड को लाइव किया। इस मामले में यह किसी के आधे-पके हुए विचार के आसपास नहीं है और रखरखाव प्रोग्रामर को भ्रमित कर रहा है, यह [उम्मीद है] कोड का एक वैध, कार्यात्मक उदाहरण है जो पूरी तरह से ऐप को तोड़ देगा, लेकिन अन्यथा स्पष्ट दृष्टिकोण है।
worc

19

मैं निश्चित रूप से, कमेंटेड-आउट कोड में दृढ़ता से कभी भी हतोत्साहित करूंगा। मैं, हालांकि, यह बिल्कुल प्रतिबंध नहीं होगा। कभी-कभी (शायद ही कभी) टिप्पणी-आउट कोड को स्रोत नियंत्रण में जांचना उचित होता है। "कभी ऐसा मत करो" कहना बहुत अधिक प्रतिबंधक है।

मुझे लगता है कि हम सभी इन बिंदुओं से सहमत हैं:

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

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

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

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

इसके अलावा, जब कोड की एक पंक्ति (या अधिक शायद ही कभी, दो पंक्तियों) को हटाकर एक बग को ठीक किया जाता है, तो मैं कभी-कभी एक टिप्पणी के साथ उस पंक्ति को टिप्पणी कर दूंगा कि उस कारण के साथ उस कोड को फिर से सक्षम करें। इस तरह की टिप्पणी स्पष्ट, प्रत्यक्ष और संक्षिप्त है।

रेक्स एम ने कहा: 1) केवल पूर्ण कार्यक्षमता में जांच करें, 2) [यदि] कार्य बहुत बड़ा है - इसे छोटे पूर्ण कार्यों में तोड़ दें।

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

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

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

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


4
@camh: एक समस्या ट्रैकिंग सिस्टम रिमाइंडर के रूप में वही संदर्भ प्रदान नहीं करेगा जो कोड में ही है, संदर्भ में, समस्या के बारे में एक संक्षिप्त टिप्पणी के साथ। समस्या ट्रैकिंग IDE के साथ गहन रूप से एकीकृत नहीं है। आपका सुझाव हठधर्मिता के लिए बहुत सारी जानकारी देता है ।
एडी

1
@ जॉन: नहीं, मैं लाखों एसएलओसी और दसियों हज़ारों स्रोत फ़ाइलों के साथ सामान पर काम करता हूं। अगर आपको लगता है कि जिस तरह की टिप्पणी का मैं जिक्र कर रहा हूं, वह अव्यवस्थित है, तो इसका मतलब है कि आप मुझे नहीं समझते हैं और / या कि मैं पर्याप्त स्पष्ट नहीं हो रहा हूं। मैं एक किनारे के मामले के बारे में बात कर रहा हूं, एक सामान्य घटना नहीं है, जैसा कि मैंने आपके प्रश्न के जवाब में कई बार थ्रेड्स में कहा है। और हे, क्या आपकी दुकान वह नहीं है जो निजी शाखाएं नहीं करती है? मुझ पर अभिमानी मत करो।
एडी

1
@ जॉन: एक उदाहरण के लिए, मेरी पिछली टिप्पणी stackoverflow.com/questions/758279/… पर देखें - और मुझे उस बग का पुनः परिचय रोकने का एक बेहतर तरीका दें। या @camh को, बताएं कि कैसे एक ट्रैकिंग सिस्टम उस बग को दोबारा पेश करने से रोकेगा। जब आप मिशन-क्रिटिकल 5-9 के उपकरण पर काम करते हैं, तो इस तरह का सामान।
एडी

1
@ जॉन: मैं कैसे "ज्यादातर अलग-अलग छोटे सामानों पर काम करने वाली विशिष्ट धारणा प्राप्त करता हूं" पर नाराज नहीं होना चाहिए? उर्फ, क्योंकि हम कुछ बहुत छोटे पर असहमत हैं, मुझे अनुभवहीन होना चाहिए? आप निश्चित रूप से हमेशा अपनी राय के हकदार हैं, और यह ठीक है कि हम असहमत हैं। लेकिन ध्यान दें जब मैं आपसे असहमत हूं, तो मैं आपके अनुभव के स्तर की आलोचना नहीं करता हूं क्योंकि हम चीजों को अलग तरह से देखते हैं। वास्तव में, मैं 98% या 99% आपसे सहमत हूं। मुझे सिर्फ निरपेक्षता पसंद नहीं है।
एडी

1
@ ईडीडीआई - आपके उत्तर का वर्तमान अवतार, जो मैं सबसे अच्छा अभ्यास पर विचार करूँगा, उसके साथ समझौता करने में बहुत करीब हूं। हमेशा की तरह जब यह सर्वोत्तम प्रथाओं की बात आती है, तो आपको कभी भी सभी से 100% समझौता नहीं करना पड़ेगा कि कोई भी चीज़ सबसे अच्छा अभ्यास है। मुझे उम्मीद नहीं थी कि जब मैंने अपना प्रश्न :) पोस्ट किया
जॉन 15

15

मुझे लगता है कि कभी भी बहुत मजबूत स्थिति नहीं होती है।

मैं टिप्पणी करना चाहता हूं, जांच कर रहा हूं, परीक्षण चला रहा हूं, एक सोच रखता हूं और फिर अगली रिलीज के बाद टिप्पणियों को हटा देता हूं।


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

@ जॉन सॉन्डर्स: यह आपके स्रोत नियंत्रण प्रणाली में क्या जाँच करता है, इस पर निर्भर करता है। यदि आप UCM के साथ ClearCase जैसी किसी चीज़ का उपयोग कर रहे हैं, तो चेकइन हमेशा एक निजी शाखा पर होते हैं और "TRUNK" के बराबर पर जाने के लिए एक अलग कदम की आवश्यकता होती है।
एडी

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

@ जॉन, मेरा मतलब था: टिप्पणी, परीक्षण, चेकइन ..! तुम सही हो।
Fortyrunner

14

सामान्य तौर पर, टिप्पणी-आउट कोड में जाँच गलत है क्योंकि यह उन लोगों के बीच भ्रम पैदा करता है जो मूल लेखक नहीं हैं और कोड को पढ़ने या उसमें संशोधन करने की आवश्यकता है। किसी भी घटना में, मूल लेखक अक्सर 3 महीने बीत जाने के बाद कोड के बारे में भ्रमित हो जाता है।

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

मुझे कोई आपत्ति नहीं है अगर आप सब खत्म कर देते हैं कि यह सामान यहाँ क्यों है। मेरी जरूरतें अधिक महत्वपूर्ण हैं कि आपकी वजह से मैंने ऐसा किया है। मुझे आपको या किसी और को सही ठहराने की कोई आवश्यकता नहीं है, मैंने ऐसा क्यों किया है।

मेरे लिए टिप्पणी-आउट कोड को आमतौर पर कम विचारशील सहकर्मी से अनादर के संकेत के रूप में देखा जाता है


3
आपके पोस्ट की अंतिम पंक्ति मृत है। मेरी इच्छा है कि मैं आपको एक से अधिक बार वोट दे
सकूं

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

6

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

अगले डेवलपर को उस टिप्पणी-आउट कोड को देखने का कोई विचार नहीं होगा कि यह प्रगति का काम है। क्या वह इसे बदलने के लिए स्वतंत्र है? क्या यह मृत कोड है? वह नहीं जानता।

यदि आपके सहकर्मी का परिवर्तन उस स्थिति में नहीं है, जहाँ इसे चेक किया जा सकता है, तो उसे इसे समाप्त करने की आवश्यकता है, और / या छोटे, वृद्धिशील परिवर्तन करना सीखना होगा।

"आंशिक परिवर्तनों में जाँच करना जो तैनात किया जा सकता है या नहीं हो सकता है" - संभवतः इसका मतलब यह भी है कि इसका परीक्षण किया भी जा सकता है या नहीं भी किया जा सकता है। यह बहुत रोप कोड बेस के लिए एक फिसलन ढलान है।


6

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


परिवर्तन प्रबंधन इस परिदृश्य में कहाँ फिट बैठता है? मैं मानता हूं कि ऐसी दुकानें हैं जहां सब कुछ हमेशा एक बड़ी आग है लेकिन इसका मतलब यह नहीं है कि चीजों को इस तरह से किया जाना चाहिए। मैं यह भी सुझाव दूंगा कि यह समस्या का एक कारण हो सकता है। कोड आधार पर पर्याप्त नियंत्रण नहीं।
जॉन

1
मैं पूरी तरह से इस तरह की बात से सहमत हूं कि बचना चाहिए, लेकिन किसी कारण से, प्रबंधन सहमत नहीं लगता :)
रॉबर्ट गोल्ड

5

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

मैं बाद वाले को "उन लोगों के रूप में वर्गीकृत करता हूं, जो अपने रिवीजन कंट्रोल सिस्टम को एक गरीब-आदमी के टेप बैकअप के रूप में इस्तेमाल करना पसंद करते हैं", लेकिन यह मेरे हाथ को खींच रहा होगा कि मैं किस कैंप में हूं। :-)

मेरा अनुमान है कि आप "अच्छे कोड" शिविर के हैं, और वह "काम करने वाले कोड" शिविर का है।

[संपादित करें]

टिप्पणियों से, हां मैंने सही अनुमान लगाया।

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

btw: अच्छे संपादकों को पुराने संस्करणों को रखने में मदद मिलेगी। उदाहरण के लिए, Emacs में मैंने पुराने-संस्करणों को रखा और पुराने-संस्करणों को 10 पर सेट किया, जिसमें यह मेरी फ़ाइलों के अंतिम 10 सहेजने के आसपास रखा है। आप संशोधन-नियंत्रण-के रूप में बैकअप भीड़ के खिलाफ अपने तर्क की मदद करने के तरीके के रूप में देख सकते हैं। हालाँकि, आप कभी भी तर्क नहीं जीतेंगे।


1
यह यहाँ भी कहा गया था। मेरे दिमाग में, हालांकि, रिपॉजिटरी डेटा लॉस रोकथाम उपकरण नहीं है। यह एक संशोधन नियंत्रण प्रणाली है। चूंकि हम टीएफएस का उपयोग कर रहे हैं, वह शेलिंग का उपयोग अधूरा कोड बैकअप करने के लिए कर सकता है। वह एक बैकअप टूल का भी उपयोग कर सकता है या कोड को बैक अप शेयर पर रख सकता है।
जॉन

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

किस तरह से मेरे एमाक्स बैकअप मुझे, जेम्स की रक्षा नहीं करते हैं? BTW: मैं आपके अंतिम वाक्य से पूरी तरह सहमत हूं।
TED

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

@ ted.dennison: शीर्ष दो उत्तरों के अंकों को देखते हुए, मैं कहूंगा कि आपकी राय एसओ पर बहुमत की राय है।
एडी

4

मेरे अनुभव में, डेवलपर स्विच कोड से बाहर हैं।

कभी-कभी, नए बैक-एंड को समानांतर में बनाया जाता है, स्रोत नियंत्रण में सक्रिय किए गए स्विच के साथ।

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


4

कोड बाहर टिप्पणी में जाँच के लिए एक और कारण:

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


5
+1: टिप्पणी-आउट कोड को जगह में छोड़ना - अगर और केवल अगर यह संक्षिप्त और विनीत है - तो किसी को "ऐसा न करें" और बग को फिर से प्रस्तुत करने से रोकता है। ESPECIALLY जब फिक्स में कोड की पंक्तियों को हटाना शामिल है, न कि कोड की पंक्तियों को फिर से लिखना।
एडी

निश्चित रूप से कोड की लाइनों को हटाने पर। ये एक अच्छा बिंदु है।
थर्सडेजेक

1
मैं असहमत हूं। शब्दों से बचने के बारे में एक टिप्पणी छोड़ना आवश्यक है, लेकिन कोड रूप में नहीं, बल्कि इसे शब्दों में वर्णन करने के बजाय।
thSoft

3

शायद यहां असली सवाल यह है कि क्या डेवलपर्स को अपूर्ण कोड में जांच करने की अनुमति दी जानी चाहिए?

यह अभ्यास निरंतर एकीकरण को लागू करने के आपके घोषित लक्ष्य के विपरीत प्रतीत होगा।


3

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


3

मेरा विचार: यदि डेवलपर्स अपनी शाखाओं पर, या अपने स्वयं के सैंडबॉक्स क्षेत्र में काम कर रहे हैं, तो उन्हें जो कुछ भी चाहिए, उसमें जांच करने में सक्षम होना चाहिए। यह तब होता है जब वे एक साझा शाखा (एक सुविधा शाखा, या एक टीम की शाखा, या निश्चित रूप से MAIN / ट्रंक) में कोड की जांच करते हैं कि कोड संभव के रूप में प्राचीन होना चाहिए (कोई टिप्पणी नहीं कोड, कोई और अधिक FIXMEs, आदि)।


3
TODO और FIXMEs या मुख्य ट्रंक के बिना दुनिया में एक भी सार्थक परियोजना नहीं है। सपने देखते रहो।
रॉबर्ट गॉल्ड

1
@ सिर्फ इसलिए क्योंकि यह बहुत कुछ होता है इसका मतलब यह नहीं है कि हमें इससे बचने की कोशिश नहीं करनी चाहिए।
रेक्स एम

2
वाह, यह वास्तव में एक सपना है। कोई FIXMEs के साथ उत्पादन कोड? यह बिना किसी कीड़े और बिना अस्पष्ट व्यवहार के पूर्ण रूप से पूर्ण होना चाहिए। ओह रुको, कोड की तरह है कि मौजूद नहीं है! :)
एडी ०

1
हां, स्पष्ट रूप से एक सपना - मैं सिर्फ यह कहने की कोशिश कर रहा था कि एक साझा शाखा में करने के लिए बार आपके व्यक्तिगत सैंडबॉक्स / कार्य-में-प्रगति शाखा में करने की तुलना में बहुत अधिक है।
जीन

@ जीन: हाँ, हम उस पर पूरी तरह सहमत हैं।
एडी

2

मुझे लगता है कि "कभी नहीं" एक नियम है। मैं कुछ व्यक्तिगत लीव को छोड़ने के लिए मतदान करूँगा कि लोग रिपॉजिटरी में टिप्पणी कोड की जाँच करें या नहीं। अंतिम लक्ष्य कोडर उत्पादकता होना चाहिए, न कि "एक प्राचीन भंडार"।

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


2

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

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

मुझे लगता है कि यह कोड को जटिल बनाता है और इसे पढ़ना मुश्किल बनाता है।

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


2

मुझे लगता है कि सोर्स कोड कंट्रोल सिस्टम में चेक-इन कमेंट कोड को अत्यधिक सावधानी के साथ किया जाना चाहिए, खासकर अगर कोड को कमेंट करने के लिए उपयोग किए जाने वाले भाषा टैग ब्लॉक द्वारा लिखे गए हों:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

इसके बजाय एक व्यक्तिगत लाइन के आधार पर, जैसे:

// My commented code start here
// My commented code line 1
// My commented code line 2

(तुम्हें नया तरीका मिल गया है)

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

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

लेकिन यदि कोड बिल्ड को पास कर देता है, तो यह तब सक्रिय हो सकता है जब इसे वहां नहीं होना चाहिए, और सीएम के नजरिए से, यह एक बुरा सपना हो सकता है। क्यूए आम तौर पर परीक्षण करते हैं कि क्या होना चाहिए, वे उस कोड के लिए परीक्षण नहीं करते हैं जो वहां होने वाला नहीं है, इसलिए आपका कोड उत्पादन में समाप्त हो सकता है इससे पहले कि आप इसे जानते हैं, और जब तक यह पता चलेगा कि कोड वहां है नहीं होना चाहिए, रखरखाव में लागत कई गुना बढ़ गई है (जैसा कि "बग" उत्पादन या ग्राहक द्वारा खोजा जाएगा, सबसे खराब जगह या समय कभी भी)।


हाँ मैं सहमत हूँ। हमने अपने सभी C # प्रोग्राम में टिप्पणी करने की शैली को विशेष रूप से / * * / रोक दिया है।
जॉन

2

स्रोत-नियंत्रण के इतिहास को किसी टिप्पणी के बजाय पुराने तरीके के "पुराने तरीके" को स्पष्ट करने की अनुमति देने और एक स्पष्टीकरण के साथ-साथ टिप्पणी-आउट में जाँच करने का विचार सिद्धांत में एक अच्छा विचार है।

वास्तविक दुनिया में, हालांकि, कोई भी उन फाइलों पर स्रोत नियंत्रण इतिहास को कभी नहीं देखता है जब तक वे काम नहीं कर रहे हैं जब तक कि यह किसी प्रकार की आधिकारिक समीक्षा प्रक्रिया का हिस्सा नहीं है (केवल समय-समय पर किया जाता है), या अगर कुछ काम नहीं करता है, और डेवलपर पता नहीं क्यों कर सकते हैं।

फिर भी, लगभग 3 संस्करणों की तुलना में अधिक मूल रूप से कभी नहीं दिखता है।

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

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

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

मेरे वर्तमान प्रोजेक्ट पर मेरा स्रोत नियंत्रण का पेड़ लगभग 10 सप्ताह पुराना है, केवल 4 इंजीनियरों की एक टीम पर, और लगभग 200 प्रतिबद्ध परिवर्तन सूचियां हैं। मुझे पता है कि मेरी टीम किसी काम का उतना अच्छा प्रदर्शन नहीं करती है जितना कि उसे जाँचना चाहिए क्योंकि कुछ ठोस और जाने के लिए तैयार है। हर महत्वपूर्ण परिवर्तन को पकड़ने के लिए कोड के हर हिस्से के कोड इतिहास को पढ़ने पर भरोसा करना बहुत कठिन बना देता है।

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

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

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

मैं शायद इस तरह की नो-कॉमेंटेड-कोड-पॉलिसी का जवाब यह कहकर दूंगा कि यह थोड़ा भोला था। सुविचारित, शायद, लेकिन अंततः अपने उद्देश्य को प्राप्त करने की संभावना नहीं है।

हालाँकि इस पोस्ट को देखने के लिए मैं पिछले हफ्ते में कोड के माध्यम से वापस जाने के लिए जा रहा हूँ और टिप्पणी-आउट भाग को हटा दें जो कि कभी भी अंतिम नहीं था (हालांकि यह काम किया) और फिर कभी भी वांछित होने की संभावना नहीं है।


इन तर्कों से इतने कम लोग क्यों सहमत हैं?
पैबाम्स

2

मुझे लगता है कि कोड आउट को "बेकार" माना जाता है।

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

यदि आप सहकर्मी कोड समीक्षा कर रहे हैं तो यह आपके प्रश्न का उत्तर दे सकता है। यदि कोई अन्य डेवलपर आपके कोड की समीक्षा करता है और कहता है कि "यह टिप्पणी कोड क्यों है जो 'ब्लाह' करने की कोशिश कर रहा है" तो आपका कोड कोड समीक्षा में विफल हो गया है और आपको इसे वैसे भी चेक नहीं करना चाहिए।

टिप्पणी की गई कोड सिर्फ अन्य डेवलपर्स के साथ सवाल उठाएगी - इसलिए समय और ऊर्जा बर्बाद करना।

आपको यह सवाल पूछने की आवश्यकता है कि " क्यों " कोड टिप्पणी की गई है। कुछ सुझाव:

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

यदि आप कोड की टिप्पणी कर रहे हैं क्योंकि आप "यदि यह करने का सबसे अच्छा तरीका है तो यह सुनिश्चित नहीं है" तो अपने कोड सहकर्मी की समीक्षा करें! समय बदल रहा है, आप उस कोड को देखेंगे जिसे आप आज 2 साल में लिखते हैं और सोचते हैं कि यह भयानक है! लेकिन आप बिट्स के बारे में टिप्पणी नहीं कर सकते हैं जिसे आप 'जानते हैं' बेहतर तरीके से कर सकते हैं लेकिन अभी आपको कोई रास्ता नहीं मिल रहा है। जो कोई भी कोडबेस को लंबे समय तक बनाए रखता है उसे निर्धारित करने दें कि क्या कोई बेहतर तरीका है - बस लिखित, परीक्षण और काम करने का कोड प्राप्त करें और आगे बढ़ें।

यदि आप कोड टिप्पणी कर रहे हैं क्योंकि "कुछ काम नहीं करता है" तो FIX IT ! एक सामान्य परिदृश्य "टूटे हुए परीक्षण" या "टूडू" है । यदि आपके पास ये हैं, तो आप उन्हें ठीक करने या बस उन्हें छुटकारा पाने के द्वारा अपने समय की बहुत बचत करेंगे। अगर उन्हें कुछ समय के लिए "तोड़ा" जा सकता है, तो वे हमेशा के लिए टूट सकते हैं।

इन सभी संभावित परिदृश्यों (और जिनका मैंने यहां उल्लेख नहीं किया है) समय और प्रयास बर्बाद कर रहे हैं। टिप्पणी की गई कोड एक छोटे से मुद्दे की तरह लग सकता है लेकिन आपकी टीम में एक बड़े मुद्दे का संकेतक हो सकता है।


1

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

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


एक रिपॉजिटरी एक संस्करण नियंत्रण प्रणाली है जो मेरे दिमाग में बैकअप उपकरण नहीं है।
जॉन

@ जॉन: कई डेवलपर्स इसे दोनों के रूप में देखेंगे।
एडी

@ ईदी, वे करेंगे, लेकिन यह नहीं है। बैकअप के लिए सभी प्रकार के अच्छे विकल्प हैं, संस्करण-नियंत्रण वास्तव में उनमें से एक नहीं है, क्या यह है?
डेविड कहते हैं, मोनिका

@ricebowl: मैं नहीं कह रहा हूँ मैं उन डेवलपर्स से सहमत हूँ! कई स्थानों पर अलग-अलग डेवलपर्स के बक्से का बैकअप नहीं लिया जाएगा। अब तक पूरा किए गए काम का एक अच्छा बैकअप के रूप में एक लंबी छुट्टी के कार्यों पर जाने से पहले एक निजी शाखा को अधूरे काम की जाँच करना। डेवलपर्स व्यावहारिक हैं।
एडी

1

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

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


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

1

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

अपूर्ण / प्रायोगिक कोड पूर्ण होने के लिए विकसित की जाने वाली शाखा में होना चाहिए। हेड / ट्रंक मेनलाइन होना चाहिए जो हमेशा संकलित होता है और व्हाट्स शिपिंग है। एक बार प्रायोगिक शाखा के पूरा हो जाने के बाद / इसे स्वीकार कर लिया जाना चाहिए। यहां तक ​​कि एक IEEE मानक (IEEE 1042) भी है, यदि आपको समर्थन दस्तावेज की आवश्यकता है, तो इसका वर्णन करें।


ज्यादातर समझौते में। लेकिन जब आप प्रायोगिक कोड को शिप करने की आवश्यकता रखते हैं तो आप क्या करते हैं क्योंकि आप किसी साइट की समस्या के मूल कारण की पहचान करने की कोशिश कर रहे हैं? विकास की बात करते समय, मैं आपसे सहमत हूं, लेकिन समर्थन की बात करते समय, कभी-कभी आपको प्रायोगिक कोड को शिप करने की आवश्यकता होती है।
एडी

@ ईडीआईआई - मैं समय-समय पर जहाज की आवश्यकता वाले प्रायोगिक कोड से सहमत हूं। लेकिन यह टिप्पणी नहीं की जानी चाहिए कि मेरी राय में अब इसकी आवश्यकता नहीं है।
जॉन

@Eddie - मैं समझता हूँ। लेकिन जब आप शाखा बनाते हैं तो शाखा हेड / रिलीज़ संस्करण की एक पूरी प्रतिलिपि होती है। ifyou एक मॉड बनाते हैं, इसे बिल्ड करने योग्य / shippable होना चाहिए। यदि आपको शाखा में बदलाव पसंद हैं तो आप उन्हें वापस सिर के सिरे पर मर्ज कर देते हैं या जरूरत पड़ने पर डीबग / प्रोफाइलिंग के लिए इसे संभाल कर रखते हैं।
माइक जेआर

@ जॉन: बिल्कुल सहमत हैं। एक बार प्रायोगिक कोड अब प्रायोगिक नहीं है, इसे जगह में छोड़ दिया जाना चाहिए या पूरी तरह से हटा दिया जाना चाहिए, जो भी उपयुक्त हो। @ मायकेजे: अच्छी प्रतिक्रिया।
एडी

1

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

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


1

" निशान ऊतक " जिसे मैं टिप्पणी-आउट कोड कहता हूं। संस्करण-नियंत्रण प्रणालियों के व्यापक उपयोग से पहले के दिनों में, कोड बंदरों ने फ़ाइल में टिप्पणी कोड को छोड़ दिया होगा , जब उन्हें कार्यक्षमता को वापस करने की आवश्यकता होगी।

केवल एक बार यह चेक-इन "निशान ऊतक" के लिए स्वीकार्य है

  1. यदि आपके पास एक निजी शाखा है और
  2. आपके पास त्रुटियों के बिना कोड संकलित करने का समय नहीं है और
  3. आप एक लंबी छुट्टी पर जा रहे हैं और
  4. आप अपने वीसीएस पर भरोसा नहीं करते हैं, जैसे कि यदि आप विज़ुअल सोर्स सेफ या का उपयोग करते हैं ।
    [संपादित करें]
  5. यदि आपके पास गलत कोड को अनुस्मारक के रूप में नहीं छोड़ा गया है तो आपके पास एक सूक्ष्म बग हो सकता है। (अन्य उत्तरों से अच्छा बिंदु)।

# 4 के लिए लगभग कोई बहाना नहीं है क्योंकि आसपास बहुत सारे स्वतंत्र रूप से उपलब्ध और मजबूत वीसीएस सिस्टम हैं, जीआईटी इसका सबसे अच्छा उदाहरण है

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

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

[संपादित करें] मैं जोड़ता हूँ कि दो प्रमुख परिदृश्य हैं जिन्हें अलग करने की आवश्यकता है:

  • निजी विकास, या तो एक निजी परियोजना को कोड करना या एक निजी शाखा में जाँच करना
  • रखरखाव विकास, जहाँ कोड की जाँच की जा रही है, उत्पादन में लगाने का इरादा है।

निशान-ऊतक के लिए "ना" कहें!


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

0

मुझे नहीं पता - मैं हमेशा बदलाव करने से पहले मूल पंक्तियों पर टिप्पणी करता हूं - अगर मैं अपना मन बदल देता हूं तो इससे मुझे वापस लौटने में मदद मिलती है। और हां मैं उन्हें चेक करता हूं।

हालांकि मैं पिछले चेक-इन से किसी भी पुराने टिप्पणी कोड को छीन लेता हूं।

मुझे पता है कि मैं क्या बदल रहा है यह देखने के लिए अलग लॉग देख सकता हूं लेकिन यह एक दर्द है - कोड में आखिरी बदलावों को देखना अच्छा है।


1
शायद आपको बेहतर उपकरण की आवश्यकता है?
jw

ऐसा न करने का एक कारण यह भी होगा कि आप यह देख सकते हैं कि मूल पंक्ति को किसने तुच्छ रूप से लिखा है (जैसे। git दोष)
gtd

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

0

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


0

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

अगर मुझे पहले के बदलाव को देखने के लिए कई संस्करणों पर वापस जाना है जो अब एक प्रदर्शन हिट की ओर जाता है तो यह बहुत कष्टप्रद होगा।

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

यह जानना भी अच्छा होगा कि उस कोड को किसने टिप्पणी की ताकि यदि कुछ औचित्य की आवश्यकता हो तो उनसे पूछा जा सके।

मैं नई कार्यक्षमता लिखना पसंद करता हूं, इकाई परीक्षण पास सुनिश्चित करता हूं, इसे जांचता हूं, फिर दूसरों को इसका उपयोग करने की अनुमति देता हूं और देखता हूं कि यह कैसे काम करता है।


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

0

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

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

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


0

स्पष्ट रूप से, डेवलपर जो कमेंट-आउट कोड में जाँच कर रहा है, ट्रंक शाखा से परिवर्तन के रूप में विलय में एक अलग शाखा में काम करना चाहिए।

इस वर्कफ़्लो में डेवलपर की सहायता करने के लिए VCS सिस्टम पर निर्भर है (git एक उत्कृष्ट VCS सिस्टम है जो इस बहुत अच्छी तरह से काम करता है)।

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