बग शोधण्यासाठी ते वापरण्याऐवजी प्रक्रियेमध्ये स्थिर विश्लेषण लागू करा

मला हा लेख लिहिण्यास प्रवृत्त केले गेले की स्थिर विश्लेषणावरील मोठ्या प्रमाणात सामग्री माझ्या लक्षांत येत आहे. प्रथम, हे पीव्हीएस-स्टुडिओ ब्लॉग, जे मुक्त स्रोत प्रकल्पांमध्ये त्यांच्या साधनाद्वारे आढळलेल्या त्रुटींच्या पुनरावलोकनांच्या मदतीने Habré वर सक्रियपणे स्वतःचा प्रचार करते. अलीकडे PVS-studio लागू केले जावा समर्थन, आणि अर्थातच, IntelliJ IDEA चे विकसक, ज्यांचे अंगभूत विश्लेषक कदाचित आज जावासाठी सर्वात प्रगत आहेत, दूर राहू शकत नव्हते.

अशी पुनरावलोकने वाचताना, आपल्याला अशी भावना येते की आम्ही जादूच्या अमृताबद्दल बोलत आहोत: बटण दाबा आणि ती येथे आहे - आपल्या डोळ्यांसमोर दोषांची यादी. असे दिसते की विश्लेषक जसे सुधारत जातील तसतसे अधिकाधिक दोष आपोआप सापडतील आणि या यंत्रमानवांनी स्कॅन केलेली उत्पादने आमच्याकडून कोणतेही प्रयत्न न करता अधिक चांगली होत जातील.

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

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

जे स्थिर विश्लेषक कधीही करू शकत नाहीत

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

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

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

स्थिर विश्लेषण हे बग शोधत नाही

वरील वरून, निष्कर्ष खालीलप्रमाणे आहे: स्थिर विश्लेषण हे प्रोग्राममधील दोषांची संख्या कमी करण्याचे साधन नाही. मी हे सांगण्याचे धाडस करू इच्छितो: जेव्हा प्रथमच आपल्या प्रकल्पावर अर्ज केला जातो तेव्हा त्यास कोडमध्ये "रुचक" ठिकाणे सापडतील, परंतु, बहुधा, आपल्या प्रोग्रामच्या गुणवत्तेवर परिणाम करणारे कोणतेही दोष सापडणार नाहीत.

विश्लेषकांद्वारे आपोआप सापडलेल्या दोषांची उदाहरणे प्रभावी आहेत, परंतु आपण हे विसरू नये की ही उदाहरणे मोठ्या कोडबेसचा एक मोठा संच स्कॅन करून सापडली आहेत. त्याच तत्त्वानुसार, ज्या हॅकर्सना मोठ्या संख्येने खात्यांवर अनेक साधे पासवर्ड वापरून पाहण्याची संधी असते त्यांना शेवटी साधा पासवर्ड असलेली खाती सापडतात.

याचा अर्थ स्टॅटिक अॅनालिसिसचा वापर करू नये असा होतो का? नक्कीच नाही! आणि अगदी त्याच कारणास्तव प्रत्येक नवीन पासवर्ड "साध्या" पासवर्डच्या स्टॉप लिस्टमध्ये समाविष्ट आहे याची खात्री करण्यासाठी ते तपासणे योग्य आहे.

स्थिर विश्लेषण हे बग शोधण्यापेक्षा जास्त आहे

खरं तर, विश्लेषणाद्वारे व्यावहारिकरित्या सोडवलेल्या समस्या खूप विस्तृत आहेत. शेवटी, सर्वसाधारणपणे, स्टॅटिक अॅनालिसिस म्हणजे स्त्रोत कोड लॉन्च होण्यापूर्वी केलेले कोणतेही सत्यापन. तुम्ही करू शकता अशा काही गोष्टी येथे आहेत:

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

तुम्ही बघू शकता, या सूचीतील बग्स शोधणे ही सर्वात कमी महत्त्वाची भूमिका बजावते आणि बाकी सर्व काही विनामूल्य मुक्त स्रोत साधनांचा वापर करून उपलब्ध आहे.

यापैकी कोणत्या प्रकारचे स्थिर विश्लेषण तुम्ही तुमच्या प्रकल्पात वापरावे? अर्थात, अधिक, चांगले! मुख्य गोष्ट म्हणजे ते योग्यरित्या अंमलात आणणे, ज्याची पुढे चर्चा केली जाईल.

