चक्रवाती जटिलता पर्वतमाला [बंद]


27

चक्रीय जटिलता की श्रेणियां क्या हैं? उदाहरण के लिए:

1-5:
6-10 को बनाए रखना आसान है : मुश्किल
11-15: बहुत मुश्किल
20+: असंभव तक पहुंचना

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

मुझे यह मिला :

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

  • 1 और 10 के बीच के तरीकों को सरल और समझने में आसान माना जाता है
  • 10 और 20 के बीच के मान अधिक जटिल कोड को इंगित करते हैं, जो अभी भी समझ से बाहर हो सकता है; हालाँकि, संभावित शाखाओं की अधिक संख्या के कारण परीक्षण अधिक कठिन हो जाता है
  • 20 और इसके बाद के संस्करण एक बहुत बड़ी संख्या में संभावित निष्पादन पथ के साथ कोड के विशिष्ट हैं और केवल बड़ी कठिनाई और प्रयास से पूरी तरह से समझा और परीक्षण किया जा सकता है
  • उच्चतर तरीके, जैसे कि> 50, निश्चित रूप से अप्राप्य हैं

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

क्या साइक्लोमैटिक जटिलता के लिए आम तौर पर स्वीकृत रेंज सूची है?


2
आपको सॉफ़्टवेयर इंजीनियरिंग संस्थान से डेटा मिला, जो एक संगठन है जिसे सॉफ़्टवेयर इंजीनियरिंग में एक नेता के रूप में मान्यता प्राप्त है। मुझे समझ नहीं आ रहा है कि आपका प्रश्न क्या है - आपको साइक्लोमैटिक जटिलता के लिए एक श्रेणी सूची मिली। आप और क्या खोज रहे हैं?
थॉमस ओवेन्स

1
मैंने विभिन्न श्रेणियों को देखा है; यह सिर्फ एक उदाहरण था। और एमएस 25 के तहत किसी भी चीज के लिए "हरा" दिखाता है। मैं सोच रहा था कि क्या कोई एक स्वीकृत सीमा सूची थी। शायद मैंने तब पाया है।
बॉब हॉर्न

1
मैं @ThomasOwens से सहमत हूं, लेकिन मुझे खुशी है कि आपने यह सवाल पूछा। मैंने इसे प्रश्न और उत्तर दोनों के रूप में उकेरा।
इवोरेल

1
स्टीव मैककॉनेल के कोड कम्प्लीट के दूसरे संस्करण में वह सलाह देता है कि 0 से 5 तक का साइक्लोमैटिक कॉम्प्लेक्सिटी आमतौर पर ठीक है, लेकिन आपको पता होना चाहिए कि कॉम्प्लेक्सिटी 6 से 10 रेंज में होनी शुरू होती है। वे आगे बताते हैं कि 10 की जटिलता पर आपको अपने कोड को फिर से भरने पर जोर देना चाहिए।
जिब्बो डेक

जवाबों:


19

मुझे लगता है कि यह आपके प्रोग्रामिंग स्टाफ की क्षमताओं पर निर्भर करता है, और प्रबंधक के रूप में आपकी संवेदनाओं पर किसी छोटे हिस्से में नहीं।

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

यह एक व्यक्तिपरक मीट्रिक है; अपने कोड मेट्रिक्स समाधान पर सेटिंग का मूल्यांकन करें, और इसे एक मीठे स्थान पर समायोजित करें जिसे आप सहज महसूस करते हैं जो आपको समझदार परिणाम देता है।


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

1
बड़े स्विच स्टेटमेंट आमतौर पर ओओपी सिद्धांतों की कमी का संकेत नहीं है, जैसे बहुरूपता? राज्य मशीनों को सुरुचिपूर्ण तरीकों से लागू किया जा सकता है, ओओपी या डिज़ाइन पैटर्न के साथ। नहीं?
बॉब हॉर्न

3
कुछ समस्याओं के लिए जो 'लालित्य' उपयोगी है, दूसरों के लिए यह सिर्फ चीजों को और अधिक भ्रमित करता है। कोई चांदी की गोली नहीं है।
whatsisname

1
-1 के लिए "अन्य प्रोग्रामर पूरी तरह से अच्छा बनाने में पूरी तरह से सक्षम हैं, एक इकाई परीक्षण लिखे बिना बग फ्री प्रोग्राम।" यदि आपने इसका परीक्षण नहीं किया है, तो आप इसके बग को मुक्त नहीं जान सकते।
सेबेस्टियन

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

10

कोई पूर्वनिर्धारित श्रेणियां नहीं हैं और कोई वर्गीकरण कई कारणों से संभव नहीं होगा:

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

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

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

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

  5. जैसा कि रॉबर्ट हार्वे ने पहले ही ऊपर कहा था , यह टीम पर ही निर्भर करता है।

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

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

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


2
+1 मैं हर बात से सहमत हूं। साइक्लोमैटिक जटिलता या एलओसी केवल मैट्रिक्स हैं जो आपको स्थिर कोड विश्लेषण द्वारा सौंपे जाते हैं। स्थैतिक विश्लेषक महान उपकरण हैं, लेकिन उनमें सामान्य ज्ञान की कमी है। इन मेट्रिक्स को मानव मस्तिष्क द्वारा संसाधित किया जाना चाहिए, अधिमानतः एक अनुभवी प्रोग्रामर से संबंधित। इसके बाद ही आप यह बता सकते हैं कि क्या कोई खास सॉफ्टवेयर बेकार है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.