4.1 कोड जटिलता मेट्रिक्स

अवलोकन और प्रेरणा

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

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

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

प्रमुख सिद्धांत

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

सिफ़ारिशें

समीक्षा और रीफ़ैक्टरिंग प्रयास को ट्राएज करने के लिए जटिलता मेट्रिक्स का उपयोग करें

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

अपनी सीमाएँ एक सार्वभौमिक संख्या की बजाय अपने स्वयं के कोडबेस के सापेक्ष निर्धारित करें

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

वास्तविक सरलीकरण के बिना विघटन के माध्यम से चालाकी के लिए देखें

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

प्रतिक्रिया देने से पहले आवश्यक जटिलता को आकस्मिक जटिलता से अलग करें

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

केवल एक स्नैपशॉट औसत नहीं, प्रवृत्ति और आउटलायर ट्रैक करें

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

समझौते: लाभ और हानि

दृष्टिकोण	लाभ	हानि
पूर्ण सार्वभौमिक सीमा	सरल, सुसंगत, स्वचालित करना आसान	वैध डोमेन अंतरों को नज़रअंदाज़ करती है; विघटन द्वारा चालाकी की जा सकती है
कोडबेस-सापेक्ष सीमा	वास्तविक संदर्भ के लिए बेहतर कैलिब्रेट	अधिक सेटअप और समय-समय पर पुनः कैलिब्रेशन की आवश्यकता
एक स्वचालित बिल्ड गेट के रूप में जटिलता	मानवीय समीक्षा ओवरहेड के बिना सुसंगति लागू करती है	वैध रूप से जटिल लेकिन अच्छी तरह-डिज़ाइन किए गए कोड को अवरुद्ध कर सकती है, या विरूपित विघटन को पुरस्कृत कर सकती है
मानवीय समीक्षा के लिए एक ट्राएज संकेत के रूप में जटिलता	वास्तविक गुणवत्ता समस्याओं को पकड़ती है जिन्हें अकेला विघटन चूक जाएगा	पूरी तरह स्वचालित गेट से अधिक मानवीय समीक्षा समय की आवश्यकता

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

अपनी टीम के साथ चर्चा करने के प्रश्न

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

क्षेत्र दृष्टिकोण

स्टार्टअप। इस पैमाने पर जटिलता मेट्रिक्स आमतौर पर कम अत्यावश्यक होते हैं; कोडबेस का आकार इतना छोटा है कि अनौपचारिक परिचितता अक्सर औपचारिक माप को प्रतिस्थापित करती है। शुरुआत में अपनाने लायक़ आदत बस कभी-कभार एक जटिलता स्कैन चलाना है ताकि एक विशिष्ट फ़ाइल को चुपचाप अप्रबंधनीय होने से पकड़ा जा सके इससे पहले कि टीम इतनी बड़ी हो जाए कि अनौपचारिक रूप से नोटिस न कर सके।

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

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

सरकार। दीर्घजीवी सरकारी प्रणालियाँ अक्सर वृद्धिशील आवश्यकता परिवर्तनों के वर्षों या दशकों में धीरे-धीरे जटिलता जमा करती हैं, और एक जटिलता ऑडिट उन रुचिधारकों के लिए आधुनिकीकरण या रीफ़ैक्टरिंग निवेश को न्यायोचित ठहराने के लिए एक प्रेरक, ठोस उपकरण हो सकता है जो अन्यथा प्रणाली को केवल “काम कर रही” मान सकते हैं और इसलिए निवेश के लायक़ नहीं।

उदाहरण

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

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

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

कुल स्वामित्व लागत कम है: अधिकांश आधुनिक विकास टूलचेन स्थैतिक विश्लेषण (विषय 4.4) के हिस्से के रूप में स्वचालित रूप से जटिलता मेट्रिक्स की गणना करते हैं, और वास्तविक निवेश परिणामों की सही व्याख्या करने का मानवीय निर्णय समय है, आवश्यक को आकस्मिक जटिलता से अलग करना और विघटन चालाकी को पकड़ना, किसी महत्वपूर्ण नई टूलिंग लागत की बजाय।

विरोधी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

स्तर 1, आरंभ: जटिलता को मापा नहीं जाता, या बिना आलोचना लागू एक अनजाँची, सामान्य सार्वभौमिक सीमा के साथ मापा जाता है।
स्तर 2, विकास: जटिलता मेट्रिक्स एकत्र किए जाते हैं लेकिन शायद ही कभी उन पर कार्य किया जाता है, और आवश्यक और आकस्मिक जटिलता के बीच कोई भेद नहीं किया जाता।
स्तर 3, मानकीकरण: सीमाएँ कोडबेस के अपने वितरण के लिए कैलिब्रेट की जाती हैं, और जटिलता मेट्रिक्स लगातार संगठन-व्यापी समीक्षा और रीफ़ैक्टरिंग ट्राएज को चलाते हैं।
स्तर 4, प्रबंधन: जटिलता प्रवृत्ति और आउटलायरों की सक्रिय रूप से निगरानी की जाती है और रीफ़ैक्टरिंग निवेश को प्राथमिकता देने के लिए चर्न डेटा (विषय 4.3) के साथ जोड़ा जाता है; विघटन चालाकी के लिए सक्रिय रूप से देखा जाता है।
स्तर 5, संयोजन: संगठन जटिलता-सूचित रीफ़ैक्टरिंग निवेश से सीधे ट्रेस किए गए विशिष्ट, मापने योग्य दोष-दर सुधारों की ओर इशारा कर सकता है, और जटिलता डेटा इंजीनियरिंग निवेश निर्णयों के लिए एक नियमित, विश्वसनीय इनपुट है।

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

McCabe, Thomas J., “A Complexity Measure,” IEEE Transactions on Software Engineering (1976): मूल साइक्लोमैटिक जटिलता पेपर।
Code Complete, by Steve McConnell (सॉफ़्टवेयर निर्माण में जटिलता प्रबंधित करने पर व्यावहारिक मार्गदर्शन)।
Working Effectively with Legacy Code, by Michael Feathers (मौजूदा, बदलने में कठिन कोड में जटिलता को सुरक्षित रूप से कम करने की तकनीकें)।
Campbell, G. Ann, “Cognitive Complexity: A New Way of Measuring Understandability” (SonarSource, 2018): संज्ञानात्मक जटिलता मेट्रिक और साइक्लोमैटिक जटिलता से इसका भेद।