मल्टी-स्टेज फिल्टर म्हणून डिलिव्हरी पाइपलाइन आणि पहिला टप्पा म्हणून स्थिर विश्लेषण

सतत एकात्मतेसाठी उत्कृष्ट रूपक ही एक पाइपलाइन आहे ज्याद्वारे स्त्रोत कोड बदलण्यापासून ते उत्पादनापर्यंत वितरणापर्यंत प्रवाह बदलतो. या पाइपलाइनमधील टप्प्यांचा मानक क्रम असा दिसतो:

1. स्थिर विश्लेषण
2. कॉंपिलियास
3. युनिट चाचण्या
4. एकीकरण चाचण्या
5. UI चाचण्या
6. मॅन्युअल तपासणी

पाइपलाइनच्या Nव्या टप्प्यावर नाकारलेले बदल N+1 स्टेजमध्ये हस्तांतरित केले जात नाहीत.

नेमका हा मार्ग का आणि अन्यथा नाही? पाइपलाइनच्या चाचणी भागामध्ये, परीक्षक सुप्रसिद्ध चाचणी पिरॅमिड ओळखतील.

चाचणी पिरॅमिड. स्रोत: लेख मार्टिन फॉलर.

या पिरॅमिडच्या तळाशी अशा चाचण्या आहेत ज्या लिहायला सोप्या आहेत, चालवायला जलद आहेत आणि अयशस्वी होण्याची प्रवृत्ती नाही. म्हणून, त्यापैकी अधिक असले पाहिजेत, त्यांनी अधिक कोड कव्हर केले पाहिजे आणि प्रथम अंमलात आणले पाहिजे. पिरॅमिडच्या शीर्षस्थानी, उलट सत्य आहे, म्हणून एकत्रीकरण आणि UI चाचण्यांची संख्या आवश्यक किमान कमी केली पाहिजे. या साखळीतील व्यक्ती सर्वात महाग, संथ आणि अविश्वसनीय संसाधन आहे, म्हणून तो अगदी शेवटच्या टप्प्यावर आहे आणि मागील टप्प्यांमध्ये कोणतेही दोष आढळले नाहीत तरच तो कार्य करतो. तथापि, चाचणीशी थेट संबंधित नसलेल्या भागांमध्ये पाइपलाइन तयार करण्यासाठी समान तत्त्वे वापरली जातात!

मी मल्टी-स्टेज वॉटर फिल्ट्रेशन सिस्टमच्या रूपात एक समानता देऊ इच्छितो. घाणेरडे पाणी (दोषांसह बदल) इनपुटला पुरवले जाते; आउटपुटवर आम्हाला स्वच्छ पाणी मिळाले पाहिजे, ज्यामध्ये सर्व अवांछित दूषित घटक काढून टाकले गेले आहेत.

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

तुम्हाला माहिती आहेच, क्लिनिंग फिल्टर्स अशा प्रकारे डिझाइन केले आहेत की प्रत्येक पुढील कॅस्केड दूषित घटकांचा अधिकाधिक सूक्ष्म अंश फिल्टर करू शकेल. त्याच वेळी, खडबडीत शुद्धीकरणाच्या कॅस्केडमध्ये जास्त थ्रुपुट आणि कमी खर्च असतो. आमच्या सादृश्यतेनुसार, याचा अर्थ असा आहे की इनपुट गुणवत्तेचे गेट्स वेगवान आहेत, त्यांना प्रारंभ करण्यासाठी कमी प्रयत्नांची आवश्यकता आहे आणि ते ऑपरेशनमध्ये अधिक नम्र आहेत - आणि हा तो क्रम आहे ज्यामध्ये ते तयार केले जातात. स्थिर विश्लेषणाची भूमिका, जी आपल्याला आता समजते की, केवळ सर्वात मोठे दोष काढून टाकण्यास सक्षम आहे, ती फिल्टर कॅस्केडच्या अगदी सुरुवातीस "मड" ग्रिडची भूमिका आहे.

