प्रक्रिया में स्थैतिक विश्लेषण एम्बेड करें, इसके साथ बग की तलाश न करें

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

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

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


शाफ़्ट (स्रोत: विकिपीडिया )।

स्थैतिक विश्लेषक क्या कभी नहीं कर सकते

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

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

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

स्थैतिक विश्लेषण बग खोज नहीं है

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

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

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

स्थैतिक खोज बग खोज की तुलना में अधिक है

वास्तव में, विश्लेषण द्वारा व्यावहारिक रूप से हल किए गए कार्य बहुत व्यापक हैं। वास्तव में, सामान्य रूप से, स्थैतिक विश्लेषण, लॉन्च होने से पहले किए गए स्रोतों का कोई सत्यापन होता है। यहाँ कुछ चीजें हैं जो आप कर सकते हैं:

• शब्द के व्यापक अर्थ में कोडिंग शैली का सत्यापन। इसमें फ़ॉर्मेटिंग की जाँच करना, और खाली / अतिरिक्त ब्रैकेट के उपयोग की खोज करना, मैट्रिक्स की थ्रेशोल्ड वैल्यू सेट करना, जैसे कि लाइनों की संख्या / विधि की साइक्लोमैटिक जटिलता, आदि - यह सब संभावित रूप से कोड को पढ़ना और बनाए रखना मुश्किल बना देता है। जावा में ऐसा उपकरण चेकस्टाइल है, पायथन में - फ्लेक 8। इस वर्ग के कार्यक्रमों को आमतौर पर लिंटर कहा जाता है।
• न केवल निष्पादन योग्य कोड का विश्लेषण किया जा सकता है। JSON, YAML, XML, .properties (और चाहिए!) जैसी संसाधन फ़ाइलें वैधता के लिए स्वचालित रूप से जाँच की जा सकती हैं। आखिरकार, यह पता लगाना बेहतर है कि कुछ अनपेक्षित उद्धरणों के कारण, JSON संरचना का परीक्षण या निष्पादन के समय स्वचालित पुल अनुरोध जाँच के प्रारंभिक चरण में उल्लंघन किया जाता है? प्रासंगिक उपकरण उपलब्ध हैं: उदाहरण के लिए, YAMLlint , JSONLint ।
• संकलन (या गतिशील प्रोग्रामिंग भाषाओं के लिए पार्सिंग) भी स्थैतिक विश्लेषण का एक रूप है। एक नियम के रूप में, संकलक स्रोत कोड की गुणवत्ता के साथ चेतावनी संकेत समस्याएं जारी करने में सक्षम हैं, और उन्हें अनदेखा नहीं किया जाना चाहिए।
• कभी-कभी संकलन केवल निष्पादन योग्य कोड का संकलन नहीं है। उदाहरण के लिए, यदि आपके पास AsciiDoctor प्रारूप में प्रलेखन है, तो इसे HTML / PDF में परिवर्तित करने के समय, AsciiDoctor ( Maven plugin ) हैंडलर चेतावनी दे सकता है, उदाहरण के लिए, टूटे हुए आंतरिक लिंक के बारे में। और यह एक अच्छा कारण है कि दस्तावेज़ में परिवर्तन के साथ पुल अनुरोध को स्वीकार नहीं करना है।
• Spellchecking भी स्थैतिक विश्लेषण का एक रूप है। Aspell यूटिलिटी न केवल प्रलेखन में, बल्कि C / C ++, जावा और पायथन सहित विभिन्न प्रोग्रामिंग भाषाओं में कार्यक्रमों (टिप्पणियों और शाब्दिक) के स्रोत कोड में भी जांच करने में सक्षम है। उपयोगकर्ता इंटरफ़ेस या प्रलेखन में एक वर्तनी त्रुटि भी एक दोष है!
• कॉन्फ़िगरेशन परीक्षण (यह क्या है - यह देखें और यह रिपोर्ट करें), हालांकि वे यूनिट टेस्ट के लिए एक रनटाइम वातावरण में चलाए जाते हैं जैसे कि पाइस्टेस्ट, वास्तव में एक प्रकार का स्थैतिक विश्लेषण भी है, क्योंकि वे निष्पादन के दौरान स्रोत कोड निष्पादित नहीं करते हैं ।

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

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

