स्रोत कोड के लिए उपयोगी मीट्रिक क्या हैं? [बन्द है]


33

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

उदाहरण के लिए, मेट्रिक्स, जैसे (निष्पादन योग्य?) कोड या साइक्लोमैटिक कॉम्प्लेक्सिटी की लाइनें गुणवत्ता आश्वासन के साथ कैसे मदद करती हैं या वे सॉफ़्टवेयर विकास प्रक्रिया के लिए सामान्य रूप से कैसे फायदेमंद हैं?


37
एकमात्र वैध उपाय डब्ल्यूटीएफ / सेकंड है। :)
टर्मिनस


जवाबों:


30

"कोड की तर्ज पर सॉफ्टवेयर उत्पादकता को मापना एक हवाई जहाज पर प्रगति को मापने से है कि इसका वजन कितना है।" - बिल गेट्स


3
कृपया गैर-उत्तर अपडेट न करें।
एरिक विल्सन

3
एक मनोरंजक उपाख्यान करते समय, यह उत्तर इस प्रश्न के उत्तर में योगदान करने के लिए बहुत कम करता है।
क्रिस नाइट

7
@ क्रिस इस जवाब को बहुत अधिक वोट मिले (या "अपडेट" जैसा कि फार्मबॉय इसे कॉल करना चाहते हैं) क्योंकि कई डेवलपर्स का मानना ​​है कि सॉफ्टवेयर मैट्रिक्स बेकार हैं। यदि आप असहमत हैं या महसूस करते हैं कि आपके पास सवाल का बेहतर जवाब है, तो अपना जवाब दें। आपके द्वारा यहां किया गया टिप्पणी करना उत्पादक नहीं है; आपने अपना कुछ भी योगदान नहीं दिया है।
चिरसायकॉक

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

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

12

इस विषय पर जेफ की पोस्टों पर एक नज़र डालें:

मेट्रिक्स नौकरानी से एक यात्रा

सॉफ्टवेयर इंजीनियरिंग: मृत?

एक पुराना है, लेकिन अच्छा है, जोएल से पोस्ट भी है, सॉफ्टवेयर मेट्रिक्स से निकटता से संबंधित है, और मैं दृढ़ता से इसके पढ़ने की सलाह देता हूं: ईओ 101 प्रबंधन विधि

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


जेफ के वन-लाइनर को उद्धृत करने के लिए +1। शुद्ध, युद्ध-युक्त ज्ञान वहीं।
luis.espinal

11

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

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

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

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

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

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


8

क्या यह "सोर्स कोड मेट्रिक्स" बकवास नहीं होगा?

कोड (SLOC) की कच्ची स्रोत लाइनें सबसे पुरानी, ​​सबसे आसान, सबसे बुनियादी मीट्रिक है।

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

उस समय, Halstead के मैट्रिक्स को छोड़ दिया गया था, क्योंकि SLOC को मापना हमेशा आसान होता है।


1
अध्ययन के लिए कोई लिंक?
जॉन हॉपकिंस

Google आपका FRIEND है, लेकिन आपको आरंभ करने के लिए यहां एक है। ecs.csun.edu/~rlingard/comp589/HoffmanArticle.pdf
जॉन आर। स्ट्रॉहम

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

मैं कहूंगा कि वास्तविक दुनिया में, ये सभी अध्ययन कीचड़ में बदल जाते हैं।
वॉरेन पी

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

8

दो उद्देश्यों के लिए गुणवत्ता आश्वासन के लिए स्रोत कोड मैट्रिक्स:

  • अंदर कम बग के साथ कोड लिखना
  • आसान रखरखाव के लिए कोड लिखना

दोनों संभव के रूप में सरल लेखन कोड के लिए सीसा। इसका मतलब है की:

  • कोड की छोटी इकाइयाँ (कार्य, विधियाँ)
  • प्रत्येक इकाई में कुछ तत्व (तर्क, स्थानीय चर, कथन, पथ)
  • और कई अन्य मापदंड अधिक या कम जटिल ( विकिपीडिया में सॉफ़्टवेयर मीट्रिक देखें )।

7

मेरे ज्ञान का सबसे अच्छा करने के लिए, पाया कीड़े की संख्या सीधे कोड (शायद मंथन), modulo भाषा, प्रोग्रामर, और डोमेन की लाइनों के साथ संबंधित है।

मैं किसी भी अन्य सीधे और व्यावहारिक मैट्रिक अच्छी तरह से बग के साथ सहसंबद्ध नहीं जानता।

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


1
तो अधिक कोड वहाँ और अधिक कीड़े वहाँ रहे हैं?

3
@ थोर: l येप यप। शॉकर, हुह?
पॉल नाथन

