बग ढूंढने के लिए इसका उपयोग करने के बजाय, प्रक्रिया में स्थैतिक विश्लेषण लागू करें

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

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

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

रैचेट (स्रोत: विकिपीडिया).

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

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

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

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

स्थैतिक विश्लेषण बग ढूंढने के बारे में नहीं है

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

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

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

स्थैतिक विश्लेषण बग ढूंढने से कहीं अधिक है

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

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

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

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

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

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

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

पाइपलाइन के Nवें चरण में अस्वीकृत परिवर्तन चरण N+1 में स्थानांतरित नहीं किए जाते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

गुणवत्ता वाले गेट शुरू करने की निम्नलिखित विधियाँ ज्ञात हैं:

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

शाफ़्ट

यह इस प्रकार काम करता है:

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() सामान्य तरीके से चेकस्टाइल और स्पॉटबग्स द्वारा उत्पन्न फ़ाइलों में xml टैग की गणना करता है, और compareWarningMaps() किसी भी श्रेणी में चेतावनियों की संख्या बढ़ने पर त्रुटि उत्पन्न करते हुए, उसी रैचेट को लागू करता है।

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

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

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

निष्कर्ष

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

संदर्भों

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

स्रोत: www.habr.com