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

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

कोड निरीक्षण क्यों महत्वपूर्ण हैं?

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

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

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

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

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

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

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

कोड निरीक्षण अभी भी क्यों नहीं किए गए हैं?

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

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

• दूसरी टीम से प्रोजेक्ट प्राप्त करते समय;
• बड़ी संख्या में त्रुटियों के कारण समय सीमा के निरंतर स्थगन के साथ।

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

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

कई प्रकार के कोड निरीक्षण हैं [1]:

• औपचारिक निरीक्षण
• ओवर-द-शोल्डर रिव्यू
• ई-मेल (ई-मेल पास-पास समीक्षाओं) का उपयोग करके कोड निरीक्षण;
• जोड़ी प्रोग्रामिंग (जोड़ी-प्रोग्रामिंग);
• विशेष उपकरणों (टूल-असिस्टेड रिव्यू) का उपयोग करके कोड निरीक्षण।

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

जोड़ी प्रोग्रामिंग में, दो डेवलपर्स एक ही कंप्यूटर पर एक साथ एक समस्या को हल करते हैं। ओवर-द-कंधे निरीक्षण के मामले में, डेवलपर केवल अपने सहयोगी को कोड दिखाता है।

ई-मेल द्वारा निरीक्षण के दौरान, परिवर्तित कोड स्वचालित रूप से दूसरे प्रोग्रामर को विश्लेषण के लिए भेजा जाता है।

विशेष उपकरणों का उपयोग कर कोड का निरीक्षण विश्लेषण में सहायता करने के लिए उपयोगिताओं की आवश्यकता है।
वे सुविधा:

• कोड में किए गए परिवर्तनों का संग्रह;
• वर्तमान और पिछले कोड की तुलना
• एक विशेष कोड के साथ बातचीत;
• सांख्यिकी संग्रह;
• कोड निरीक्षण और दोषों के सुधार में तेजी;
• आदि

हमारे कोड निरीक्षण अनुभव

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

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

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

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

पीएमडी (जेनकिंस प्लगइन) का उपयोग कर परियोजना विश्लेषण परिणाम

पीएमडी (जेनकिंस प्लगिन) का उपयोग करते हुए पाया दोष का विवरण

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

सोनारक्यूब में परियोजना विश्लेषण परिणाम

सोनारक्यूब में पाए जाने वाले दोष का विवरण

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

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

एक समाधान की तलाश में जो एक औपचारिक कोड निरीक्षण के रूप में प्रभावी होगा, लेकिन इतना समय नहीं लगेगा, हम एटलसियन क्रूसिबल [4] के साथ आए। वास्तव में, इस उपकरण ने सभी कामों को इसमें शामिल किया:

• सत्यापन के लिए कोड परिवर्तन तैयार करना;
• कोड नेविगेशन;
• कोड की कुछ पंक्तियों के संबंध में बातचीत;
• एक निरीक्षण करने के लिए डेवलपर्स को आमंत्रित करना;
• सहकर्मियों द्वारा नोट किए गए सुधारों को ट्रैक करना;
• आदि

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

उदाहरण उपयोगकर्ता स्क्रीन जब Atlassian क्रूसिबल के साथ कोड निरीक्षण का आयोजन

एटलसियन क्रूसिबल कोड निरीक्षण निर्माण स्क्रीन उदाहरण

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

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

हमारे पास क्या है?

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

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

अंत में

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

संदर्भ

1. पीयर कोड रिव्यू / जे। कोहेन, सेंट का सर्वश्रेष्ठ रखा गया रहस्य टेलीकी, ई। ब्राउन
2. सहकर्मी संहिता की समीक्षा के लिए 11 सर्वश्रेष्ठ अभ्यास // smartbear.com/SmartBear/media/pdfs/11_Best_Practices_for_Peer_Code_Review.pdf
3. एटलसियन क्रूसिबल ओवरव्यू - www.atlassian.com/software/crucible/overview
4. सोनारक्यूब - www.sonarqube.org