कोड कवरेज अप्रयुक्त विधियों को उजागर करता है - मुझे क्या करना चाहिए?


59

मुझे एक मौजूदा जावा परियोजना के कोड कवरेज को बढ़ाने का काम सौंपा गया है।

मैंने देखा कि कोड कवरेज टूल ( EclEmma ) ने कुछ तरीकों को उजागर किया है जिन्हें कभी भी कहीं से नहीं बुलाया जाता है।

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

सबसे अच्छा तरीका क्या होगा? उनके लिए यूनिट टेस्ट लिखें, या सवाल करें कि वे वहां क्यों हैं?


1
टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
maple_shaft

जवाबों:


119
  1. हटाएँ।
  2. प्रतिबद्ध होते हैं।
  3. भूल जाओ।

दलील:

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

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


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

11
यद्यपि मैं इस उत्तर के मूल से सहमत हूं, शाब्दिक प्रश्न था "क्या मुझे सवाल करना चाहिए कि वे वहां क्यों हैं?" । यह उत्तर ओपी को अपनी टीम को हटाने से पहले नहीं पूछना चाहिए।
डॉक ब्राउन

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

10
इस उत्तर के साथ बहुत सी बातें गलत हैं, जैसा कि टिप्पणियों या अन्य उत्तरों में व्यक्त किया गया है, कि मैं विश्वास नहीं कर सकता कि यह शीर्ष मतदान और स्वीकृत उत्तर है।
user949300

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

55

अन्य सभी उत्तर इस धारणा पर आधारित हैं कि प्रश्न के तरीके वास्तव में अप्रयुक्त हैं। हालाँकि, यह प्रश्न निर्दिष्ट नहीं किया गया था कि यह परियोजना स्व-निहित है या किसी प्रकार का पुस्तकालय है।

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

इस मामले में, चार संभावनाएँ हैं:

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

9
प्लस अगर यह एक पुस्तकालय है, तो कार्य पूर्णता के लिए हैं
प्लाज्मा १

क्या आप इस बात पर विस्तार से बता सकते हैं कि उनका परीक्षण कैसे किया जाना चाहिए? यदि आप नहीं जानते कि विधि क्यों है, तो आप शायद नहीं जानते कि यह क्या करना चाहिए।
TKK

विधि के नाम filter_name_exists, ReloadSettingsया addToSchema(बेतरतीब ढंग से 3 मनमानी खुले स्रोत परियोजनाओं से उठाए गए) को कुछ संकेत प्रदान करना चाहिए कि विधि क्या करना है। एक javadoc टिप्पणी और भी उपयोगी हो सकती है। एक उचित विनिर्देश नहीं, मुझे पता है, लेकिन कुछ परीक्षण बनाने के लिए पर्याप्त हो सकता है जो कम से कम प्रतिगमन को रोक सकते हैं।
ज़ोल्टन

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

31

पहले जांच लें कि आपका कोड कवरेज टूल सही है।

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


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

3
हां, आपको अन्य परियोजनाओं की जांच करनी चाहिए जो कक्षा को dll के रूप में आयात कर सकती हैं
इवान

7
यह उत्तर अधूरा लगता है। "पहले जांच लें कि आपका कोड कवरेज टूल सही है। यदि यह है, तो .... [शेष उत्तर डालें] "। विशेष रूप से, ओपी यह जानना चाहता है कि कोड कवरेज टूल सही होने पर क्या करना है।
जॉन बेंटले

1
@jonbentley ओपी उपकरण रिपोर्ट के लिए सबसे अच्छा तरीका पूछ रहा है। "इसे मैन्युअल रूप से जांचें" क्योंकि इसके संदर्भ से यह बहुत स्पष्ट है कि इसका गलत
इवान

15

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


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

4
खैर जब तक कोड "अप्रयुक्त" विधियों को कॉल करने के लिए प्रतिबिंब का उपयोग नहीं करता है, लेकिन उस स्थिति में आपके पास बहुत बड़ी समस्याएं हैं, और हम thefailywft.com पर कोड देखने के लिए तत्पर हैं (यदि कोई कोड क्लासनेम करता है, तो एक त्वरित परीक्षण करें। कक्षा)।
MTilsted