बहु-चरण फिल्टर के रूप में वितरण पाइपलाइन और इसके पहले कैस्केड के रूप में स्थैतिक विश्लेषण

निरंतर एकीकरण के लिए क्लासिक रूपक वह पाइपलाइन है जिसके माध्यम से परिवर्तन होता है - स्रोत कोड को बदलने से लेकर उत्पादन तक पहुंचाने तक। इस पाइपलाइन में चरणों का मानक अनुक्रम निम्नानुसार है:

1. स्थैतिक विश्लेषण
2. संकलन
3. इकाई परीक्षण
4. एकीकरण परीक्षण
5. यूआई परीक्षण
6. मैनुअल जांच

कन्वेयर के Nth चरण में खारिज किए गए परिवर्तन स्टेज N + 1 में स्थानांतरित नहीं होते हैं।

ऐसा क्यों, और अन्यथा नहीं? पाइपलाइन के परीक्षण भाग में, परीक्षकों ने प्रसिद्ध परीक्षण पिरामिड को पहचाना।


परीक्षण पिरामिड। स्रोत: मार्टिन फाउलर का लेख

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

मैं एक बहु-मंच जल निस्पंदन प्रणाली के रूप में एक सादृश्य की पेशकश करना चाहता हूं। गंदे पानी को प्रवेश द्वार (दोषों के साथ परिवर्तन) की आपूर्ति की जाती है, बाहर निकलने पर हमें साफ पानी मिलना चाहिए, जिसमें सभी अवांछनीय प्रदूषण समाप्त हो जाते हैं।


मल्टीस्टेज फिल्टर। स्रोत: विकिमीडिया कॉमन्स

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

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

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

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

एक विरासत परियोजना में कार्यान्वयन

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

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

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

गुणवत्ता द्वार के प्रबंधन के निम्नलिखित तरीके ज्ञात हैं:

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

शाफ़्ट

यह इस तरह से काम करता है:

1. प्रारंभिक चरण में, विश्लेषक द्वारा पाए गए कोड में चेतावनी की संख्या को रिलीज के बारे में मेटाडेटा में दर्ज किया गया है। इस प्रकार, मुख्य शाखा का निर्माण करते समय, न केवल "रिलीज़ 7.0.2", बल्कि "रिलीज़ 7.0.2, जिसमें 100500 चेकस्टाइल चेतावनी शामिल हैं" आपके भंडार प्रबंधक को लिखा जाता है। यदि आप एक उन्नत रिपॉजिटरी प्रबंधक (जैसे आर्टिफ़ैक्टिव) का उपयोग करते हैं, तो आपकी रिहाई के बारे में ऐसे मेटाडेटा को सहेजना आसान है।
2. अब, असेंबली के दौरान प्रत्येक पुल अनुरोध वर्तमान रिलीज़ में संख्या के साथ प्राप्त चेतावनियों की संख्या की तुलना करता है। यदि पीआर इस संख्या में वृद्धि की ओर जाता है, तो कोड स्थिर विश्लेषण के लिए गुणवत्ता गेट पास नहीं करता है। यदि चेतावनियों की संख्या कम हो जाती है या नहीं बदलती है, तो यह गुजरता है।
3. अगली रिलीज पर, चेतावनी की गणना संख्या को रिलीज़ मेटाडेटा पर फिर से लिखा जाएगा।

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

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



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

celesta-sql: checkstyle: 434 spotbugs: 45 celesta-core: checkstyle: 206 spotbugs: 13 celesta-maven-plugin: checkstyle: 19 spotbugs: 0 celesta-unit: checkstyle: 0 spotbugs: 0 

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

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

विश्लेषक संस्करण को ठीक करने के महत्व के बारे में

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

निष्कर्ष

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

संदर्भ

1. निरंतर वितरण
2. ए। कुद्रीवत्सेव: कार्यक्रमों का विश्लेषण: कैसे समझें कि आप कोड विश्लेषण के विभिन्न तरीकों पर एक अच्छी प्रोग्रामर रिपोर्ट हैं (न केवल स्थिर!)