जहां तक ​​मुझे याद है कि विशिष्ट उद्योग संख्या औसत परियोजनाओं के लिए कोड की प्रति 1000 लाइनों में लगभग 2-3 त्रुटियां हैं, परमाणु संयंत्र नियंत्रण सॉफ्टवेयर या नासा परियोजनाओं के लिए कोड की 1000 पंक्तियों की तरह 0.5 त्रुटियों के करीब पहुंचना जहां वे प्रयास की एक बड़ी राशि डालते हैं। , नियंत्रण, परीक्षण, समीक्षा आदि, क्योंकि असफलताओं के बहुत गंभीर परिणाम हो सकते हैं। किसी को भी है कि यह समर्थन संख्याओं के लिए कुछ संदर्भ है?
hlovdal

2
@ क्लोवल्ड: केएसएलओसी प्रति 2-3 त्रुटियां पहले से ही बहुत कम है। एयरोस्पेस और सुरक्षा डोमेन से सबसे कम आंकड़े मुझे पता है कि केएसओएलसी प्रति 0.1 त्रुटियों का क्रम है। केएसओसीएल में प्रति व्यक्ति 20 से 50 त्रुटियां प्रतीत होती हैं। संदर्भ के लिए, एंडी जर्मन के पेपर के लिए Google ने "सॉफ़्टवेयर स्टेटिक कोड विश्लेषण - सबक सीखा" शीर्षक दिया।
शेडलर

1
मैं इन आंकड़ों पर विवाद करूंगा - यह पूरी तरह से भाषा, संकलक और निष्पादन योग्य वातावरण पर निर्भर करता है। जावास्क्रिप्ट कोड में टाइपो को खोजने में कई साल लग सकते हैं, लेकिन एक संकलित भाषा में एक टाइपो पहले संकलन पर मिलेगा।
JBRWilkinson

7

मेट्रिक्स केवल उपयोगी होते हैं यदि आप जानते हैं कि आपको प्राप्त उत्तरों के साथ क्या करना है। संक्षेप में एक सॉफ्टवेयर मीट्रिक थर्मामीटर की तरह होता है। यह तथ्य कि आप 98.6 ° F पर कुछ मापते हैं, इसका कोई मतलब नहीं है जब तक आप यह नहीं जानते कि सामान्य तापमान क्या है। उपरोक्त तापमान शरीर के तापमान के लिए अच्छा है लेकिन वास्तव में आइसक्रीम के लिए बुरा है।

सामान्य मीट्रिक जो उपयोगी हो सकते हैं वे हैं:

  • कीड़े की खोज / सप्ताह
  • कीड़े हल / सप्ताह
  • # आवश्यकताएँ परिभाषित / जारी
  • # आवश्यकताएं लागू / जारी

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

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

जमीनी स्तर

आपके द्वारा लिए गए प्रत्येक माप में निम्नलिखित परिभाषित होना चाहिए या यह बेकार है:

  • "सामान्य" क्या है की समझ। यह परियोजना के जीवन पर समायोजित किया जा सकता है।
  • "सामान्य" के बाहर एक दहलीज जहां आपको किसी प्रकार की कार्रवाई करने की आवश्यकता होती है।
  • सीमा से अधिक होने पर कोड से निपटने की योजना।

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

मीट्रिक सिर्फ एक थर्मामीटर है, आप इसके साथ क्या करते हैं यह आपके ऊपर है।


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

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

6

स्रोत कोड एक देनदारी है, न कि एक परिसंपत्ति। इस बात को ध्यान में रखते हुए, घर बनाते समय खर्च की गई डॉलर की ट्रैकिंग के अनुरूप कोड की माप होती है। यदि आप बजट के तहत रहना चाहते हैं, तो यह करने की आवश्यकता है, लेकिन आप जरूरी नहीं सोचते कि एक दिन में $ 1000 खर्च करना एक दिन में $ 50 खर्च करने से बेहतर है; आप जानना चाहेंगे कि उस पैसे के लिए घर का कितना निर्माण हुआ। यह एक सॉफ्टवेयर प्रोजेक्ट में कोड की लाइनों के साथ समान है।

संक्षेप में, स्रोत कोड के लिए कोई उपयोगी मीट्रिक नहीं हैं क्योंकि स्रोत कोड को स्वयं मापना उपयोगी नहीं है।


4

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


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

+1 अधिक स्रोत कोड जरूरी बेहतर नहीं है।
लैरी कोलेमन

केवल बहुत ही सरल अनुप्रयोग 100% परीक्षण कवरेज (कवरेज को अनावश्यक बनाने) के लिए उत्तरदायी हैं। यह जटिल सॉफ्टवेयर के लिए 100% परीक्षण कवरेज प्राप्त करने के लिए कम्प्यूटेशनल रूप से महंगा है (यदि नहीं)। हम इस तथ्य को जानते हैं कि 6 दशकों से इस तरह के आधार हैं। दूसरे, परीक्षण केवल आपको बताता है कि आपने बग नहीं पाया है - यह आपको गारंटी नहीं देता है कि संरचनात्मक गुणवत्ता, आकार या जटिलता के बारे में कोई कीड़े नहीं हैं (कुछ लंबे समय के लिए भी जाना जाता है।) काम करते समय इन तथ्यों को नहीं जानते हैं। सॉफ्टवेयर में एक भौतिक विज्ञानी के लिए वास्तव में ऊष्मप्रवैगिकी के नियमों को नहीं जानता है।
luis.espinal

