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