क्या वीसीएस से दूर निरर्थक फ़ाइलों को न हटाना बुरा है, लेकिन पहले उन्हें टिप्पणियों के साथ "हटाए जाने" के रूप में चिह्नित करें?

Question

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

मैं इसे उस उदाहरण के आधार पर आपको समझाना चाहता हूं:

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

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

उन्हें दूर करने के बजाय ऐसा क्यों किया जा रहा है?

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

"हम्म ... वो फाइलें क्यों हटाई गईं? मैंने पहले ठीक काम किया था।" (प्रेस 'रिवर्ट' -> वह आदमी जो फिर वापस आया है, हमेशा के लिए चला गया है या अगले हफ्तों में उपलब्ध नहीं है और अगले असाइनमेंट में मुझे थकाऊ रूप से यह पता लगाना है कि उन फाइलों के बारे में क्या है)

लेकिन क्या आप ध्यान नहीं देते कि उन संदेशों को कमिटेड मैसेज में क्यों डिलीट किया गया था?

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

Comments

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

— विंसेंट सवार्ड

@GregBurghardt यह एक बुरे विचार के बारे में एक अच्छा प्रश्न है। शायद लोग उस के दूसरे भाग के आधार पर डाउनवोटिंग कर रहे हैं (कब, आईएमओ, उन्हें पहले के लिए upvoting होना चाहिए)?

— बेन आरन्सन

"अगली बार जब मुझे प्रोजेक्ट कंट्रोल करने के लिए वर्जन में किसी चीज़ की जांच / जांच करनी हो, तो मैं SVN-> डिलीट दबाऊं" क्या आप कह रहे हैं कि आप उन्हें (संभावित) पूरी तरह से असंबंधित कमिट में डिलीट कर दें?

— केविन

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

— एंट पी।

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

— जूल

Answer 1

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

एक बाहरी व्यक्ति के दृष्टिकोण से, इस पद्धति को स्रोत नियंत्रण के बहुत रूढ़िवादी दृष्टिकोण में निहित किया गया लगता है।

"क्या होगा अगर मैं इस अप्रयुक्त फ़ाइल को हटा दूं और फिर किसी को इसकी आवश्यकता हो?" कोई पूछ सकता है।

आप स्रोत नियंत्रण का उपयोग कर रहे हैं। परिवर्तन को वापस करें, या बेहतर अभी तक उस व्यक्ति से बात करें जिसने फ़ाइल (संचार) को हटा दिया है।

"क्या होगा अगर मैं मृत फ़ाइल को हटा देता हूं, तो कोई इसे फिर से उपयोग करना शुरू कर देता है और वे बदलाव करते हैं?" कोई और पूछ सकता है।

फिर, आप स्रोत नियंत्रण का उपयोग कर रहे हैं। आपको एक मर्ज संघर्ष मिलेगा जिसे एक व्यक्ति को हल करना होगा। अंतिम प्रश्न के साथ यहां उत्तर, अपने साथियों के साथ संवाद करना है।

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

यदि इसे हटाया जाना चाहिए, तो इसे हटा दें। कोड बेस से वसा को काटें।

यदि आपने एक "उफ़्सी" बनाया है और आपको वास्तव में फ़ाइल की आवश्यकता है, तो याद रखें कि आप स्रोत नियंत्रण का उपयोग कर रहे हैं ताकि आप फ़ाइल को पुनर्प्राप्त कर सकें।

विंसेंट सवार्ड ने सवाल पर एक टिप्पणी में कहा:

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

यह ध्वनि सलाह है। कोड की समीक्षाओं को इस तरह की चीज को पकड़ना चाहिए। जब किसी फ़ाइल में कोई अप्रत्याशित परिवर्तन होता है, या फ़ाइल को हटा दिया जाता है या उसका नाम बदल दिया जाता है, तो डेवलपर्स को प्रतिबद्ध संदेशों से परामर्श करने की आवश्यकता होती है।

यदि प्रतिबद्ध संदेश कहानी नहीं सुनाते हैं, तो डेवलपर्स को भी बेहतर प्रतिबद्ध संदेश लिखने की आवश्यकता होती है।

