कोड समीक्षा अभ्यास: विश्लेषण और तकनीकी निर्णय क्षमता विकसित करने के लिए सहकर्मी समीक्षा का उपयोग कैसे करें

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

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

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

कोड रिव्यू एक्सरसाइज क्या हैं?

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

त्वरित तथ्य

1. प्रदर्शन संबंधी समस्या का वर्णन करें।

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

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

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

2. सीखने और संदर्भ संबंधी कमियों का निदान करें

इस कार्य की तुलना अपने वर्तमान कार्यक्रम में अपनाई जाने वाली पद्धतियों और मूल्यांकन विधियों से करें।

1. क्या वर्तमान कार्यप्रणाली में वास्तविक कार्य का उपयोग किया जाता है? यदि नए समीक्षक स्टाइल गाइड पढ़कर और फिर लाइव पुल रिक्वेस्ट की समीक्षा करके सीखते हैं, तो वे वास्तविक कार्य पर अभ्यास करते हैं जहाँ गलती करने की कोई गुंजाइश नहीं होती। यदि मूल्यांकन समीक्षा शिष्टाचार पर आधारित एक परीक्षा है, तो यह नियमों को याद रखने की क्षमता को मापता है, न कि उन्हें किसी बदलाव पर लागू करने की क्षमता को।
2. संज्ञानात्मक आवश्यकता क्या है? ब्लूम के संशोधित वर्गीकरण में, किसी डिज़ाइन की उपयुक्तता का आकलन करना और उसके लाभ-हानि का मूल्यांकन करना विश्लेषण और मूल्यांकन स्तरों पर आता है, जबकि बेहतर संरचना का प्रस्ताव देना सृजन स्तर पर पहुँचता है। यदि आपके अभ्यास केवल "यह कोड क्या करता है?" पूछते हैं, तो वे केवल समझने तक ही सीमित रह जाते हैं। हमारी मार्गदर्शिका ब्लूम के वर्गीकरण के अनुसार सीखने की गतिविधियों का मिलान करना यह दर्शाता है कि गतिविधि को स्तर से कैसे मिलाया जाए।
3. क्या कौशल के अलावा कोई और चीज बाधा बन रही है? समीक्षा के लिए निर्धारित समय, उपकरण, स्वामित्व और टीम के मानदंडों की जाँच करें। यदि समीक्षकों को प्रत्येक पुल रिक्वेस्ट के लिए पाँच मिनट का समय दिया जाता है, तो कोई भी समीक्षा प्रक्रिया विचारपूर्ण स्पष्टीकरण उत्पन्न नहीं कर पाएगी। यदि लेखक प्रत्येक टिप्पणी को आलोचना के रूप में लेते हैं, तो समीक्षक अपने निष्कर्षों को नरम कर देंगे और अंततः कुछ भी नहीं कहेंगे। इन कारणों की जानकारी उन लोगों को दें जो इन्हें ठीक कर सकते हैं।

3. डिज़ाइन की तैयारी, अभ्यास और प्रतिक्रिया

प्रत्येक चरण को अलग-अलग कार्य सौंपें।

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

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

प्रतिक्रिया। इसे समीक्षक द्वारा लिए गए निर्णयों से जोड़ें। "आपने राउंडिंग की समस्या देखी, लेकिन आपकी टिप्पणी में केवल 'यह गलत लग रहा है' लिखा है, यह बताए बिना कि किस इनपुट से समस्या आ रही है" यह "4 में से 2 सही पाए गए" से अधिक उपयोगी है।

लाइव इनपुट या अतुल्यकालिक समीक्षा? लाइव इनपुट तब सबसे अधिक उपयोगी होता है जब कोई समस्या अस्पष्ट हो और समीक्षक वरिष्ठ इंजीनियर से यह सुनकर सीख सकें कि वे इसे क्यों उठाएंगे या क्यों अनदेखा करेंगे। टिप्पणियों की तुलना विशेषज्ञ की विस्तृत समीक्षा से करने के लिए अतुल्यकालिक समीक्षा पर्याप्त है।

4. एक वास्तविक उदाहरण के माध्यम से काम करें

उदाहरण के तौर पर। इंजीनियरिंग मैनेजर को उपयोग करने से पहले मामले और उत्तर के मानदंडों को सत्यापित करना चाहिए।

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

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

पहला प्रयास। "ठीक लग रहा है, परीक्षा पास हो गई। शायद इसे अलग-अलग हिस्सों में बाँट लें?" समीक्षक ने कुछ देखा है, लेकिन यह नहीं बताया कि क्या, क्यों महत्वपूर्ण है या क्या करना है। लेखक इस पर कोई कार्रवाई नहीं कर सकता।

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

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

5. क्षमता का आकलन करें और स्थानांतरण की योजना बनाएं

क्षमता का प्रमाण किसी ऐसे नए बदलाव पर प्रदर्शन है जिसे समीक्षक ने पहले नहीं देखा है। निष्कर्षों की सटीकता और स्पष्टीकरण की उपयोगिता का मूल्यांकन करें। एक सरल मानदंड के लिए 0 से 2 तक के पैमाने का उपयोग किया जाता है:

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

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

6. AhaSlides की मदद से अभ्यास को लाइव या अपनी गति से करें।

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

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

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

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

वे बाधाएं जो बनी रह सकती हैं

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

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

ज़्यादातर पूछे जाने वाले सवाल

कोड रिव्यू एक्सरसाइज क्या हैं?

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

आप यह कैसे आंकते हैं कि समीक्षक के निर्णय में सुधार हुआ है या नहीं?

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

क्या पीयर कोड रिव्यू का मुख्य उद्देश्य बग ढूंढना है?

खामियों को ढूंढना अभी भी एक मुख्य प्रेरणा है, लेकिन माइक्रोसॉफ्ट में किए गए एक अध्ययन में पाया गया कि समीक्षाओं में खामियों पर उम्मीद से कम ध्यान दिया गया और साथ ही ज्ञान साझा करने और टीम में जागरूकता बढ़ाने में भी मदद मिली। ऐसे अभ्यास तैयार करें जो खामियों की संख्या के साथ-साथ स्पष्टीकरण और समझ को भी पुरस्कृत करें।

कहा से शुरुवात करे

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

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