👆🏽 🎒 🕵🏻 कोड समीक्षा - प्रक्रिया में सुधार 👩🏿‍💼 🤟 👨🏾‍🚀

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

इससे कैसे बचा जा सकता है?शीर्षक में प्रश्न का उत्तर कोड समीक्षा है।

कोड समीक्षा त्रुटियों की एक कोड जांच है जो कोड की स्थिरता और गुणवत्ता में सुधार करती है।

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

चयनित शाखा में परिवर्तन के अनुमोदन और आवेदन के लिए परियोजना टीम (व्यक्ति या लोगों का समूह) के लिए अनुरोध / मर्ज अनुरोध अनुरोध है। जैसे ही पुल अनुरोध बनाया जाता है, लिखित कोड की चर्चा अनुमोदन से पहले होती है। चर्चा के दौरान परिवर्तन का सुझाव दिया जा सकता है। अनुमोदन के बाद, वर्तमान परिवर्तन चयनित शाखा में आते हैं।

नीचे दी गई सूचियों में कोड की समीक्षा में तेजी लाने और इसकी गुणवत्ता में सुधार करने में मदद करने के लिए सिफारिशें दी गई हैं।

हम प्रश्न को तीन भागों में विभाजित करते हैं और प्रत्येक पर अलग से विचार करते हैं:

तकनीकी भाग: कोड की जाँच कैसे करें और जाँच करते समय क्या देखना है?
संचार भाग: चर्चा के दौरान विवादों को कैसे रोकें और तनाव को कम करें?
संगठनात्मक भाग: कोड समीक्षा प्रक्रिया को कुशल बनाने के लिए क्या किया जा सकता है?

भाग 1. कोड की जाँच

घर पर लेखक कोड चलाएं

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

उपयोगकर्ता अनुभव याद रखें

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

हम सामान्य तर्क को देखते हैं

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

हम कोड वास्तुकला को देखते हैं

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

हम आसान लिखते हैं

कोड री-कॉम्प्लीकेशन पर ध्यान दें: कोड जितना सरल होगा, पढ़ने में उतना ही आसान और बनाए रखने में आसान होगा। कोड के जटिल टुकड़ों से छुटकारा पाएं।

बहु सूत्रण

यदि प्रोजेक्ट में कई थ्रेड्स में कार्य शामिल है, तो देखें कि क्या होता है यदि थ्रेड्स में से किसी एक में कोड के निष्पादन के दौरान देरी होती है, और ऐसे मामलों को कैसे काम किया जाता है।

अत्यधिक अनुकूलन

जैसा कि क्लासिक डोनाल्ड नुथ ने लिखा है, समयपूर्व अनुकूलन सभी बुराई की जड़ है। यहां और अभी जो आवश्यक है, उसे ही ऑप्टिमाइज़ करना बेहतर है।

हम त्रुटियां दूर करते हैं

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

अनुपालन

कोड को समझौते, कोड शैली का अनुपालन करना चाहिए। कोड की एकरूपता एक कानाफूसी नहीं है, लेकिन एक आवश्यकता है: इस तरह के कोड को बनाए रखना आसान है, और इस कोड को समझना आसान है।

नाम और रूप

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

कोड टिप्पणियाँ

टिप्पणियों को इस सवाल का जवाब देना चाहिए: "यह क्यों किया गया है?", और नहीं "यह कैसे किया जाता है?"। यह याद रखना।

भाग 2. हम चर्चा करते हैं

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

एक नियम के रूप में, पुल अनुरोध विशेष वेब होस्टिंग सेवाओं (github.com, bitbucket.org, gitlab.com, आदि) पर किया जाता है, जहां परिवर्तनों को देखना और कोड के एक विशिष्ट टुकड़े पर एक टिप्पणी छोड़ना संभव है।

हम समझौते का अनुपालन करते हैं

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

हम एक विकल्प प्रदान करते हैं

"आपने गलत किया ..." जैसे बयानों से बचें, "ऐसा क्यों, आप ऐसा क्यों लिखते हैं?" और अन्य। वे आलोचना के रूप में माना जाता है और बहाने के लिए नेतृत्व करते हैं। लेखक की पहचान का सहारा लिए बिना, कोड की सामग्री के बारे में एक टिप्पणी लिखना बेहतर है। आदेशों और ज़बरदस्ती से बचने की भी कोशिश करें: लोग पसंद नहीं करते जब कोई उन्हें आदेश देता है, और ऐसी टिप्पणियों को नकारात्मक रूप से देखता है।

आप निम्नानुसार आगे बढ़ सकते हैं:

हम लिखते हैं कि कोड में क्या गलत है
क्यों न लिखना ही बेहतर है
हम वैकल्पिक विकल्प प्रदान करते हैं

हम समस्या के दायरे में रहते हैं

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

प्रशंसा

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

सभी टिप्पणियाँ समान हैं।

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

अपने विचारों को स्पष्ट रूप से व्यक्त करें

उत्पादक संचार के लिए, यथासंभव विस्तृत लिखें और हर विवरण की व्याख्या करें। हर किसी के पास ज्ञान का एक अलग स्तर है, और अब तक किसी ने भी दिमाग पढ़ना नहीं सीखा है।

सवाल पूछ रही है

अपने सहयोगियों से पूछने के लिए स्वतंत्र महसूस करें कि उनका प्रस्तावित विकल्प आपके वर्तमान से बेहतर क्यों है। यह कुछ नया सीखने और पेशेवर रूप से विकसित होने का एक शानदार अवसर है।

हम संघर्षों का समाधान करते हैं

ऐसा होता है कि एक व्यक्ति सभी तर्कों को स्वीकार नहीं करता है और अपनी पेशकश नहीं कर सकता है, कुछ करने से इनकार करता है। इस मामले के लिए कुछ व्यावहारिक सुझाव:

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

भाग 3. प्रक्रिया में सुधार

हमने वर्णन किया कि उन्होंने क्या किया

हम पुल अनुरोध शीर्षलेख में कार्य के सार का वर्णन करते हैं (या एक अलग टिप्पणी करते हैं) और इसे पूरा करने के लिए क्या कदम उठाए गए हैं।

पुल अनुरोध को भागों में विभाजित करें

एक बड़े हिस्से को लंबे समय तक देखा जाएगा, लंबे समय तक चर्चा की जाती है और लंबे समय तक सही किया जाता है। कोड को छोटे तार्किक भागों में विभाजित करें - इस तरह यह प्रक्रिया बहुत तेज़ी से आगे बढ़ेगी।

सभी टिप्पणियों का जवाब दें

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

सभी खोजें?

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

सभी का इंतजार है?

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

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

छोटी बातें

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

निष्कर्ष

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

कोड समीक्षा - प्रक्रिया में सुधार