कोड हटाने या फ़ाइलों को हटाने से डरना प्रक्रिया के साथ एक गहरी, प्रणालीगत समस्या का संकेत है:

• सटीक कोड समीक्षाओं का अभाव
• स्रोत नियंत्रण कैसे काम करता है, इसके बारे में समझने की कमी
• टीम संचार का अभाव
• डेवलपर्स की ओर से खराब संदेश

ये पते की समस्याएं हैं, इसलिए आपको ऐसा महसूस नहीं होता है कि जब आप कोड या फ़ाइलों को हटाते हैं तो आप एक ग्लास हाउस में चट्टानें फेंक रहे होते हैं।

Comments

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

— एशेल्ली

@AShelly: एक डेवलपर कार्य शायद ही कभी एक टिप्पणी को बदलने के लिए है। कार्य में कोड बदलना शामिल है, जो कि डेवलपर पर ध्यान केंद्रित करता है - टिप्पणियां नहीं।

— ग्रेग बरगार्ड

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

— Cort Ammon

@AShelly - एक उदाहरण के रूप में मैं आमतौर पर किसी स्थान पर फ़ाइलें खोलता हूं। वीएस में मैं शीर्ष पर ड्रॉपडाउन का उपयोग करके सीधे एक विधि के लिए खुल सकता हूं या संदर्भ मेनू पर "परिभाषा पर जाएं"। मैं फ़ाइल के शीर्ष को कभी नहीं देख पाऊंगा। इसके अलावा, उदात्त पाठ I में अक्सर एक पंक्ति में उनके खुले संवाद users.rb: 123 उपयोगकर्ताओं को खोलते हैं। सीधे रेखा 123 पर खुलते हैं। कई कोड संपादकों के पास समान विकल्प होते हैं।

— coteyr

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

— xdhmoore

Answer 2

हाँ यह बुरा अभ्यास है।

जब आप फ़ाइलों को हटाने का काम करते हैं, तो आपको स्पष्टीकरण में हटाए जाने के लिए स्पष्टीकरण देना चाहिए।

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

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

Comments

शायद सवाल का जवाब जोड़ें: क्या यह बुरा अभ्यास है? हां, क्योंकि ....

— जुआन कार्लोस कोटो

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

— एंड्रयू साविनाख

@AndrewSavinykh यह अलग है, आप टिप्पणी कर रहे हैं कोड आप अभी भी सुनिश्चित नहीं हैं कि आप हटाना चाहते हैं।

— गोयो

@AndrewSavinykh "प्रमुख दर्द या बाद में कई चीजें प्रभावित करती हैं" - मुझे आश्चर्य है कि आप किस संस्करण का उपयोग करते हैं; यह एक बड़ा दर्द नहीं होना चाहिए। यह निश्चित रूप से Git में नहीं है, कम से कम नहीं के बाद आप इसे दो बार किया है और सीखा है कि क्या देखना है ... और बशर्ते आपका इतिहास अनावश्यक बैक-एंड-कमिट्स से भरा हुआ न हो जो आपको देता है हर दूसरे मर्ज का सामना करता है। और

— कहता

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

— लेफ्टनैताबाउट

Answer 3

मेरी राय में, आपके दोनों विकल्प सर्वोत्तम अभ्यास नहीं हैं , जैसा कि बुरे , अभ्यास के विपरीत है :

1. यदि कोई व्यक्ति उन टिप्पणियों को पढ़ने के लिए होता है, तो केवल टिप्पणियों को जोड़ना किसी भी मूल्य को जोड़ता है।
2. बस VCS से हटाने, (परिवर्तन विवरण में एक कारण के साथ), एक महत्वपूर्ण वितरण को प्रभावित कर सकता है और कई लोग परिवर्तन विवरण नहीं पढ़ते हैं, खासकर जब दबाव में।

मेरा पसंदीदा अभ्यास - काफी हद तक वर्षों में कई बार काटे जाने के कारण, यह ध्यान में रखते हुए कि आप हमेशा नहीं जानते कि आपका कोड कहाँ या किसके द्वारा उपयोग किया जा रहा है -

