कोड समीक्षा तकनीकों की तुलना

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

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

बग ढूंढना केवल कोड समीक्षा का कार्य नहीं है। इसके अलावा, कोड अवलोकन में कई और सकारात्मक विशेषताएं हैं:

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

इस सब के लिए, आपको समय देना होगा जो कोडिंग पर खर्च किया जा सकता है। फिर भी, कम से कम कुछ परिप्रेक्ष्य के लिए डिज़ाइन की गई परियोजनाओं पर, भविष्य में बिताया गया समय बाद में एक दोषी "डोपिला" के बजाय एक प्रारंभिक उच्च गुणवत्ता वाले उत्पाद के निर्माण के कारण सौ गुना वापस आ जाएगा।

निम्नलिखित प्रकारों की कोड समीक्षा की जा सकती है:

• औपचारिक कोड निरीक्षण।
• अनौपचारिक कोड निरीक्षण (दूसरा नाम कोड विश्लेषण है)।
• कोड पढ़ना।
• जोड़ी प्रोग्रामिंग।

हम प्रत्येक विकल्प पर अलग से विचार करते हैं।

औपचारिक कोड निरीक्षण

एक औपचारिक कोड निरीक्षण है, जैसा कि नाम का अर्थ है, एक औपचारिक कोड समीक्षा प्रक्रिया। मैककोनेल के अनुसार, वह कुछ इस तरह दिखती है।

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

औपचारिक निरीक्षण का अधिक विस्तृत उदाहरण यहां पाया जा सकता है ।

लाभ:

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

नुकसान:

• एक जटिल औपचारिक प्रक्रिया जिसमें समय लगता है।
• अपनी मुख्य नौकरी से कम से कम 3 लोगों (समन्वयक, कोड और निरीक्षक के लेखक) की व्याकुलता।
• कोड के लेखक पर महान मनोवैज्ञानिक दबाव।

अनौपचारिक कोड निरीक्षण

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

लाभ:

• कम समय की खपत।
• एक सरल प्रक्रिया जिसे औपचारिक प्रक्रियाओं की आवश्यकता नहीं होती है।

नुकसान:

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

कोड पढ़ना

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

लाभ:

• सादगी।
• उच्च उपलब्धता - समय और स्थान में कोई सिंक्रनाइज़ेशन की आवश्यकता नहीं है।

नुकसान:

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

जोड़ी प्रोग्रामिंग

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

लाभ:

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

नुकसान:

• समग्र प्रदर्शन में गिरावट, दो प्रोग्रामर एक कार्य के साथ व्यस्त हैं, दो कार्यों को विकसित करने के बजाय - यह कथन काफी विवादास्पद है, कई अध्ययनों के अनुसार, जोड़े में काम करने वाले प्रोग्रामर के पास अलग-अलग काम करने वाले दो प्रोग्रामर की तुलना में केवल 15% कम प्रदर्शन है।
• वर्क शेड्यूल के सिंक्रोनाइज़ेशन की आवश्यकता होती है - जोड़े में काम करना मुश्किल होता है जब पार्टनर अलग-अलग समय पर डिनर पर जाएं या काम पर आए।
• काम पर लगातार उच्च एकाग्रता के कारण लटका हुआ थकान - जोड़े में काम करने वाले प्रोग्रामर के लिए, यह कार्य दिवस को मानक 8 घंटे से कम करने के लिए भी समझ में आ सकता है।
• सभी लोग संगत नहीं हैं, और कुछ भी किसी के साथ काम करने में सक्षम नहीं हैं। वास्तव में, ऐसे कुछ लोग हैं, और एक जोड़ी में बातचीत की अधिकांश समस्याओं को कई नियमों ( उदाहरण के लिए ) का पालन करके दूर किया जा सकता है, साथ ही साथ जोड़ी में अनुभव के संचय के साथ।
• नियमित कार्यों को करने के लिए अप्रभावी - इस मामले में, एक डेवलपर, जिसके पास कीबोर्ड नहीं है, वह बस ऊब जाएगा।
• डेवलपर्स की गति को सिंक्रनाइज़ करना मुश्किल है, अनुभव और ज्ञान का स्तर जो बहुत भिन्न होता है - अधिक कुशलता से काम करने के लिए, एक अधिक अनुभवी डेवलपर को धैर्य और कुछ सलाह कौशल की आवश्यकता होती है।

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

क्या चुनना है?

अब आप यह तय करने की कोशिश कर सकते हैं कि कौन सी विधि और किस मामले में उपयोग करने लायक है।

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

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

साहित्य

1. सही कोड (कोड पूरा)। स्टीव मैककोनेल अध्याय 21. सह-निर्माण।
2. चरम प्रोग्रामिंग: प्रक्रिया सेटिंग। पहले चरणों से अंत तक (चरम प्रोग्रामिंग एप्लाइड: जीतने के लिए खेल)। केन एयूआर, रॉय मिलर अध्याय 14. अकेले काम करना बंद करो।