विकास प्रक्रिया में कोड निरीक्षण को एकीकृत करना

चेतावनी! यह लेख उन लोगों के लिए अभिप्रेत है, जिन्हें इस बात का अंदाजा है कि कोड निरीक्षण क्या हैं और कौन इस तकनीक को अपनी कंपनी में लागू करना चाहते हैं।


जब हमने अपनी परियोजनाओं में कोड समीक्षा को लागू करने की प्रक्रिया में संलग्न होना शुरू किया, तो हमें खरोंच से इस प्रक्रिया को आयोजित करने पर समझदार सामग्रियों की कमी से अप्रिय आश्चर्य हुआ। निरीक्षण प्रक्रिया का एक और बेहद खराब पहलू है।

इस अंतर को भरना, हम अपनी टीम में इस अद्भुत अभ्यास को शुरू करने के अनुभव को साझा करना चाहते हैं। टिप्पणियों में रचनात्मक आलोचना का स्वागत है।

तो चलिए शुरू करते हैं।

यह सब क्यों है?

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

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

निरीक्षण में कौन शामिल है?

आइए कुछ शब्दों को स्पष्ट करें जिनका उपयोग हम बाद में विषय में करेंगे।

लेखक एक कोड डेवलपर है।

इंस्पेक्टर (समीक्षक) - उन सभी परिवर्तनों के लिए जिम्मेदार डेवलपर जो परियोजना शाखा में किसी विशेष मॉड्यूल या पथ में आते हैं।

ऑब्जर्वर (ऑब्जर्वर) - एक डेवलपर जो एक विशेषज्ञ के रूप में शामिल है।

कब करें निरीक्षण?

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



यह कहा जाना चाहिए कि स्वयं के लिए हमने शुरू में पूर्व-प्रतिबद्ध निरीक्षणों को चुना।

यह कैसे काम करता है?

निरीक्षण करते समय, डेवलपर निम्नलिखित प्रतिभागियों को जोड़ता है:

1. अपने समूह से निरीक्षकों;
2. टीम लीडर।

टीम लीडर पर्यवेक्षकों को टीम के नेताओं के रूप में नियुक्त करता है जिनके मॉड्यूल में परिवर्तन हुए हैं।

टीम के नेता अपनी टीमों से निरीक्षकों को नामित करते हैं।



यह दृष्टिकोण निरीक्षण प्रतिभागियों और पूरी तरह से दोनों लंबवत (पदानुक्रम में) और क्षैतिज रूप से (परियोजना टीमों की संख्या में वृद्धि के साथ) की विकेन्द्रीकृत नियुक्ति सुनिश्चित करता है।

कार्यान्वयन के लिए क्या आवश्यक है?

कोड निरीक्षण के सफल कार्यान्वयन के लिए, कई शर्तों को पूरा करना होगा।

• रिपॉजिटरी में प्रवेश करने से पहले, किसी भी कोड को कम से कम एक व्यक्ति द्वारा देखा जाना चाहिए जो इसमें अच्छी तरह से वाकिफ है।
• विकास दल हमेशा उन परिवर्तनों से अवगत होता है जो अन्य समूह अपनी परियोजना में कर रहे हैं।
• समूह का नेता उस चीज से अवगत होता है जो समूह करता है, और अपने समूह में किसी भी कोड का पर्याप्त विचार प्राप्त करता है।
• समूह के अंदर, डेवलपर्स को कोड का एक अच्छा विचार है जो उनके सहकर्मी लिखते हैं।

जब इन शर्तों को पूरा किया जाता है, तो परियोजना प्रतिभागियों द्वारा सामान्य कोड स्वामित्व का एक अच्छा स्तर हासिल किया जाता है।

शायद यही सब है :)

यदि कोड निरीक्षण का विषय और हमारे अनुभव का वर्णन हैबरोसिटी के लिए रूचि का होगा, तो हम निम्नलिखित लेखों में से एक को SmartCear CodeCollaborator टूल का उपयोग करके निरीक्षण प्रक्रिया को स्वचालित करने के लिए समर्पित करेंगे।



धन्यवाद और जल्द ही मिलते हैं!