🚟 📛 🎋 प्रक्रिया में स्थैतिक विश्लेषण का परिचय दें, इसके साथ कीड़े के लिए बस खोज न करें 🌇 📬 🚶🏼

यह लेख मूल पद का अधिकृत अनुवाद है। अनुवाद को PVS-Studio के लोगों की मदद से बनाया गया था। धन्यवाद दोस्तों!

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

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

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

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

स्टेटिक एनालिसिस करने वाले कभी भी समर्थ नहीं होंगे

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

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

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

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

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

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

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

स्थैतिक विश्लेषण कीड़े के लिए और अधिक खोज है

वास्तव में, व्यवहार में विश्लेषण द्वारा हल किए जा सकने वाले कार्य बहुत व्यापक हैं। क्योंकि आम तौर पर बोलते हुए, स्थैतिक विश्लेषण स्रोत कोड के किसी भी चेक का प्रतिनिधित्व करता है, इसे चलाने से पहले किया जाता है। यहाँ कुछ चीजें हैं जो आप कर सकते हैं:

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

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

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

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

परिवर्तनों के प्रवाह के साथ एक पाइपलाइन (उत्पादन में वितरण के लिए स्रोत कोड के परिवर्तन से शुरू) निरंतर एकीकरण का एक क्लासिक रूपक है। इस पाइपलाइन के चरणों का मानक अनुक्रम निम्नानुसार है:

स्थैतिक विश्लेषण
संकलन
इकाई परीक्षण
एकीकरण परीक्षण
यूआई परीक्षण
मैनुअल सत्यापन

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

ऐसा क्यों और नहीं तो क्या? पाइपलाइन के हिस्से में, जो परीक्षण से संबंधित है, परीक्षक अच्छी तरह से ज्ञात परीक्षण पिरामिड को पहचानते हैं:

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

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

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

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

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

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

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

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

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

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

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

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

यहाँ गुणवत्ता द्वार परिचय के ज्ञात तरीके हैं:

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

शाफ़्ट

यह निम्नलिखित तरीके से काम करता है:

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

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

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

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

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

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

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

निष्कर्ष

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

संदर्भ

निरंतर वितरण
एलेक्सी कुद्र्यावत्सेव: कार्यक्रम विश्लेषण: क्या आप एक अच्छे डेवलपर हैं? कोड के विभिन्न विश्लेषण विधियों पर रिपोर्ट करें, न केवल स्थिर!

मूल लेख की चर्चा के कुछ अंश

एवगेनी रेज़्कोव

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

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

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

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

यह संक्षिप्त लेख "स्थिर कोड विश्लेषण के दर्शन" के बारे में है, जो विभिन्न कंपनियों का दौरा करते समय मेरा विषय है।

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

यहाँ कोई भी दोषी नहीं है, क्योंकि विश्लेषणकर्ताओं पर लेखों / रिपोर्टों के लेखकों का लक्ष्य विश्लेषण पर लेख / रिपोर्ट बनाना नहीं है। लेकिन Andrey2008 और lany द्वारा हाल के कुछ पदों के बाद, मैंने फैसला किया कि मैं किसी भी अधिक चुप नहीं रह सकता।

एवगेनी रेज़्कोव
इवान, जैसा कि ऊपर लिखा गया है, मैं लेख के तीन बिंदुओं पर टिप्पणी करूंगा। इसका मतलब है कि मैं इससे सहमत हूं, कि मैं कोई टिप्पणी नहीं करता।

1. इस पाइपलाइन के चरणों का मानक अनुक्रम निम्नानुसार दिखता है ...

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

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

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

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

3. जिस भी तरीके से आप अपनी डिलीवरी पाइपलाइन विश्लेषण का परिचय देते हैं, उसका विश्लेषण संस्करण निश्चित होना चाहिए

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

एनालाइजर को अपडेट न करना एंटी-वायरस डेटाबेस ("क्या होगा अगर वे वायरस के बारे में सूचित करना शुरू कर दें") को अपडेट नहीं करते हैं। हम यहां संपूर्ण रूप से एंटीवायरस सॉफ़्टवेयर की सही उपयोगिता के बारे में चर्चा नहीं करेंगे।

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

इवान पिंडोमेरेव

1. यहाँ आप सही हैं। मैं शुरुआत में एक कंपाइलर / पार्सर के साथ सहमत होने के लिए तैयार हूं और इसे लेख में भी बदला जाना चाहिए! उदाहरण के लिए, कुख्यात spotbugs बिल्कुल अलग तरीके से कार्य करने में सक्षम नहीं हैं, क्योंकि यह संकलित spotbugs का विश्लेषण करता है। विदेशी मामले हैं, उदाहरण के लिए, Ansible playbooks के लिए पाइपलाइन में, स्थैतिक विश्लेषण को पार्स करने से पहले सेट करना बेहतर है क्योंकि यह हल्का है। लेकिन यह खुद विदेशी है)

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

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

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

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

मेरी राय है कि इस मामले में निर्माण को विफल करना बुरा है। समस्या कोड के लेखकों को संदेश भेजना अच्छा है।

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

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

"जल्दी" विषय पर मेरी पसंदीदा प्रतिबद्धता।

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

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

एवगेनी रेज़्कोव
मैं समझता हूं कि "इसे सिद्धांत रूप में कैसे किया जाना चाहिए"। लेकिन मुझे ग्राहकों द्वारा केवल दो विकल्प दिखाई देते हैं। या तो नए या पुराने से चिपके रहते हैं। इसलिए हम ALMOST के पास ऐसी परिस्थितियां नहीं हैं जब "हमारे पास अनुशासन है और हम दो संस्करणों पर वर्तमान संस्करण से पीछे हैं"। मेरे लिए यह कहना महत्वपूर्ण नहीं है कि अभी यह अच्छा है या बुरा है। मैं वही कहता हूं जो मैं देखता हूं।

इवान पिंडोमेरेव
मैं समझ गया। वैसे भी, यह सब दृढ़ता से इस बात पर निर्भर करता है कि आपके ग्राहकों के पास कौन से उपकरण / प्रक्रियाएं हैं और वे उनका उपयोग कैसे करते हैं। उदाहरण के लिए, मुझे इस बारे में कुछ नहीं पता है कि यह सब C ++ दुनिया में कैसे काम करता है।

प्रक्रिया में स्थैतिक विश्लेषण का परिचय दें, इसके साथ कीड़े के लिए बस खोज न करें