स्थिर विश्लेषण स्वतःच अंतिम उत्पादनाची गुणवत्ता सुधारत नाही, ज्याप्रमाणे “मड फिल्टर” पाणी पिण्यायोग्य बनवत नाही. आणि तरीही, पाइपलाइनच्या इतर घटकांच्या संयोगाने, त्याचे महत्त्व स्पष्ट आहे. जरी मल्टीस्टेज फिल्टरमध्ये आउटपुट टप्पे इनपुट स्टेजमध्ये जे काही करतात ते कॅप्चर करण्यास संभाव्यतः सक्षम असले तरी, इनपुट स्टेजशिवाय केवळ सूक्ष्म-शुद्धीकरण टप्प्यांसह करण्याचा प्रयत्न केल्याने काय परिणाम होतील हे स्पष्ट आहे.

"मड ट्रॅप" चा उद्देश त्यानंतरच्या कॅस्केड्सना अत्यंत गंभीर दोष पकडण्यापासून मुक्त करणे हा आहे. उदाहरणार्थ, कमीतकमी, कोड पुनरावलोकन करणारी व्यक्ती चुकीचे स्वरूपित कोड आणि स्थापित कोडिंग मानकांचे उल्लंघन (जसे की अतिरिक्त कंस किंवा खूप खोल नेस्टेड शाखा) द्वारे विचलित होऊ नये. NPEs सारखे बग युनिट चाचण्यांद्वारे पकडले जावे, परंतु जर चाचणीपूर्वीच विश्लेषक आम्हाला सूचित करत असेल की दोष उद्भवणार आहे, तर हे त्याचे निराकरण लक्षणीयरीत्या गती देईल.

मला विश्वास आहे की अधूनमधून वापरल्यास स्थिर विश्लेषण उत्पादनाची गुणवत्ता का सुधारत नाही हे आता स्पष्ट झाले आहे आणि स्थूल दोषांसह बदल फिल्टर करण्यासाठी सतत वापरले पाहिजे. स्टॅटिक अॅनालायझर वापरल्याने तुमच्या उत्पादनाची गुणवत्ता सुधारेल का हा प्रश्न साधारणपणे विचारण्यासारखा आहे, "अस्वच्छ तलावातून घेतलेले पाणी चाळणीतून गेल्यास पिण्याच्या गुणवत्तेत सुधारणा होईल का?"

वारसा प्रकल्पात अंमलबजावणी

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

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

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

दर्जेदार गेट्स सादर करण्याच्या खालील पद्धती ज्ञात आहेत:

• चेतावणींच्या एकूण संख्येवर मर्यादा सेट करणे किंवा कोडच्या ओळींच्या संख्येने भागिले चेतावणींची संख्या. हे खराबपणे कार्य करते, कारण असे गेट मुक्तपणे नवीन दोषांसह बदल करू देते, जोपर्यंत त्यांची मर्यादा ओलांडली जात नाही.
• एका विशिष्ट क्षणी, कोडमधील सर्व जुन्या इशारे दुर्लक्षित केल्याप्रमाणे दुरुस्त करणे आणि नवीन इशारे आल्यावर तयार करण्यास नकार देणे. ही कार्यक्षमता PVS-studio आणि काही ऑनलाइन संसाधनांद्वारे प्रदान केली जाते, उदाहरणार्थ, Codacy. मला पीव्हीएस-स्टुडिओमध्ये काम करण्याची संधी मिळाली नाही, कोडॅसीमधील माझ्या अनुभवाप्रमाणे, त्यांची मुख्य समस्या ही आहे की "जुने" काय आहे आणि "नवीन" त्रुटी काय आहे हे निश्चित करणे ही एक जटिल अल्गोरिदम आहे जी नेहमीच कार्य करत नाही. योग्यरित्या, विशेषत: जर फायली मोठ्या प्रमाणात सुधारित किंवा पुनर्नामित केल्या गेल्या असतील. माझ्या अनुभवानुसार, कोडेसी पुल विनंतीमधील नवीन इशाऱ्यांकडे दुर्लक्ष करू शकते, त्याच वेळी दिलेल्या 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. कुद्र्यवत्सेव: प्रोग्राम विश्लेषण: आपण चांगले प्रोग्रामर आहात हे कसे समजून घ्यावे कोड विश्लेषणाच्या विविध पद्धतींवर अहवाल द्या (फक्त स्थिर नाही!)

स्त्रोत: www.habr.com