मीट क्रिटिक: ओपेरा सॉफ्टवेयर में कोड निरीक्षण प्रणाली

ओपेरा सॉफ्टवेयर द्वारा उपयोग किए जाने वाले आंतरिक समालोचक स्रोत कोड निरीक्षण प्रणाली को कल रात अपाचे लाइसेंस 2.0 के तहत जीथब पर अपलोड किया गया था।

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

यहाँ समालोचक स्रोत कोड डाउनलोड करें: github.com/jensl/critic

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

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

आलोचना एक वेब एप्लिकेशन है और इसे पायथन में लिखा गया है। समालोचना कसकर Git के साथ एकीकृत है। जैसे ही आप Git रिपॉजिटरी में देख रहे हैं क्रिटिक देख रहा है, जैसे ही आपके कमिट्स को रिव्यू में जोड़ा जाएगा।

निरीक्षण चक्र इस प्रकार है:

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

कुछ नोट:

1. समस्या रिकॉर्ड संपूर्ण समीक्षा, एक कमिट या कोड की विशिष्ट लाइनों को संदर्भित कर सकता है। कोड की ये पंक्तियाँ कमिट का हिस्सा नहीं हो सकती हैं, अर्थात उदाहरण के लिए, "अछूता" कोड का हिस्सा हो सकता है, जब एक प्रतिबद्ध अछूता कोड के व्यवहार को बदलता है। यदि कोई समस्या रिकॉर्ड कोड की कुछ पंक्तियों को संदर्भित करती है और ये पंक्तियाँ अगली प्रतिबद्ध में तय की जाती हैं, तो इस समस्या को इस पते द्वारा "संबोधित" के रूप में चिह्नित किया जाता है। हालाँकि, नई कमिट को बिना लाइसेंस के चिह्नित किया जाता है, ताकि सभी समीक्षा स्वचालित रूप से अनुमोदित न हो सकें। यह उन विशेषताओं में से एक है जो सिस्टम के साथ काम करते समय समय बचाता है।
   
2. आलोचक "पुनर्लेखन इतिहास" का समर्थन करता है। यह डरावना लगता है, लेकिन यह उपयोगी है, खासकर जब "पुनर्लेखन" जीआईटी रिबेस -आई के माध्यम से एक समानांतर गिट शाखा पर होता है। उदाहरण के लिए, यदि आपकी समीक्षा 50 हो गई है, और इनमें से कई कमिट हैं - मामूली बग फिक्स, संकलन फिक्स, नाम बदलने वाले चर, संपादन टिप्पणियां और अन्य "क्लीनअप" जैसी छोटी चीजें - यह वीसीएस में आपके इतिहास को तोड़ देगा। ऐसे मामलों में, यह उन सभी मध्यवर्ती सुधारों को "छड़ी" करने के लिए उपयोगी हो सकता है जो मुख्य परियोजना कोड में एकीकरण के लिए अपनी शाखा देने से पहले ठीक करते हैं। इस प्रकार, परियोजना की मुख्य शाखा में हमेशा एक सुंदर कहानी होगी, न कि गड़बड़। खैर, या लगभग हमेशा। इसलिए, यदि आपने ऐसा ऑपरेशन किया है और 50 "खराब" 5 "अच्छे" वाले हैं, तो एक ही सामग्री के साथ - आलोचक आपको दूसरी बार इस कोड का निरीक्षण करने के लिए नहीं कहेगा। हर चीज को वर्कआउट करने के लिए, 50 "खराब" कमिट्स का कुल अंतर 5 "अच्छे" कमिट्स के कुल फॉर्म के समान 100% होना चाहिए। पुन: लिखित कहानी समीक्षा में प्रकाशित होगी।
   
