क्या कोई अप्रयुक्त कोड हटाने (या रखने) के पेशेवरों की व्याख्या कर सकता है?

Question

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

हटाने के लिए मेरे बिंदु नहीं हैं:

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

क्या कोई अप्रयुक्त कोड हटाने (या रखने) के पेशेवरों की व्याख्या कर सकता है?

Comments

कमेंट आउट कोड भी एक कोडबेस में नहीं होना चाहिए।

— लीपी

क्योंकि हमारे पास संस्करण नियंत्रण है। यदि हमें कभी भी कोड के पुराने संस्करणों को संदर्भित करने की आवश्यकता होती है तो हम केवल इतिहास की समीक्षा कर सकते हैं।

— आर्मंडिनो

Btw, संस्करण नियंत्रण का जिक्र करना मुश्किल हो सकता है, जब परियोजना बड़ी होती है और कुछ फाइलों में> 200 संशोधन होते हैं

— एलेक्स टर्बिन

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

— utnapistim 7

सॉफ्टवेयर इंजीनियरिंग में एक समान प्रश्न है ।

— davidvandebunte

Answer 1

यहां कुछ कारण दिए गए हैं जिनका अप्रयुक्त कोड हटाया जाना चाहिए:

• किसी प्रोजेक्ट पर काम करने वाले नए लोगों के लिए, उन्हें न केवल काम करने वाले कोड को समझना होगा, उन्हें अप्रयुक्त सामग्री को भी समझना होगा। यह समय बर्बाद किया जाता है और भ्रम पैदा करता है।

• एक खतरा है कि किसी समय कोई व्यक्ति एक बदलाव करेगा जो अनजाने में 'निष्क्रिय' कोड को शामिल करता है और बग का परिचय दे सकता है। मुझे पता है कि यह उन परियोजनाओं पर हुआ है जिन पर मैंने काम किया है।

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

• समय के साथ क्या होता है और अधिक पुराने अप्रयुक्त कोड को कोडबेस में जोड़ा जाता है। इससे भ्रम, संभावित गलतफहमी और प्रशासनिक उपरि बढ़ जाती है।

• संभावना है कि अप्रयुक्त कोड कभी भी फिर से उपयोग किया जाएगा बहुत संभावना नहीं है। समय के साथ पुन: उपयोग की संभावना कम हो जाती है। यदि कोड निकालना है और पर्याप्त महत्वपूर्ण माना जाता है तो कोड को बंद कर दिया जा सकता है और प्रलेखित किया जा सकता है।

• कोडर के बारे में कोई भी व्यक्तिगत भावनाएं जो कोड के बारे में हो सकती हैं, वे समझ में आने पर कड़ी मेहनत कर सकते हैं। लेकिन पेशेवर होने के हिस्से के लिए आवश्यक है कि उन विचारों को बेहतर अच्छे के लिए एक तरफ रखा जाए। समय बिना किसी के लिए खड़ा है और एक कामकाजी कोडबेस में ऐतिहासिक कोड को संरक्षित करने के लिए कोई जगह नहीं है।

Comments

मेरे पास हाल ही में अनुपयोगी कोड को देखने के कारण (और यह अप्रयुक्त नहीं था) को देखने के कारण मेरे अंदर से डराने वाला जीव निकला था। अनुपयोगी कोड को अस्तित्व से हटा दिया जाना चाहिए!

— लेप्पी

अच्छा अंक, धन्यवाद। मेरे सहयोगियों ने उनमें से कई को भी कहा

— एलेक्स टर्बिन

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

— जोनास विंकलर

मैं अभी नीचे वोट के लिए अपने कारणों में बहुत दिलचस्पी होगी।

— शक

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

— चॉप

Answer 2

@suspectus ने कोड हटाने के कारणों को प्रस्तुत करने का एक उत्कृष्ट काम किया है; मैं कोड रखने के लिए आपकी व्यक्तिगत गोलियों को संबोधित करना चाहूंगा।

• कोड पहले से ही लिखा गया है, और प्रयास खर्च किए जाते हैं

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

• कोड को सिंथेटिक और वास्तविक वातावरण पर परीक्षण किया जा सकता है