2
यह सांख्यिकीय रूप से संकलित है, लेकिन यह भी invokedynamicनिर्देश है, इसलिए, फिर जानते हैं ...
corsiKa

@ जारी: कई चौखटे हैं जो तार का उपयोग करके कोड कहेंगे - मैं कम से कम स्प्रिंग और हाइबरनेट को अपने सिर के ऊपर से सोच सकता हूं।
झोमिनल

9

सबसे अच्छा तरीका क्या होगा? उनके लिए यूनिट टेस्ट लिखें, या सवाल करें कि वे वहां क्यों हैं?

कोड हटाना एक अच्छी बात है।

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

मैं पदावनत तरीकों में निवेश करने की सिफारिश नहीं करूंगा - इसलिए कोई नई इकाई परीक्षण सिर्फ कवरेज के लक्ष्यों को हिट करने के लिए नहीं।

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

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

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

यदि आपकी कंपनी मोनो-रेपो का उपयोग करती है , तो हटाएं मल्टी-रेपो मामले की तुलना में कम जोखिम है।

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

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

सवाल वे वहाँ क्यों हैं?

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

आप स्रोत कोड के साथ विद्या पर कब्जा करने के तरीके के रूप में वास्तु निर्णय रिकॉर्ड के अनुरूप कुछ का उपयोग भी कर सकते हैं ।


9

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

यदि आप निश्चित नहीं हैं, तो प्रत्येक "अप्रयुक्त" विधि की शुरुआत में एक जोर () डालें। शायद यह कहा जाता है। या एक लॉगिंग स्टेटमेंट।

शायद कोड वास्तव में मूल्यवान है। यह नया कोड हो सकता है कि एक सहकर्मी दो सप्ताह से काम कर रहा है, और वह कल को चालू करने जा रहा है। इसे आज नहीं कहा जाता है क्योंकि इसमें कॉल कल जोड़ा जाएगा।

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

दिलचस्प है, सबसे खराब संभव सलाह "हटाएं। प्रतिबद्ध। भूल जाओ।" उच्चतम मूल्यांकन किया गया है। (कोड समीक्षा? आप कोड समीक्षा नहीं करते हैं? यदि आप कोड समीक्षा नहीं करते हैं तो आप पृथ्वी पर क्या कर रहे हैं?


मैं "DELETE। COMMIT। FORGET" के बारे में सम्मानपूर्वक असहमत हूं। (मुझे लगता है कि यह सबसे अच्छा है।)। आपका दृष्टिकोण भी ठीक है। मुझे लगता है कि सबसे खराब सलाह यूनिट परीक्षणों को लिखने की होगी जो "मृत कोड" का उपयोग करते हैं, लेकिन कोई दावा नहीं करते हैं। कोड कवरेज टूल को यह सोचकर मूर्ख बनाया जाएगा कि उनका उपयोग किया जाता है।
एमोरी

3
"डिलीट। कमिट। फॉरगेट" जवाब में कुछ भी नहीं कहते हैं कि कोड की समीक्षा न करें। यह पूरी तरह से संभव है (और सलाह देने योग्य, IMHO) कोड की समीक्षा करने के बाद यह प्रतिबद्ध है (लेकिन तैनाती से पहले :-))।
sleske

@ स्केलेक आप कोड की समीक्षा कैसे करते हैं जो अब नहीं है? न ही वह उत्तर "समीक्षा" का उल्लेख करता है।
user949300

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

1
@ user949300: जैसा कि "आप कोड की समीक्षा कैसे करते हैं जो अब नहीं है" - मुझे उम्मीद है कि यह स्पष्ट है: अपनी पसंद के संस्करण नियंत्रण उपकरण में परिवर्तन को देखकर। आप अन्य परिवर्तनों (किसी भी परिवर्तन) की समीक्षा कैसे करेंगे?
sleske

6

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

यह केवल विधि को हटाने की तुलना में अधिक सतर्क दृष्टिकोण है, और यदि आप अत्यधिक दोष-संवेदनशील वातावरण में चल रहे हैं तो यह उपयोगी हो सकता है।

हम #unreachable-codeहटाने के लिए प्रत्येक उम्मीदवार के लिए एक विशिष्ट पहचानकर्ता के साथ एक समर्पित सुस्त चैनल में प्रवेश करते हैं , और यह बहुत प्रभावी साबित होता है।



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