यसमा बगहरू खोज्नुको सट्टा प्रक्रियामा स्थिर विश्लेषण लागू गर्नुहोस्

मलाई यो लेख लेख्न प्रेरित गरिएको थियो स्थिर विश्लेषणमा धेरै संख्यामा सामग्रीहरू जुन बढ्दो रूपमा आउँदैछ। पहिलो, यो PVS-studio ब्लग, जसले सक्रिय रूपमा Habré मा उनीहरूको उपकरणद्वारा खुला स्रोत परियोजनाहरूमा फेला परेका त्रुटिहरूको समीक्षाको साथ प्रचार गर्दछ। PVS-studio भर्खरै लागू गरियो जाभा समर्थन, र, निस्सन्देह, IntelliJ IDEA का विकासकर्ताहरू, जसको बिल्ट-इन विश्लेषक सम्भवतः आज जाभाको लागि सबैभन्दा उन्नत छ, टाढा रहन सकेन.

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

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

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

स्थिर विश्लेषकहरूले के गर्न सक्दैनन्

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

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

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

स्थिर विश्लेषण बगहरूको खोजी होइन

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

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

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

स्थिर विश्लेषण बगहरू फेला पार्न भन्दा बढी छ

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

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

तपाईंले देख्न सक्नुहुने रूपमा, यस सूचीमा बगहरू फेला पार्नुले कम्तिमा महत्त्वपूर्ण भूमिका लिन्छ, र अरू सबै कुरा नि: शुल्क खुला स्रोत उपकरणहरूको प्रयोग मार्फत उपलब्ध छ।

तपाईंको परियोजनामा ​​यी मध्ये कुन प्रकारको स्थिर विश्लेषण प्रयोग गर्नुपर्छ? निस्सन्देह, अधिक, राम्रो! मुख्य कुरा यसलाई सही रूपमा लागू गर्न हो, जुन थप छलफल गरिनेछ।

डिलिवरी पाइपलाइन बहु-चरण फिल्टरको रूपमा र यसको पहिलो क्यास्केडको रूपमा स्थिर विश्लेषण

निरन्तर एकीकरणको लागि क्लासिक रूपक पाइपलाइन (पाइपलाइन) हो जसको माध्यमबाट प्रवाह परिवर्तन हुन्छ - स्रोत कोड परिवर्तन गर्नदेखि उत्पादनमा डेलिभरीसम्म। यस पाइपलाइनको चरणहरूको मानक अनुक्रम यस्तो देखिन्छ:

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

पाइपलाइनको Nth चरणमा अस्वीकार गरिएका परिवर्तनहरू N+1 चरणमा प्रचार गरिएको छैन।

वास्तवमा किन यसरी र अन्यथा होइन? पाइपलाइनको परीक्षण भागमा, परीक्षकहरूले प्रख्यात परीक्षण पिरामिड पहिचान गर्नेछन्।

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

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

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

बहु-चरण फिल्टर। मुहान: विकिमिडियामा

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

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

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

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

विरासत परियोजनामा ​​कार्यान्वयन

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

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

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

गुणस्तर गेटहरू परिचय गर्ने निम्न तरिकाहरू ज्ञात छन्:

• चेतावनीहरूको कुल संख्यामा सीमा सेट गर्दछ, वा चेतावनीहरूको संख्यालाई कोडको लाइनहरूको संख्याले विभाजित गर्दछ। यसले राम्रोसँग काम गर्दैन, किनभने यस्तो गेटले स्वतन्त्र रूपमा नयाँ दोषहरूसँग परिवर्तनहरू छोड्छ जबसम्म तिनीहरूको सीमा नाघेको छ।
• फिक्स गर्दै, केहि बिन्दुमा, कोडमा भएका सबै पुराना चेतावनीहरूलाई बेवास्ता गरिँदै, र नयाँ चेतावनीहरू देखा पर्दा निर्माण असफल। यो कार्यक्षमता PVS-studio र केही अनलाइन स्रोतहरू, जस्तै Codacy द्वारा प्रदान गरिएको हो। मैले PVS-studio मा काम गर्ने मौका पाएन, कोडेसीको साथ मेरो अनुभवको लागि, तिनीहरूको मुख्य समस्या भनेको "पुरानो" के हो र "नयाँ" त्रुटि के हो भन्ने परिभाषा भनेको एक जटिल एल्गोरिथ्म हो जुन गर्दैन। सधैं सही रूपमा काम गर्नुहोस्, विशेष गरी यदि फाइलहरू भारी परिमार्जन वा पुन: नामाकरण गरिएका छन्। मेरो मेमोरीमा, कोडेसीले पुल अनुरोधमा नयाँ चेतावनीहरू छोड्न सक्छ, र एकै समयमा यो PR को कोडमा परिवर्तनहरूसँग सम्बन्धित नभएका चेतावनीहरूको कारणले पुल अनुरोध छोड्न सक्दैन।
• मेरो विचारमा, सबैभन्दा प्रभावकारी समाधान पुस्तकमा वर्णन गरिएको छ लगातार वितरण "रैचेटिंग" विधि। मुख्य विचार यो हो कि प्रत्येक रिलीजको गुण स्थिर विश्लेषण चेतावनीहरूको संख्या हो, र चेतावनीहरूको कुल संख्या नबढाउने परिवर्तनहरूलाई मात्र अनुमति दिइन्छ।

र्याचेट

यो यस्तो काम गर्छ:

1. प्रारम्भिक चरणमा, विश्लेषकहरू द्वारा फेला परेको कोडमा चेतावनीहरूको संख्याको रिलीज मेटाडेटामा रेकर्ड लागू गरिएको छ। यसरी, जब तपाइँ अपस्ट्रीम बनाउनुहुन्छ, तपाइँको भण्डार प्रबन्धक "रिलिज 7.0.2" मात्र लेखिएको छैन, तर "7.0.2 चेकस्टाइल चेतावनीहरू समावेश भएको 100500 जारी गर्नुहोस्"। यदि तपाइँ उन्नत रिपोजिटरी प्रबन्धक प्रयोग गर्दै हुनुहुन्छ (जस्तै आर्टिफ्याक्ट्री), तपाइँको रिलीजको बारेमा यस्तो मेटाडेटा भण्डारण गर्न सजिलो छ।
2. अब निर्माणमा प्रत्येक पुल अनुरोधले हालको विमोचनमा प्राप्त हुने चेतावनीहरूको संख्यासँग तुलना गर्दछ। यदि PR ले यो संख्यामा वृद्धि हुन्छ भने, कोडले स्थिर विश्लेषणमा गुणस्तर गेट पार गर्दैन। यदि चेतावनीहरूको संख्या घट्छ वा परिवर्तन हुँदैन, तब यो पारित हुन्छ।
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

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

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

विश्लेषक संस्करण फिक्सिङ को महत्व को बारे मा

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

निष्कर्ष

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

सन्दर्भ

1. लगातार वितरण
2. A. Kudryavtsev: कार्यक्रम विश्लेषण: कसरी बुझ्ने कि तपाईं एक राम्रो प्रोग्रामर हुनुहुन्छ कोड विश्लेषणका विभिन्न विधिहरूमा रिपोर्ट गर्नुहोस् (स्थिर मात्र होइन!)

स्रोत: www.habr.com