मुझे क्षमा करें, मुझे नहीं पता कि आपका इससे क्या मतलब है।

• यदि अच्छी तरह से संगठित (समूहीकृत, अलग पैकेज, शिथिल कपल आदि) तो यह आपको समग्र कोड विश्लेषण या रीफैक्टरिंग पर परेशान नहीं करता है

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

• कोड का उपयोग भविष्य में किया जा सकता है

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

• हटाए जाने पर, लेखक असहज महसूस कर सकता है

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

Answer 3

क्या यह कुछ कोड लेने और इरादे का पता लगाने के लिए पर्याप्त कठिन नहीं है, लेकिन अब आपको यह पता लगाना होगा कि कौन से हिस्से उपयोग में नहीं हैं?

Answer 4

कोड पहले से ही लिखा गया है, और प्रयास खर्च किए जाते हैं

यह भी अनावश्यक है। यदि आप इसे किसी भी चीज के लिए उपयोग नहीं करते हैं, तो यह (परिभाषा के अनुसार) बेकार है, भले ही यह क्या करता है या इस पर कितना प्रयास किया गया था।

कोड को सिंथेटिक और वास्तविक वातावरण पर परीक्षण किया जा सकता है

यदि यह बेकार है, तो यह अभी भी बेकार है, भले ही आपके पास इस पर परीक्षण हो। यदि कोड बेकार है, तो इसके लिए परीक्षण भी बेकार होना चाहिए (इसलिए टिप्पणी कोड को वहां रखने से अस्पष्टता पैदा होती है - क्या आप परीक्षण रखते हैं? यदि आपके पास टिप्पणी कोड का क्लाइंट कोड था, तो क्या आप ग्राहक कोड के साथ भी टिप्पणी करते हैं? )

यदि अच्छी तरह से संगठित (समूहीकृत, अलग पैकेज, शिथिल कपल आदि) तो यह आपको समग्र कोड विश्लेषण या रीफैक्टरिंग पर परेशान नहीं करता है

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

यदि कोड दूसरी ओर अच्छी तरह से व्यवस्थित नहीं है , तो यह स्थैतिक विश्लेषण, रीफैक्टरिंग और किसी भी अन्य को गड़बड़ कर देगा।

आप अपने टूल इनपुट पर शोर शुरू कर रहे हैं और उम्मीद कर रहे हैं कि वे इसके साथ सही तरीके से सामना करेंगे।

क्या होगा यदि आपका स्थिर विश्लेषण उपकरण टिप्पणियों / कोड अनुपात की गणना करता है? आपने अभी इसे गड़बड़ कर दिया, कुछ ऐसा जो कल तक प्रासंगिक था (या जब भी कोड टिप्पणी की गई थी)।

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

कोड का उपयोग भविष्य में किया जा सकता है

यदि यह है, तो आप इसे अपनी टीम की पसंद के SCM में पाएंगे।

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

हटाए जाने पर, लेखक असहज महसूस कर सकता है

इसलिए?

आप (मेरा मानना ​​है) डेवलपर्स की एक पूरी टीम है जो आपको सबसे अच्छा सॉफ्टवेयर बनाने के लिए भुगतान करती है जो आप जानते हैं कि कैसे, "सबसे अच्छा सॉफ्टवेयर जिसे आप जानते हैं कि एक्स की भावनाओं को चोट पहुंचाए बिना कैसे करें"।

यह प्रोग्रामिंग का एक हिस्सा है, जो लिखा गया अधिकांश कोड अंततः खारिज कर दिया जाएगा; उदाहरण के लिए, जोएल स्पोल्स्की ने कुछ बिंदु पर कहा कि उनकी कंपनी के लिए, लगभग 2% लिखित कोड उत्पादन को देखता है।

यदि आप कोड बेस की गुणवत्ता पर डेवलपर्स के अहंकार को प्राथमिकता देते हैं, तो आप अपने उत्पाद की गुणवत्ता का त्याग करेंगे, ... क्या वास्तव में? अपने साथी डेवलपर्स की अपरिपक्वता को बनाए रखना? अपने सहयोगियों की अवास्तविक उम्मीदों की रक्षा?

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

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