@ luis.espinal सॉफ्टवेयर इतना बड़ा है कि परीक्षण के लिए बहुत महंगा है अविश्वसनीय रूप से खराब लिखा सॉफ्टवेयर है। यह कैसे काम कर सॉफ्टवेयर बनाने के लिए पर कोई सुराग नहीं है के करीब है।
पाब्लो एरियल

@PabloAriel - "सॉफ्टवेयर इतना बड़ा है कि परीक्षण करने के लिए बहुत अधिक महंगा है" << यह वही नहीं है जो मैंने कहा था। यह सुनिश्चित करने के लिए टिप्पणी (शायद दो या तीन बार) पढ़ें कि आप वास्तव में वही पढ़ रहे हैं जो आपको लगता है कि आप पढ़ रहे हैं।
luis.espinal

4

एक उपाख्यान यह दिखाने के लिए कि KLOC गणना प्रदर्शन के लिए क्यों बेकार (और हानिकारक भी है)।

वर्षों पहले मैंने एक बड़े प्रोजेक्ट पर काम किया (हमारी कंपनी में 70+ लोग, हमारे ग्राहक पर एक और 30+) जिसने KLOC का उपयोग टीमों और व्यक्तियों के प्रदर्शन के एकमात्र उपाय के रूप में किया।

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

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

कुछ महीने बाद (इस तरह की चीजों में समय लगता है) हमें बताया गया कि कंपनी उनके उत्पादकता मानकों की समीक्षा कर रही थी और उन्होंने फंक्शन पॉइंट विश्लेषण के आधार पर एक नई प्रणाली बनाने के लिए विशेषज्ञों की एक टीम को नियुक्त किया था।


तुम सिर्फ अलग क्यों नहीं दिखाया ?!
रीइन्टीरियरपोस्ट

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

2
आपका जवाब नहीं दिखाता है कि KLOC बेकार है, यह दिखाता है कि उनका उपयोग कैसे नहीं किया जाए।
नील एन

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

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

2

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

कोड कवरेज इस मायने में उपयोगी है कि आप जानते हैं कि आवेदन का कितना प्रतिशत विनाशकारी रूप से विफल नहीं होता है; इसकी उपयोगिता के बाकी हिस्सों के साथ यूनिट परीक्षणों की गुणवत्ता पर निर्भर करता है।


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

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

1

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

जब तक कोई प्रतिबद्ध निर्माण को तोड़ता है ...


1

ये प्रगति के मामले में बहुत उपयोगी निरपेक्ष मीट्रिक नहीं हैं , लेकिन कोड की स्थिति का एक सामान्य विचार देने के लिए उपयोग किया जा सकता है।

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


1

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

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


1

मेरे काम की कई स्थितियाँ हैं जहाँ मैं कोड मेट्रिक्स का उपयोग करता हूँ:

कोड लिखते समय

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

डेवलपर्स सभी नियमों को तोड़ने के लिए पूरी तरह से स्वतंत्र हैं क्योंकि वे सभी स्थितियों पर कभी भी लागू नहीं होंगे। "नियम" विचार को उत्तेजित करने के लिए हैं और कहते हैं "अरे, क्या यह ऐसा करने का सबसे अच्छा तरीका है?"

क्यूए / कोड समीक्षा के दौरान

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

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

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

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

ट्रेंडिंग, विचार-विमर्श या आगे के तरीकों के लिए शुरुआती बिंदुओं के रूप में मीट्रिक का उपयोग करने के लिए महत्वपूर्ण चीजें हैं और सटीक आंकड़ों के लिए उन्हें धार्मिक रूप से प्रबंधित करने के लिए नहीं। लेकिन मेरा दृढ़ता से मानना ​​है कि जब आप ठीक से उपयोग करते हैं तो वे आपको कोड को बेहतर बनाने में मदद कर सकते हैं।


0

प्रश्न: सोर्स कोड के लिए कैप्चर करने के लिए उपयोगी मेट्रिक्स क्या हैं?

व्यापार के लिए:

उ: मानव-घंटे की संख्या

कोडर के पर्यवेक्षक के लिए:

A: कोई बात नहीं। चलो आज सब करते हैं

कोडर के आत्म-सम्मान के लिए:

ए: एसएलओसी की संख्या (कोड की स्रोत लाइनें)

कोडर की माँ के लिए:

A: इन नरम फ्रेंच रोल्स का अधिक सेवन करें और चाय पिएं

नीचे टिप्पणियों में जारी ...


-1

याद रखें: सभी कोड कम से कम 1 निर्देश द्वारा कम किए जा सकते हैं। सभी कोड में कम से कम 1 बग है। इसलिए, सभी कोड को एक एकल निर्देश पर कम किया जा सकता है जो काम नहीं करता है। उम्मीद है की वो मदद करदे!


और कम sideeffects के साथ।

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