तुम नहीं।
सॉफ्टवेयर की गुणवत्ता वास्तव में मुश्किल से मापी जाती है। काफी मुश्किल है कि कोई समाधान नहीं है। मैं इस सवाल का जवाब देने से इनकार कर रहा हूं कि क्या कोई समाधान हो सकता है, लेकिन केवल इस बात को इंगित करें कि किसी को परिभाषित करना वास्तव में कठिन क्यों होगा।
यथास्थिति द्वारा तर्क
जैसा कि किलियन फोथ ने कहा, "अच्छा" सॉफ़्टवेयर के लिए एक सरल उपाय था, तो हम सभी इसका उपयोग करेंगे और हर कोई इसकी मांग करेगा।
ऐसी परियोजनाएं हैं जिनमें प्रबंधकों ने कुछ मैट्रिक्स को लागू करने का निर्णय लिया है। कभी-कभी यह काम करता था, कभी-कभी ऐसा नहीं होता था। मुझे किसी महत्वपूर्ण सहसंबंध के बारे में जानकारी नहीं है। विशेष रूप से महत्वपूर्ण सिस्टम सॉफ़्टवेयर (हवाई जहाज, कार आदि के बारे में सोचें) में SW गुणवत्ता के "सुनिश्चित" करने के लिए मेट्रिक्स की बहुत अधिक आवश्यकताएं हैं - मुझे किसी भी अध्ययन के बारे में पता नहीं है जिससे पता चलता है कि इन आवश्यकताओं के परिणामस्वरूप वास्तव में उच्च गुणवत्ता होती है, और मेरे पास व्यक्तिगत अनुभव हैं इसके विपरीत।
प्रति-बुद्धि द्वारा तर्क करना
इसके अलावा पहले से ही किलियन द्वारा संकेत दिया गया है, और आम तौर पर "हर मीट्रिक कैन और खेला जाएगा" के रूप में चित्रित किया गया है।
मीट्रिक खेलने का क्या मतलब है? यह डेवलपर्स के लिए एक मजेदार खेल है: आप सुनिश्चित करते हैं कि मीट्रिक मूल्य वास्तव में अच्छे दिखते हैं, जबकि वास्तव में चमकदार सामान करते हैं।
मान लें कि आप प्रति LOC दोषों को मापते हैं। मैं कैसे खेलने जा रहा हूँ? आसान - बस अधिक कोड जोड़ें! बेवकूफ कोड बनाएं जिसके परिणामस्वरूप 100 से अधिक लाइनें न हों और अचानक आपको प्रति एलओसी कम दोष हो। सभी के सर्वश्रेष्ठ: आप वास्तव में इस तरह से सॉफ्टवेयर की गुणवत्ता में कमी आई है।
टूल की कमियों का दुरुपयोग किया जाता है, परिभाषाओं को उनके अधिकतम तक फैलाया जाता है, पूरी तरह से नए तरीके का आविष्कार किया जाता है। मूल रूप से, डेवलपर्स वास्तव में स्मार्ट लोग हैं और क्या आपको अपनी टीम में सिर्फ एक डेवलपर होना चाहिए जिसमें मज़ा है मेट्रिक्स खेलना, फिर आपके मैट्रिक्स संदिग्ध होंगे।
यह कहना नहीं है कि मैट्रिक्स हमेशा खराब होते हैं - लेकिन इन मैट्रिक्स के प्रति टीम का रवैया महत्वपूर्ण है। विशेष रूप से, इसका तात्पर्य है कि यह किसी भी उपमहाद्वीप / 3 पार्टी विक्रेता संबंध के लिए अच्छा काम नहीं करेगा।
गलत लक्ष्य करके तर्क करना
आप जो कुछ मापना चाहते हैं, वह सॉफ्टवेयर की गुणवत्ता है। आप जो मापते हैं वह एक या अधिक मीट्रिक है।
आप क्या मापते हैं और आप क्या मानते हैं, इसके बीच एक अंतर है जो आपको बताएगा। यह अंतर बहुत बड़ा है।
यह हमारे चारों ओर सभी प्रकार के व्यवसायों में हर समय होता है। कभी KPI (मुख्य प्रदर्शन संकेतक) पर आधारित निर्णय देखा गया है? यह सिर्फ एक ही समस्या है - आप चाहते हैं कि एक कंपनी अच्छा करे, लेकिन आप कुछ और मापें।
क्वांटिफ़िबिलिटी द्वारा तर्क
मेट्रिक्स को मापा जा सकता है। केवल यही कारण है कि हम उनके साथ बिल्कुल व्यवहार करते हैं। सॉफ्टवेयर गुणवत्ता, हालांकि, इन मापने योग्य संस्थाओं से परे का विस्तार करती है और इसके लिए बहुत कुछ है जो इसे निर्धारित करना बहुत कठिन है: स्रोत कोड कितना पठनीय है? आपका डिज़ाइन कितना एक्स्टेंसिबल है? नई टीम के सदस्यों के लिए जहाज पर चलना कितना कठिन है? आदि आदि।
केवल मेट्रिक्स द्वारा सॉफ़्टवेयर की गुणवत्ता को देखते हुए और गुणवत्ता के कुछ हिस्सों पर नज़र रखना, जिन्हें आप निर्धारित नहीं कर सकते, निश्चित रूप से अच्छी तरह से काम नहीं करने वाले हैं।
संपादित करें:
सारांश
मैं यह बताना चाहता हूं कि उपरोक्त सभी उद्देश्यपूर्ण रूप से देखते हुए है कि सॉफ्टवेयर मैट्रिक्स के आधार पर अच्छा है या बुरा। इसका मतलब है, यह इस बारे में कुछ नहीं कह रहा है कि आपको मेट्रिक्स लागू करना चाहिए या नहीं।
वास्तव में, यह एक यूनिडायरेक्शनल निहितार्थ है: खराब मैट्रिक्स खराब कोड का अर्थ है। यूनिडायरेक्शनल का मतलब है कि बुरा कोड खराब मेट्रिक्स की गारंटी नहीं देता है, और न ही अच्छे मेट्रिक्स अच्छे कोड की गारंटी देते हैं। दूसरी ओर, इसका मतलब है कि आप सॉफ्टवेयर के एक टुकड़े का न्याय करने के लिए मैट्रिक्स लागू कर सकते हैं - जब आप इस निहितार्थ को ध्यान में रखते हैं।
आप सॉफ्टवेयर ए को मापते हैं, और मेट्रिक्स वास्तव में खराब हो जाते हैं। तब आप निश्चित हो सकते हैं कि कोड की गुणवत्ता खराब है। आप सॉफ्टवेयर बी को मापते हैं और मैट्रिक्स ठीक है, फिर आपके पास कोड गुणवत्ता के बारे में कोई सुराग नहीं है। जब यह वास्तव में सिर्फ "कोड अच्छा => मीट्रिक अच्छा" हो तो "मेट्रिक्स गुड = कोड अच्छा" सोचने में मूर्ख मत बनो।
संक्षेप में, आप गुणवत्ता की समस्याओं को खोजने के लिए मैट्रिक्स का उपयोग कर सकते हैं, लेकिन स्वयं गुणवत्ता नहीं।