Answer 5

डेड कोड आपके कोड को प्रदूषित कर रहा है

मृत कोड समझ और पठनीयता कम हो जाती है।

सर्वश्रेष्ठ कोड हमेशा पुन: उपयोग किए जाते हैं, और यदि u मृत कोड हैं तो यह पुन: प्रयोज्य को कम करता है

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

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

Answer 6

• भय । इससे टीम को अधिक चिंता होती है और उत्पादन कम होता है। अधिक मृत कोड पेश किए जाने पर डर की मात्रा तेजी से बढ़ जाती है। "हमें नहीं पता कि अगर उस बिट का उपयोग किया जाता है, तो हम इसे हटाने या इसे छूने की हिम्मत नहीं करते हैं।"

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

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

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

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

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

Answer 7

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

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

आपकी बातों के जवाब में ...

• कोड पहले से ही लिखा गया है, और प्रयास खर्च किए जाते हैं

लेकिन इसे अक्सर बनाए रखना चाहिए। यह अभी भी चीजों में दिखाई देगा जैसे कि फ़ाइल में खोजें।

• कोड को सिंथेटिक और वास्तविक वातावरण पर परीक्षण किया जा सकता है

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

• यदि अच्छी तरह से संगठित (समूहीकृत, अलग पैकेज, शिथिल कपल आदि) तो यह आपको समग्र कोड विश्लेषण या रीफैक्टरिंग पर परेशान नहीं करता है

आपका कोड वैसे भी ऐसा होना चाहिए लेकिन केवल समस्या को कम करता है। यह सुनने के लिए सबसे अजीब तर्क है कि कुछ को अभी तक अशुद्ध आयोजित किया जाना चाहिए। कोड मॉड्यूलर रखने और निर्भरता कम करने की कोशिश करना सामान्य है, लेकिन आप पुन: प्रयोज्य कोड भी चाहते हैं और यदि आपके सभी मॉड्यूल एक द्वीप हैं तो संभावना है कि आप DRY नहीं हुए हैं। तुम भी अपने आप को अत्यधिक decoupling है कि कुछ भी नहीं है, लेकिन अप्रयुक्त गन्दा कोड की समस्या को कम करता है पा सकते हैं।

• कोड का उपयोग भविष्य में किया जा सकता है

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

क्या बुरा है कि अप्रयुक्त कोड का कोई उद्देश्य नहीं है। जब कोई व्यक्ति आता है और उसे कुछ बदलना होता है जो अप्रयुक्त कोड को प्रभावित करता है, तो वे वहां बैठे रहने वाले होते हैं, यह पता लगाने की कोशिश करते हैं कि इस अप्रयुक्त कोड का कोई उद्देश्य नहीं है।

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

• हटाए जाने पर, लेखक असहज महसूस कर सकता है

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

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

Answer 8

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

Answer 9

यह चर्चा कई साल पुरानी है, लेकिन मैं इसमें भाग गया ...

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

Answer 10

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

Answer 11

क्या आप सुनिश्चित हैं कि कोड अप्रयुक्त है?

यह अभी भी संकलित कोड की जांच करने के लिए पर्याप्त नहीं है। C ++ में, यदि आप "अप्रयुक्त" रूप से परिभाषित पद्धति को हटा देते हैं, जैसे operator=आप संकलक त्रुटि प्राप्त नहीं करने जा रहे हैं, तो कक्षा चुपचाप (संभवतः गलत) डिफ़ॉल्ट कार्यान्वयन का उपयोग करना शुरू कर देगी। जावा या C # में कोड का उपयोग परावर्तन के माध्यम से किया जा सकता है। ऑब्जेक्ट-ओरिएंटेड भाषाओं में, वंशानुक्रम एक भूमिका निभा सकता है (बेस क्लास अब कहा जा सकता है)। लगभग किसी भी भाषा में, एक और अतिभारित कार्य हो सकता है।

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

अप्रयुक्त कोड को अप्रत्यक्ष रूप से हटा दें

आप कोड बनाए रखने के लिए भुगतान करते हैं:

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

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