1. एक टिप्पणी जोड़ें जो यह कहती है कि यह विलोपन और पदावनति #warning या समान केprint लिए एक उम्मीदवार है , (अधिकांश भाषाओं में इस तरह के तंत्र हैं, जैसे जावा में, सबसे खराब स्थिति में एक बयान या एक समान पर्याप्त होगा), आदर्श रूप से किसी प्रकार के समय के साथ। संपर्क विवरण के साथ। यह किसी को भी सचेत करेगा जो अभी भी वास्तव में कोड का उपयोग कर रहा है। ये चेतावनी आम तौर पर प्रत्येक फ़ंक्शन या वर्ग के अंदर होती है यदि ऐसी चीजें मौजूद हैं ।
2. कुछ समय बाद चेतावनी को मानक फ़ाइल स्कोप में अपग्रेड करें #warning(कुछ लोग डिप्रेशन चेतावनियों को अनदेखा करते हैं और कुछ टूल चेन डिफ़ॉल्ट रूप से ऐसी चेतावनियों को प्रदर्शित नहीं करते हैं)।
3. बाद में फ़ाइल स्कोप #warningको एक #errorया समतुल्य के साथ बदलें - इससे कोड बिल्ड टाइम पर टूट जाएगा लेकिन यदि आवश्यक हो तो हटा दिया जा सकता है लेकिन इसे हटाने वाला व्यक्ति इसे अनदेखा नहीं कर सकता है। (कुछ डेवलपर्स किसी भी चेतावनी को पढ़ते या संबोधित नहीं करते हैं या इतने सारे हैं कि वे महत्वपूर्ण लोगों को अलग नहीं कर सकते हैं)।
4. अंत में फ़ाइल (ओं) को चिह्नित करें, (नियत तारीख पर या उसके बाद), जैसा कि वीसीएस में हटा दिया गया है।
5. यदि चेतावनी के चरण में पूरे पैकेज / लाइब्रेरी / आदि को हटाने पर मैं एक README.txt या README.html या इसी तरह की जानकारी के साथ जोड़ दूंगा कि यह पैकेज से छुटकारा पाने के लिए कब और क्यों उस फ़ाइल के साथ छोड़ने की योजना है? यह कहने के लिए कि जब यह हटा दिया गया था, तब बाकी सामग्री को हटाने के बाद कुछ समय के लिए पैकेज की एकमात्र सामग्री थी।

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

ध्यान दें कि #warning/ #errorएक C / C ++ तंत्र है जो प्रदान किए गए पाठ के बाद एक चेतावनी / त्रुटि का कारण बनता है जब कंपाइलर का सामना होता है जो कोड, जावा / जावा-डॉक्टर को @Deprecatedउपयोग पर चेतावनी जारी करने और @deprecatedकुछ जानकारी प्रदान करने के लिए एनोटेशन होता है , आदि। python & I में समान करने के लिए व्यंजनों का assertउपयोग मैंने #errorवास्तविक दुनिया में इसी तरह की जानकारी प्रदान करने के लिए किया है ।

Comments

विशेष रूप से, चूंकि इस प्रश्न में जावा का उल्लेख है, @deprecatedजावाडॉक टिप्पणी और @Deprecatedएनोटेशन का उपयोग करें ।

— २००:०००

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

— एंडी

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

— स्टीव बार्न्स

@ 200_success धन्यवाद - C / C ++ में मेरा बैकग्राउंड - उत्तर में जोड़ा गया।

— स्टीव बार्न्स

@SteveBarnes हो सकता है, लेकिन ऐसा नहीं है जो ओपी के बारे में पूछ रहा है। उसने सत्यापित किया है कि कोड मृत है।

— एंडी

Answer 4

हां, मैं कहूंगा कि यह बुरा व्यवहार है, लेकिन इसलिए नहीं कि यह फाइलों में बनाम प्रतिबद्ध संदेश में है। समस्या यह है कि आप अपनी टीम के साथ संवाद किए बिना बदलाव करने की कोशिश कर रहे हैं।

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

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

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

Answer 5

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

इसलिए (C ++ प्रोजेक्ट में) मैंने जोड़ा

#error this is not as dead as I thought it was

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

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

Answer 6

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

लेकिन यह कोड लंबे समय तक नहीं रहना चाहिए। मैं आमतौर पर अगले स्प्रिंट की शुरुआत में हटाता हूं।

