आपत्तियों के साथ काम करें: स्थैतिक विश्लेषण कार्य समय का हिस्सा होगा

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

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

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

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

फिर भी, स्टेटिक कोड एनालिसिस करने वालों को समय बिताने की जरूरत का डर कहां से आता है?

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

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

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

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

हाँ, झूठे अलार्म ट्यूनिंग के बाद मौजूद होंगे। लेकिन उनकी संख्या अतिरंजित है। विश्लेषक को कॉन्फ़िगर करना काफी संभव है ताकि झूठी सकारात्मकता का प्रतिशत 10% -15% हो। यानी 9 दोषों के लिए, केवल 1 चेतावनी को झूठ के रूप में दमन की आवश्यकता होगी। तो यहाँ "समय की बर्बादी" कहाँ है? इसी समय, 15% एक बहुत ही वास्तविक मूल्य है, जिसे इस लेख में अधिक विस्तार से पाया जा सकता है।

एक और बात बनी हुई है। प्रोग्रामर को आपत्ति हो सकती है:

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

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

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

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

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

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

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

टिप्पणी

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

अतिरिक्त लिंक:

1. पीवीएस-स्टूडियो आरओआई ।
2. स्थैतिक विश्लेषण जटिल सी ++ परियोजनाओं के कोड आधार में सुधार करेगा ।
3. हाइजेनबग 2019. इवान पोनोमारेव की रिपोर्ट " कंटीन्यूअस स्टैटिक कोड एनालिसिस "।
4. इवान पिंडोमेरेव। प्रक्रिया में स्थैतिक विश्लेषण एम्बेड करें, इसके साथ बग की तलाश न करें ।

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