कोड गुणवत्ता क्या है और इसे क्यों मापना है

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

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

• नियमों का अनुपालन;
• कोड जटिलता
• नकल;
• कमेंटरी;
• परीक्षण कवरेज।

अब उनमें से प्रत्येक पर विचार करें।

नियमों का अनुपालन

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

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

यहां मीट्रिक स्पष्ट है: नियमों का अनुपालन 100% के लिए प्रयास करना चाहिए, अर्थात्, नियमों का कम उल्लंघन बेहतर होगा।

चक्रीय कोड जटिलता

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

डुप्लिकेट

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

टिप्पणी

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

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

जैसा कि मैंने पहले ही लिखा था, कंपनी की जरूरतों के आधार पर कोड पर टिप्पणी करने का सवाल सबसे अच्छा है, लेकिन टिप्पणी कोड के साथ रहना बेहतर है।

टेस्ट कवरेज

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

• फ़ाइल कवरेज - यहां आपको यह निर्धारित करने की आवश्यकता है कि यह समझने के लिए कि फ़ाइल परीक्षणों द्वारा कवर की गई है: अक्सर फ़ाइल को कवर किया जाता है यदि परीक्षण फ़ाइल में गिर गया और फ़ाइल से कम से कम एक कोड कोड निष्पादित किया गया। इसलिए, ऐसी मीट्रिक का उपयोग शायद ही कभी किया जाता है, लेकिन यह अभी भी अस्तित्व का अधिकार है।
• क्लास कवरेज - फाइल कवरेज के साथ, केवल क्लास कवरेज :)। इसके अलावा शायद ही कभी इस्तेमाल किया।
• विधि कवरेज मैट्रिक्स की गणना करने का एक ही तरीका है। सच है, विधियों का कवरेज व्यापक वितरण पा सकता है: यदि आपके पास कम से कम एक परीक्षण के साथ प्रत्येक विधि को कवर करने के लिए परियोजना पर एक नियम है, तो इस मीट्रिक का उपयोग करके आप जल्दी से कोड पा सकते हैं जो नियमों का पालन नहीं करता है।
• पंक्ति कवरेज सबसे अधिक उपयोग की जाने वाली कवरेज मीट्रिक है। पथरी का एक ही तरीका, केवल ob'ek के लिए एक स्ट्रिंग लेता है।
• शाखा कवरेज - समान, क्रमशः, शाखा के लिए तत्व लिया जाता है। इस मीट्रिक का एक अच्छा संकेतक सबसे अधिक प्रयास के लायक है। इस मीट्रिक के आधार पर, कोई यह निर्धारित कर सकता है कि प्रोग्रामर ने परीक्षण कवरेज के लिए कैसे शर्म की।
• कुल कवरेज वह कवरेज मीट्रिक है जिसमें एक तत्व नहीं बल्कि कई गणनाओं में ध्यान में रखा जाता है। सबसे आम उपयोग लाइनों और शाखाओं का कुल कवरेज है।

परीक्षण कवरेज जितना अधिक होगा, सिस्टम के हिस्से को तोड़ने और इसे किसी के ध्यान न देने का जोखिम कम होगा।

एक निष्कर्ष के बजाय

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