🤾🏿 🕚 👼🏽 क्यों आपको अपनी विकास प्रक्रिया में एकीकृत करने के लिए पीवीएस-स्टूडियो स्टेटिक विश्लेषक का चयन करना चाहिए 👎🏿 👆🏽 💝

आपको अपनी विकास प्रक्रिया में एकीकृत करने के लिए पीवीएस-स्टूडियो स्टेटिक विश्लेषक का चयन क्यों करना चाहिए

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

स्थैतिक कोड विश्लेषण

जैसे-जैसे सॉफ्टवेयर प्रोजेक्ट विकसित होते हैं, वे आकार में बढ़ते जाते हैं। की तुलना करें:

लिनक्स कर्नेल 1.0.0: 176,000 LOC
लिनक्स कर्नेल 5.0: 26,000,000 LOC
फोटोशॉप 1.0: 128,000 LOC
फोटोशॉप सीएस 6: 10,000,000 LOC

जैसे-जैसे परियोजना बढ़ती है, इसकी जटिलता रैखिक रूप से तेजी से बढ़ती है। यह बताता है कि कोडबेस के साथ त्रुटि घनत्व क्यों बढ़ता है । बढ़ती जटिलता के लिए बनाने के तरीकों में से एक स्थिर कोड विश्लेषण टूल का उपयोग करना है।

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

स्थैतिक विश्लेषण प्रतिस्थापित नहीं करता है - बल्कि पूरक - कोड समीक्षा, इकाई परीक्षण, गतिशील विश्लेषण, प्रतिगमन परीक्षण, मैनुअल परीक्षण, और इतने पर जैसे अन्य बग-डिटेक्टिंग प्रथाओं।

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

स्थैतिक विश्लेषण उपकरण का एक और लाभ व्यापक त्रुटि पैटर्न आधार है। वे ऐसे दोष पा सकते हैं जो कई प्रोग्रामर को भी पता नहीं हो सकते हैं, जैसे कि V698 , V718 , V1023 ।

पी वी एस-स्टूडियो

हम पीवीएस-स्टूडियो, हमारी टीम द्वारा विकसित एक स्थिर कोड विश्लेषक चुनने की सलाह देते हैं। यह 64-बिट विंडोज, लिनक्स और मैकओएस सिस्टम पर चलता है और 32-बिट, 64-बिट और एम्बेडेड एआरएम प्लेटफार्मों के लिए कार्यक्रमों के स्रोत कोड की जांच कर सकता है।

इस लेखन के अनुसार, विश्लेषक निम्नलिखित भाषाओं और संकलकों का समर्थन करता है:

विंडोज। विज़ुअल स्टूडियो 2010-2019 C, C ++, C ++ / CLI, C ++ / CX (WinRT), C #
विंडोज। आईएआर एंबेडेड वर्कबेंच, एआर / सी के लिए सी / सी ++ कंपाइलर, सी ++
विंडोज। क्यूएनएक्स मोमेंटिक्स, क्यूसीसी सी, सी ++
विंडोज / लिनक्स केएल ilविज़न, डीएस-एमडीके, एआरएम कंपाइलर 5/6 सी, सी ++
विंडोज / लिनक्स टेक्सास इंस्ट्रूमेंट्स कोड कम्पोज़र स्टूडियो, एआरएम कोड जेनरेशन टूल्स सी, सी ++
विंडोज / लिनक्स / मैकओएस। जीएनयू आर्म एंबेडेड टूलचिन, आर्म एंबेडेड जीसीसी कंपाइलर, सी, सी ++
विंडोज / लिनक्स / मैकओएस। क्लेंग सी, सी ++
लिनक्स / macOS। जीसीसी सी, सी ++
विंडोज। MinGW C, C ++
विंडोज / लिनक्स / मैकओएस। जावा

विश्लेषक अंग्रेजी और रूसी में विस्तृत प्रलेखन के साथ आता है। नैदानिक नियमों के विवरण में सही और गलत कोड के उदाहरण शामिल हैं। वे वास्तविक ओपन-सोर्स कार्यक्रमों से कोड स्निपेट्स के लिंक भी शामिल करते हैं।

उन विशेषज्ञों के लिए जो पीवीएस-स्टूडियो को एक एसएएसटी उपकरण के रूप में उपयोग करने जा रहे हैं, डायग्नोस्टिक्स को सामान्य कमजोरी एन्यूमरेशन, एसईआई सीईआरटी कोडिंग मानकों और एमआईएसआरए मानक के लिए मैप किया जाता है। यहां विभिन्न मानकों के लिए पीवीएस-स्टूडियो डायग्नोस्टिक्स की मैपिंग टेबल हैं:

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

