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

कटलेट अलग, मक्खियों अलग

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

पत्राचार मुक्केबाजी

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

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

आप यहाँ क्या कर रहे हैं?

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

क्या मछली में यह मछली है!

निरीक्षण करने से पहले, जबकि आपकी आँखें धुंधली नहीं हैं, तो सोचें कि आप कार्य को कैसे हल करेंगे। यदि आपको अचानक पता चलता है कि आपका निर्णय निरीक्षण के लिए प्रदान किए गए की तुलना में काफी बेहतर है, तो इसे लेखक को रिपोर्ट करने में संकोच न करें। बेहतर है कि वह इसे अब ठीक कर दे, जबकि यह इतना महंगा नहीं है और यह बैसाखी नहीं है।

सभी मार्कर स्वाद और रंग में भिन्न हैं।

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

और अगर उसकी जेब में ग्रेनेड होता तो?

वैकल्पिक परिदृश्य देखें। अक्सर प्रोग्रामर कार्यक्रम के मुख्य प्रवाह पर केंद्रित होता है और विकल्पों को सही ढंग से संसाधित करने के लिए भूल जाता है। इस तरह के पंचर को बदलने के लिए, कार्य में डूबे हुए व्यक्ति के रूप में, आपके लिए यह आसान है।

गंध के लाभों के बारे में

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

पुनश्च: टिप्पणियों में कोड निरीक्षण पर अपनी टिप्पणी साझा करने के लिए एक बहुत बड़ा अनुरोध। एक प्रभावी निरीक्षण के लिए आप क्या सलाह देंगे?

प्रभावी कोड निरीक्षण के लिए व्यावहारिक सुझाव