स्वचालित जावा कोड गुणवत्ता जांच (पुनरावृत्ति 1)

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

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

इस पुनरावृत्ति में, मैं निरीक्षण जांच को कॉन्फ़िगर करूंगा। हम JetBrains से एक टीम के रूप में IntelliJ IDEA और TeamCity का उपयोग करते हैं, इसलिए आप उन उपकरणों का उपयोग कर सकते हैं जो वे प्रदान करते हैं। शुरू करने के लिए, IntelliJ IDEA एक निरीक्षण प्रोफ़ाइल स्थापित करेगा, जिसमें कोड अनुपालन का पालन किया जाएगा, जो कि TeamCity का उपयोग करके प्रत्येक विधानसभा के दौरान जाँच की जाएगी। यह एक नियमित विधि है और टीमकिट पर आधिकारिक ज्ञान के आधार में वर्णित है , लेकिन सब कुछ बहुत आसानी से नहीं निकला ...

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



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

उपयोगी उल्लेखनीय निरीक्षण से:

• I / O संसाधन खोला गया, लेकिन सुरक्षित रूप से बंद नहीं - आपको यह जांचने की अनुमति देता है कि बंद सभी खुले संसाधनों और, इसके अलावा, सही जगह (JDBC, JNDI और nio के समान) के लिए कहा जाता है;
• मिसिंग ओवरराइड एनोटेशन - मैंने एक त्रुटि के रूप में व्यवहार किए जाने के लिए एक कठिन निर्णय लिया, क्योंकि यह इन बहुत त्रुटियों से भरा हुआ है (यह कुछ भी नहीं है कि स्काला इस तरह की घोषणा के लिए आवश्यक कीवर्ड का उपयोग करता है);
• 'KeySet ()' से अधिक परिवर्तन को 'entrySet ()' पुनरावृत्ति से बदला जा सकता है - अजीब तरह से, कुछ सोचते हैं कि दूसरा तरीका तेज है और यहां तक ​​कि मौजूद है;
• 'इंस्टोफ़' चेक की श्रृंखला - आपको दुर्भावनापूर्ण एलएसपी उल्लंघनकर्ताओं को संकेत देने की अनुमति देता है कि आप अलग तरीके से रह सकते हैं;
• अत्यधिक लंबी विधि , बहुत अधिक विधियों वाली कक्षा - आपको यह निगरानी करने की अनुमति देती है कि विधियाँ और कक्षाएं समय में टूट जाती हैं और उचित संख्या में स्क्रीन पर रखी जाती हैं।

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

आप सहेजे गए प्रोफ़ाइल को आयात विकल्प के माध्यम से टीम के अन्य सदस्यों को आयात कर सकते हैं ताकि चेक पूरी टीम के लिए उसी तरह काम करें। सच है, हर बार जब आप प्रोफ़ाइल बदलते हैं, तो टीम को फिर से आयात करना होगा, क्योंकि निर्यात की गई फ़ाइल में परिवर्तन स्वचालित रूप से ट्रैक नहीं किया जाता है।

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



हमारे पास मावेन परियोजना है , और यह मेरे लिए एक आश्चर्य की बात थी: "निर्दिष्ट पथ चेकआउट निर्देशिका के सापेक्ष होना चाहिए। प्रोजेक्ट फ़ाइल (.ipr) या डायरेक्टरी-बेस्ड (.idea) प्रोजेक्ट्स के लिए प्रोजेक्ट डायरेक्टरी का संदर्भ देना चाहिए। ", इस विषय पर प्रलेखन में लाभ स्पष्ट है:" Maven2 प्रोजेक्ट के लिए: pom के लिए पथ। xml फ़ाइल। " हम स्वयं मल्टी - मॉड्यूल मावेन प्रोजेक्ट के मॉड्यूल ( टिंकॉफ-पोर्टल-वेब ) में से एक को इकट्ठा करते हैं, इसलिए हम इसमें pom फ़ाइल का पथ इंगित करते हैं। क्रमशः कार्यशील निर्देशिका को भी ठीक करने की आवश्यकता है।

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

-Xmx512m -XX:MaxPermSize=150m 

उसी क्षेत्र में, आप टीम पैकेज की जांच कर सकते हैं या कुछ विशेष पैकेजों की जांच नहीं कर सकते हैं , उदाहरण के लिए, यह देखना बहुत दिलचस्प नहीं है कि वेब सेवाओं के साथ काम करने के लिए उत्पन्न होने वाले स्टब्स के लिए क्या दावे हैं, इसलिए हम केवल उन कक्षाओं को देखते हैं जो हमने खुद को लिखा था (मेलेन के लिए, कैसे यह देखा जा सकता है कि पथ की जाँच की जा रही मॉड्यूल की जड़ के सापेक्ष है):

 -Didea.include.patterns=src/main/java/ru/tcsbank/portal/* 

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

 %system.teamcity.build.checkoutDir%/tcsInspectionsProfile.xml 

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

इसलिए, हम अपनी विधानसभा शुरू करते हैं और हम कुछ ऐसा देखते हैं:

खैर, अब हम हमेशा यह जानते हैं कि क्या कमिट ने कोड की गुणवत्ता में सुधार किया है या बिगड़ गया है।

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

निरीक्षण के बाद के चयन को पिज़्ज़ा-प्रेरित-विकास पद्धति का उपयोग करके टीम के साथ मिलकर किया जा सकता है :)

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