हमने CI सिस्टम के साथ PVS-Studio के उपयोग के कई परिदृश्य विकसित किए हैं। जैसा कि सभी परिदृश्यों का अवलोकन इस लेख के दायरे से बाहर है, कृपया दस्तावेज़ देखें। यहां आपको सामान्य विचार देने के लिए कुछ लिंक दिए गए हैं:

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

आपको पीवीएस-स्टूडियो का उपयोग क्यों करना चाहिए

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

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

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

पीवीएस-स्टूडियो को कुछ उत्साही लोगों द्वारा विकसित परियोजनाओं में एकीकृत करना संभवतः अव्यवहारिक होगा, लेकिन यहां तक कि छोटी परियोजनाएं भी इससे लाभान्वित हो सकती हैं - सभी और इसलिए जब से हम छात्रों, ओपन-सोर्स डेवलपर्स और इतने पर मुफ्त लाइसेंसिंग विकल्प प्रदान करते हैं ।

हमारे नए ग्राहक आम तौर पर एक साल का लाइसेंस खरीदेंगे। जब यह समाप्त हो जाता है, तो वे पहले से ही हमारे विश्लेषक की क्षमताओं और उपयोगकर्ता समर्थन सेवा के बारे में खुश होते हैं और दो या तीन वर्षों के लिए लाइसेंस को नवीनीकृत करेंगे, जो एक साल के लाइसेंस की तुलना में बहुत सस्ता है। आप कीमतों का अनुरोध कर सकते हैं और यहां लाइसेंस देने के लिए सलाह ले सकते हैं ।

हमारे ग्राहक बनें और पीवीएस-स्टूडियो को आपकी विकास प्रक्रिया को अधिक परिपक्व, बग-फिक्सिंग सस्ता और आपके कोड को बेहतर बनाने दें।

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

आलोचना का जवाब

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

"स्थैतिक विश्लेषण आपके काम के समय की कुछ राशि ले रहा होगा"

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

लोग क्यों मानते हैं कि स्थैतिक विश्लेषक की रिपोर्ट की जाँच समय लेने वाली है?

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

लेख " हैंडलिंग आक्षेप: स्थैतिक विश्लेषण कार्य समय का हिस्सा ले जाएगा " इस विषय पर विस्तृत है।

"स्थैतिक विश्लेषक बहुत अधिक शोर उत्पन्न करते हैं (यानी बहुत सारे झूठे सकारात्मक)"

फिर, यह कथन सही है जब आपने उपकरण को ठीक से अनुकूलित नहीं किया है। एक बार जब आपने पीवीएस-स्टूडियो की सेटिंग्स को आवश्यकतानुसार बदल दिया, तो आप झूठी सकारात्मक दर को 10-20% तक कम करने की उम्मीद कर सकते हैं। यही है, हर पाँच चेतावनियों में से चार वास्तविक बग या कोड की ओर इशारा करते हैं जो भविष्य में बग का स्रोत बनने की बहुत संभावना है। ईएफएल कोर पुस्तकालयों के उदाहरण द्वारा " पीवीएस-स्टूडियो विश्लेषक के चरित्र, 10-15% झूठी सकारात्मकता के लक्षण " लेख विश्लेषक अनुकूलन का एक उदाहरण दिखाता है।

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

"विकास प्रक्रिया में स्थैतिक विश्लेषण को एकीकृत करना प्रयास, समय और धन के मामले में बहुत महंगा है"

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

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

यह इतना भयानक नहीं है। बड़ी पुरानी परियोजनाओं में भी स्थैतिक विश्लेषण को सुचारू रूप से एकीकृत करने के लिए कम से कम तीन अभ्यास हैं।

अभ्यास 1. "रैचिंग", जिसे इवान पोनोमेर्व ने अपने लेख " प्रोसेस में स्टैटिक एनालिसिस का परिचय, इट्स जस्ट सर्च फॉर बग्स इट " से स्पष्ट किया है।

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

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

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

अभ्यास 3. आप हमारे साथ एक अनुबंध बनाकर हमारी टीम को पीवीएस-स्टूडियो स्थापित करने और एकीकृत करने के कार्य को सौंप सकते हैं। इस अभ्यास का एक उदाहरण " पीवीएस-स्टूडियो टीम इम्प्रूव्ड अनरियल इंजन कोड " लेख में वर्णित है।

"हमने विश्लेषक को दौड़ाया, लेकिन इसमें कोई दिलचस्पी नहीं मिली"

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

इस विषय पर लेख " फिलॉस्फी ऑफ स्टैटिक कोड एनालिसिस: वी हैव 100 डिवेलपर्स, एनालाइजर फाउंड फ्यूज बग्स, इज एनालाइजर यूजलेस? " में और अधिक विस्तार से चर्चा की गई है।

"एक स्थिर विश्लेषक एक महंगा उपकरण है; हम बेहतर ढंग से एक अतिरिक्त प्रोग्रामर / परीक्षक को नियुक्त करेंगे »

