जैसा कि पीवीएस-स्टूडियो में हम कई वर्षों से एक इंजीनियरिंग समस्या को हल कर रहे हैं

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



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

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

सबसे पहले हमने जो किया वह तुरंत डुप्लिकेट संदेशों को हटा दिया गया था। विश्लेषक C / C ++ प्रोजेक्ट्स की जाँच करता है और ऐसा होता है कि .h फ़ाइल में कोई त्रुटि तब जारी की जा सकती है जब कई .cpp फाइलें इसका उपयोग करती हैं। यह यहाँ नकल नहीं है। फिर हमने विश्लेषण परिणामों को फ़िल्टर करने की क्षमता को जोड़ा (और लगातार उन्हें बेहतर बनाया): त्रुटि कोड, संदेश पाठ, मुखौटा द्वारा फ़ाइलों को स्कैन न करने की क्षमता, आदि द्वारा फ़िल्टर करना। यह सब संदेशों की संख्या को काफी कम करने की अनुमति देता है, लेकिन केवल कॉन्फ़िगरेशन के बाद। पहली बार उपयोगकर्ता को अभी भी संदेशों का एक पहाड़ मिला है। इस प्रकार, संदेश फ़िल्टरिंग एक महत्वपूर्ण उपकरण है, लेकिन यह मूल समस्या को हल नहीं करता था - उपकरण को विकास प्रक्रिया में पेश करने की कठिनाई।

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

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

इसलिए हम आगे बढ़े और एक नया सुपर फीचर बनाया जिसका नाम है “Incremental Analysis after Build”। अब विश्लेषक संकलन के तुरंत बाद शुरू होता है और केवल उन फाइलों की जांच करता है जो उपयोगकर्ता संपादन द्वारा "प्रभावित" थीं। कुछ दिनों में फ़ाइलों की जाँच करने के विपरीत (जब विकास टीम के संपादन की जाँच की जा सकती है), अब उपयोगकर्ता कोड में केवल त्रुटियों को देखता है जिसे वह सीधे छूता है।

प्रोग्रामर को अब बड़ी मात्रा में कोड के बारे में चिंता नहीं होगी जिसे वह स्पर्श नहीं करता है। शायद यह कोड 5 साल से अधिक पुराना है। यह व्यावहारिक रूप से संशोधित नहीं है और इसमें अधिकांश दोष पहले से तय हो गए हैं। इस कोड को पहले जांचने के लिए जल्दी नहीं करना पड़ता है और विश्लेषक ऐसा नहीं करता है। प्रोग्रामर केवल नवीनतम कोड में चेतावनी देखेंगे। और अगर उसके पास अतिरिक्त समय है, तो वह हमेशा पूरी परियोजना की जांच करने में सक्षम होगा, सबसे अधिक बार देखी जाने वाली जगहों पर।

हां, विश्लेषक के पास अभी भी झूठी सकारात्मकताएं हैं। हां, सभी समान, फिल्टर ने अपनी प्रासंगिकता नहीं खोई है। लेकिन एक और महत्वपूर्ण बात। हम एक स्थिर विश्लेषक के परिचय की लागत (कमीशन के लिए मानव प्रयासों की लागत) को कम करने में कामयाब रहे। यही है, अब एक व्यक्ति एक स्थिर विश्लेषक डाउनलोड करता है, इसे स्थापित करता है, और IMMEDIATELY इसे बिना किसी अतिरिक्त कार्यों के लाभ शुरू करता है।

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

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

इस प्रकार, विकास प्रक्रिया में स्थैतिक विश्लेषण शुरू करने का इंजीनियरिंग कार्य हल किया गया था। इसलिए, PVS-Studio 4.34 में, बिल्ड मोड के बाद इंक्रीमेंटल एनालिसिस डिफ़ॉल्ट रूप से सक्षम हो जाएगा।

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