🧝🏿 ⏸️ 🌎 कोड समीक्षा पर एक और लेख ⚔️ 🥁 ➰

कोड समीक्षा क्या है

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

इस अभ्यास के स्पष्ट लाभों में शामिल हैं:

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

क्या निरीक्षण किया जा सकता है

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

समीक्षा कैसे करें

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

क्या समीक्षा के होते हैं

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

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

डिज़ाइन समीक्षा कैसे करें

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

कोड समीक्षा कैसे करें

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

पूर्व-प्रतिबद्ध समीक्षा

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

पोस्ट-कमिट की समीक्षा

वीसीएस में बदलाव करने के बाद इस तरह की समीक्षा की जाती है। इस स्थिति में, आप दोनों मुख्य शाखा और अस्थायी शाखा के लिए प्रतिबद्ध हो सकते हैं (और पहले से सत्यापित परिवर्तन मुख्य शाखा में जोड़े जा सकते हैं)।

विषयगत समीक्षा

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

" आइए इस मॉड्यूल में त्रुटियों की तलाश करें " - एक लक्ष्य के रूप में उपयुक्त नहीं है, क्योंकि यह असीम है।
" RFC 1149 विनिर्देश के अनुपालन के लिए एल्गोरिथ्म का विश्लेषण " पहले से बेहतर है।

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

परिणाम की समीक्षा करें

समीक्षा का आयोजन करते समय सबसे महत्वपूर्ण बात यह है कि परिणाम का उपयोग करें। निम्नलिखित कलाकृतियां समीक्षा के परिणामस्वरूप दिखाई दे सकती हैं:

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

इसी समय, यह बहुत महत्वपूर्ण है कि सभी परिणाम खो नहीं जाते हैं, और वे वीसीएस, विकी में दर्ज किए जाते हैं। इससे रोका जा सकता है:

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

इन समस्याओं को दूर करने के लिए, यह आंशिक रूप से मदद कर सकता है:

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

समीक्षा करने में कठिनाई (व्यक्तिपरक राय)

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

समीक्षा के लिए उपयोगिताएँ

सामान्य तौर पर, समीक्षा और भुगतान दोनों के लिए बड़ी संख्या में उपयोगिताओं हैं। मैंने उन्हें नहीं दिया, इसलिए अपनी बात को थोपने के लिए नहीं, इंटरनेट पर आप कई उपकरण और एक विस्तृत विवरण पा सकते हैं।

संदर्भ

सुझाव, परिवर्धन, आलोचना का स्वागत है

कोड समीक्षा पर एक और लेख