3. आलोचना भी शाखा समीक्षा बिंदुओं को बदलने का समर्थन करती है। मान लीजिए कि आप परियोजना की मुख्य शाखा के शीर्ष से समीक्षा शाखा को शाखा देते हैं। निरीक्षण के दौरान, परियोजना की मुख्य शाखा आगे बढ़ी। और आपकी शाखा को मुख्य शाखा की नई वास्तविकताओं के अनुसार कोड को बदलना होगा। क्या करें, एक नई समीक्षा बनाएं और इस समीक्षा पर पहले से किए गए सभी काम खो दें? कोई फर्क नहीं पड़ता कि कैसे। आलोचक यहाँ आपकी सहायता करेगा। सभी कमिटों को एक ही गिट रिबास का उपयोग करके एक नए शाखा बिंदु पर कॉपी किया जा सकता है, और आलोचक को बताएं कि वास्तव में आपने शाखा बिंदु कहां स्थानांतरित किया है। और वह सब कुछ समझ जाएगा! और वह दूसरी बार उसी कोड का निरीक्षण करने के लिए नहीं कहेगा। और वह आपको मुख्य शाखा से टन के कोड का निरीक्षण करने के लिए नहीं कहेगा। लेकिन वह ध्यान देगा कि आपने मर्ज संघर्षों को हल कर लिया है, और निरीक्षकों से यह जांचने के लिए कहेंगे कि क्या आपने इसे सही तरीके से किया है। खैर, यह बहुत अच्छा नहीं है?
   
4. आलोचक विस्तार का समर्थन करता है। "यह अभी फैशनेबल है।" एक्सटेंशन स्पष्ट रूप से आलोचना की कार्यक्षमता का विस्तार कर सकता है और आपको और भी अधिक समय बचा सकता है। एक्सटेंशन विभिन्न विशिष्ट कार्यक्षमता को लागू कर सकता है जो सभी उपयोगकर्ताओं द्वारा आवश्यक नहीं है। इसलिए, प्रत्येक उपयोगकर्ता अपने लिए उन एक्सटेंशन को इंस्टॉल करता है जिनकी उसे आवश्यकता होती है। मान लीजिए कि आप प्रोजेक्ट X पर काम कर रहे हैं। बग्स को ठीक करें। समीक्षा में, बगफिक्स के लिए शुरू में 1 प्रतिबद्ध था, लेकिन निरीक्षक बहुत सख्त थे, और मुझे उन्हें संतुष्ट करने के लिए तय करने के लिए 5 और सुधार करने पड़े। अंत में समीक्षा मंजूर। और आपके पास प्रतिबद्ध करने के लिए थोड़ा सरल, लेकिन उबाऊ औपचारिक काम है। आपकी परियोजना से किसी ने अपने साथियों के लिए जीवन को आसान बनाने का फैसला किया और अपनी परियोजना के लिए एक विस्तार विकसित किया। विस्तार वेब इंटरफेस में एक बटन "प्रोजेक्ट एक्स में बगिफ्ट को एकीकृत करें" जोड़ता है। अब आप इस मैजिक बटन को दबा सकते हैं, और आलोचक आपके लिए कई उपयोगी चीजें करेगा:
   
   • अपने 6 को 1 में एकत्रित करता है।
   • उसे पहली टिप्पणी से एक टिप्पणी की पेशकश करेगा।
   • टिप्पणी को संपादित करने की पेशकश करेगा।
   • चेक करता है कि क्या परियोजना की मुख्य शाखा के साथ मर्ज संघर्ष हैं, जो आगे बढ़ गए हैं, या बग फिक्स के लिए शाखा।
   • बग फिक्स के लिए शाखा को ठीक करें।
   • आलोचना में समीक्षा बंद कर देता है।
   • बीटीएस में कुछ अच्छा लिखेंगे।
   • BTS में बग को बंद करता है।
   
   
5. आलोचना मुख्य परियोजना भंडार, जैसे गेरिट के आसपास एक आवरण नहीं है। इसलिए, आलोचना का उपयोग आपके संगठन के लिए पूर्व-समीक्षा और पोस्ट-कमिट समीक्षा दोनों के लिए सुविधाजनक हो सकता है। आलोचक, हालांकि, मुख्य भंडार से कोड खींच सकता है, या इसके साथ एक भंडार साझा कर सकता है। और एक्सटेंशन की मदद से कोड को भी पुश करें, जैसा कि पिछले पैराग्राफ में दिखाया गया है।
   

मुझे उम्मीद है कि समालोचना आपके लिए भी उपयोगी होगी। विकास में शुभकामनाएँ!