यह तर्क वास्तव में क्या कहता है कि व्यक्ति कुछ भी बदलना नहीं चाहता है। आखिरकार, उनकी टीम कुछ समय पहले से ही नए प्रोग्रामर और टेस्टर्स को बढ़ा रही है और काम पर रख रही है, लेकिन इससे अधिक परिपक्व विकास प्रक्रिया को प्राप्त करने में मदद नहीं मिली है। उन्होंने कहा, हमें अभी भी इस तर्क पर विस्तार से बात करनी चाहिए।

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

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

"गतिशील विश्लेषण स्थैतिक विश्लेषण से बेहतर है"

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

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

"इकाई परीक्षण स्थैतिक विश्लेषण से बेहतर है"

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

यहाँ इकाई परीक्षण के साथ स्थैतिक विश्लेषण का उपयोग करने के तर्क दिए गए हैं:

परीक्षणों का स्वयं परीक्षण नहीं किया जाता है और अक्सर त्रुटियां होती हैं। हमारे लेखों में, हम वास्तविक परियोजनाओं में यूनिट परीक्षणों में पाए जाने वाले कीड़े के बहुत सारे उदाहरण दिखाते हैं। स्थैतिक विश्लेषण परीक्षणों में कीड़े पा सकते हैं, जो कि उनकी बारी में, मुख्य कोड में कीड़े पा सकते हैं।
परीक्षणों के साथ पूरे कोड को कवर करना मुश्किल है, खासकर उन हिस्सों को जो अपवाद से निपटने के साथ सौदा करते हैं। उनके विपरीत, स्थैतिक विश्लेषक पूरे कोड की जांच करते हैं।
कुछ कीड़े बेहद कठिन हैं, यदि संभव हो तो यूनिट परीक्षणों के माध्यम से पता लगाने के लिए। V597 (CWE-14) ऐसा ही एक उदाहरण है।
कुछ कीड़े स्वयं को तभी प्रकट करते हैं जब प्रोग्राम बड़ी मात्रा में डेटा के साथ काम करता है, इसलिए यूनिट परीक्षणों में ऐसी स्थितियों का अनुकरण करना अव्यावहारिक है। ऐसा ही एक उदाहरण 64-बिट प्रोग्राम ( V108 , V127 ) में 32-बिट चर का अतिप्रवाह है।
जब कोई परीक्षा पास नहीं होती है, तो डिबगिंग की तुलना में स्टैटिक एनालाइजर को चलाकर त्रुटि को अधिक आसानी से और जल्दी पाया जा सकता है। ज़रूर, यूनिट परीक्षणों में और कीड़े मिलेंगे लेकिन जब आप उन्हें एक सस्ती तकनीक (यानी स्थैतिक विश्लेषण) का उपयोग करके पकड़ सकते हैं, तो ऐसा क्यों नहीं करते?
हम विभिन्न परियोजनाओं में कीड़े के ढेर पाते हैं। उनमें से कई परीक्षण के साथ भारी हैं, लेकिन जैसा कि आप देख सकते हैं, वे ज्यादा मदद नहीं करते हैं। इसलिए आपके कोड की गुणवत्ता और विश्वसनीयता बढ़ाने के लिए इकाई परीक्षण के अतिरिक्त स्थैतिक विश्लेषण को अपनाने का कोई कारण नहीं है।

"समकालीन मुक्त संकलक वही कीड़े पा सकते हैं जो पीवीएस-स्टूडियो कर सकते हैं"

यकीन है, संकलक विकसित हो रहे हैं और नई चेतावनियों को प्राप्त कर रहे हैं, जो बग का पता लगा सकते हैं। लेकिन आप पीवीएस-स्टूडियो जैसे पेशेवर मालिकाना समाधानों की तुलना में बहुत सारे कंपाइलरों की उम्मीद नहीं कर सकते।

पीवीएस-स्टूडियो जाने के कारण:

कुशल उपयोगकर्ता समर्थन
अत्यधिक विकसित बुनियादी ढांचा (अन्य उत्पादों के साथ एकीकरण)
शक्तिशाली नैदानिक क्षमता

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

इस बात से अवगत होने के बाद कि ऊपर कहे गए सभी लोग अपने मन को बदलने के लिए पर्याप्त नहीं हैं, हम हर बार संकलक की जाँच करते हैं और यह दिखाने के लिए कि उनके पास कीड़े हैं, जिन्हें पीवीएस-स्टूडियो पता लगा सकता है:

पुनश्च

यदि आपको अभी भी संदेह है कि क्या आपको पीवीएस-स्टूडियो का उपयोग करना चाहिए, तो विभिन्न परियोजनाओं में पाए जाने वाले बगों की इस सूची को देखें।

क्यों आपको अपनी विकास प्रक्रिया में एकीकृत करने के लिए पीवीएस-स्टूडियो स्टेटिक विश्लेषक का चयन करना चाहिए