यदि आपके पास सह-कार्यकर्ता हैं जो प्रतिबद्ध संदेश नहीं पढ़ते हैं या आपसे यह नहीं पूछेंगे कि आपने परियोजना में कोड क्यों छोड़ा, तो आपका मुद्दा खराब कोडिंग शैली में से एक नहीं है। आपको एक अलग समस्या है।

Comments

इससे पहले किए गए 6 अंकों से अधिक कुछ भी नहीं दिया गया था और पहले 6 उत्तरों में समझाया गया था

— gnat

Answer 7

अपने स्टंट को खींचने से पहले आप क्लास को रीफ़्रैक्टर भी कर सकते हैं और UNUSED_Classname के लिए एक उपसर्ग के साथ इसका नाम बदल सकते हैं। फिर आपको सीधे डिलीट ऑपरेशन भी करना चाहिए

• चरण 1: वर्ग का नाम बदलें, अपनी टिप्पणी जोड़ें, प्रतिबद्ध
• चरण 2: फ़ाइल को हटा दें और प्रतिबद्ध करें

यदि यह मृत कोड है, तो इसे हटा दें। किसी को भी इसकी आवश्यकता है, वे वापस जा सकते हैं, लेकिन नाम बदलने का कदम उन्हें बिना सोचे-समझे सीधे इसका इस्तेमाल करने से रोक देगा।

लोगों को यह भी सिखाएं कि किसी फ़ाइल के लिए सभी प्रतिबद्ध संदेशों को कैसे देखें, कुछ लोग यह भी नहीं जानते हैं कि यह संभव है।

Comments

"रिफ़ैक्टरिंग" का वास्तव में मतलब नहीं है कि आप क्या सोचते हैं

— निक किरियाकिड्स

यह अप्रयुक्त है, यह सुनिश्चित करने के लिए वर्ग / विधि का नाम बदलने की आवश्यकता नहीं है, इसे हटाने के साथ ही काम करता है। इसके बजाय प्रक्रिया किसी अन्य परिवर्तन के समान है: 1) मृत कोड हटाएं , 2) परीक्षण चलाएं , 3) यदि वे पास होते हैं, तो कमेंट्री के साथ प्रतिबद्ध करें ।

— श्वर्न

@ user275398 मुझे भी लगता है कि फाइलों का नाम बदलना वास्तव में बहुत ज्यादा है। और तकनीकी दृष्टिकोण से भी, एसवीएन नाम बदलने का व्यवहार करता है जैसे फ़ाइल को हटा दिया जाता है और एक नए नाम के साथ बनाया जाता है, इस प्रकार आपके पास इतिहास में एक ब्रेक होता है। यदि आप पुनर्नामित फ़ाइल को पुनर्स्थापित करेंगे और इसके SVN लॉग पर गौर करेंगे, तो नाम बदलने से पहले का इतिहास उपलब्ध नहीं है। इसके लिए आपको पुराने नाम वाली फाइल को वापस करना होगा। Refactoring कुछ और तरह से है, Refactoring मौजूदा कोड को एक नई संरचना में व्यवस्थित कर रही है।

— ब्रुडर लस्टिग

@BruderLustig: अच्छा सॉफ्टवेयर निश्चित रूप से ऐसा नहीं करेगा। गिट के पास है git mv, जो इतिहास पर नज़र रखता है । मर्क्यूरियल इसी तरह है hg mv। लगता है svn moveSVN के लिए भी काम करना चाहिए?

— व्रचिन

@wchargin नहीं, git mvबस फ़ाइल को स्थानांतरित करता है और एक फ़ाइल हटाने और एक फ़ाइल निर्माण को चरणबद्ध करता है। जब आप चलते हैं git log --followऔर समान होते हैं तो सभी मूव ट्रैकिंग होती है । gitनाम बदलने का कोई तरीका नहीं है, यह वास्तव में परिवर्तनों को ट्रैक नहीं करता है ; इसके बजाय यह प्रतिबद्धताओं के समय राज्यों को ट्रैक करता है और यह पता लगाता है कि उस समय क्या बदल गया है जब आप इतिहास का निरीक्षण करते हैं।

— मआर्टिनस