आपत्ति से निपटने: स्थैतिक विश्लेषण कार्य समय का हिस्सा ले जाएगा

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

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

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

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

हालाँकि, स्थिर कोड विश्लेषणकर्ताओं की चेतावनी के लिए समय बर्बाद करने का डर कहाँ से आता है?

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

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

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

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

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

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

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

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

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

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

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

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

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

टिप्पणी

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

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

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