कोड समीक्षा दर्दनाक हो सकती है। सॉफ़्टवेयर इंजीनियर अक्सर शिकायत करते हैं कि समीक्षा प्रक्रिया धीमी है, डाउनस्ट्रीम कार्यों में देरी करती है, और जब आप एक खुले पुल अनुरोध (पीआर) और अपने अगले कार्य के बीच आगे और पीछे नेविगेट करते हैं तो संदर्भ स्विचिंग की ओर जाता है। कोड समीक्षाएं नाइटपिकिंग और बाइकशेडिंग से भी भरी हो सकती हैं, जिससे इसमें शामिल सभी लोगों के लिए यह एक खराब अनुभव हो सकता है। इस समस्या को दूर करने के लिए, कुछ इंजीनियरों ने यहां तक कहा है कि हम पुल अनुरोधों और कोड समीक्षाओं से पूरी तरह छुटकारा पाने का सुझाव दे रहे हैं। हालांकि यह स्टार्टअप में छोटी टीमों के लिए काम कर सकता है, मुझे नहीं लगता कि यह सभी के लिए सही समाधान है, खासकर उद्यम स्तर की कंपनियों के लिए। इसके बजाय, ऐसे कई तरीके हैं जिनसे हम कोड समीक्षा प्रक्रिया को कोड लेखक और कोड समीक्षक दोनों के लिए एक बेहतर अनुभव बना सकते हैं। आइए इनमें से सात सर्वोत्तम प्रथाओं पर एक साथ विचार करें। # 1: पुल अनुरोधों को छोटा रखें प्रत्येक इंजीनियर उन पुल अनुरोधों की समीक्षा करने से डरता है जिनमें कोड की 1000+ लाइनें बदल गई हैं। इन समीक्षाओं को पूरा होने में घंटों लग सकते हैं, और कई बार ऐसा होता है कि समीक्षक कोड की सावधानीपूर्वक समीक्षा करने के बजाय उस पर ध्यान देना शुरू कर देता है। समाधान यह है कि आप अपने पुल अनुरोधों को छोटा रखें। छोटे पीआर की समीक्षा करना आसान और तेज होता है क्योंकि समीक्षक को मानसिक मॉडल बनाने में अधिक समय खर्च करने की आवश्यकता नहीं होती है कि सभी परिवर्तन एक साथ कैसे काम करते हैं। कम कोड बदला गया है, जो उम्मीद है कि लेखक और समीक्षक के बीच कम त्रुटियों, कम टिप्पणियों और आगे और पीछे के कम दौर के बराबर है। अपने पीआर को छोटा रखना शुरू में मुश्किल लग सकता है, लेकिन यह तब किया जा सकता है जब आप अपने काम को छोटे-छोटे कामों में बांट लें और फोकस्ड रहें। नई सुविधाओं को लागू करने या बग फिक्स करते समय प्रमुख रिफैक्टर न करें। अपने कोड में फीचर फ़्लैग का उपयोग करें ताकि आप नई सुविधाओं के छोटे भागों को उत्पादन ऐप में दिखाए बिना मास्टर शाखा में मर्ज कर सकें। अपने पीआर को छोटा रखें। आपके समीक्षक आभारी रहेंगे। #2: पुल अनुरोध टेम्पलेट का प्रयोग करें एक और झुंझलाहट को बिना किसी संदर्भ के पुल अनुरोध की समीक्षा करने के लिए कहा जा रहा है। जब कोई पीआर आपकी गोद में बिना किसी स्पष्टीकरण के गिरा दिया जाता है, तो आप अक्सर सोच में पड़ जाते हैं, “यह पीआर किस लिए है? यह कौन सा मुद्दा सुलझा रहा है? क्या इसके लिए कोई संबंधित कार्य है? यह खास तरीका क्यों अपनाया गया?” एक छोटा, विन्यास योग्य प्रपत्र है जिसे आप प्रत्येक नए पुल अनुरोध पर डिफ़ॉल्ट पाठ के रूप में सेट कर सकते हैं। पीआर टेम्पलेट कोड लेखक को उनके पीआर के लिए प्रासंगिक विवरण प्रदान करने के लिए प्रेरित करता है। आम तौर पर, एक पीआर टेम्पलेट आपके द्वारा किए गए कार्यों और क्यों, कार्य टिकट के लिए एक लिंक, और परिवर्तनों को मान्य करने के लिए एक परीक्षण योजना का संक्षिप्त विवरण मांगेगा। पुल अनुरोध टेम्पलेट अच्छे पीआर टेम्प्लेट में आमतौर पर कोड लेखक के लिए एक छोटी चेकलिस्ट भी शामिल होती है ताकि यह सुनिश्चित किया जा सके कि उन्होंने कोई भी मूल बातें याद नहीं की हैं। इस चेकलिस्ट में यूनिट परीक्षण, दस्तावेज़, अंतर्राष्ट्रीयकरण, क्रॉस-ब्राउज़र समर्थन और पहुंच जैसे आइटम शामिल हो सकते हैं। नीचे एक उदाहरण पुल अनुरोध टेम्प्लेट है जिसे मैं अपने सभी रेपो के लिए उपयोग करना पसंद करता हूं: #3: प्रतिक्रिया समय SLAs लागू करें यदि आप पाते हैं कि पुल अनुरोधों की आपकी अपेक्षा से अधिक समय तक समीक्षा नहीं हुई है, तो अब एक टीम के रूप में अपेक्षाओं को निर्धारित करने का एक अच्छा समय है कि एक नए पुल अनुरोध की कितनी जल्दी समीक्षा की जानी चाहिए। दूसरे शब्दों में, पीआर को उठाए जाने से पहले अधिकतम कितनी बार मौजूद हो सकता है? एक घंटा? दो घंटे? चौबीस घंटे? उस प्रश्न का आपका उत्तर संभवतः आपकी टीम के आकार पर निर्भर करेगा। आपकी टीम से आंतरिक पुल अनुरोधों के लिए आपके पास अन्य टीमों के बाहरी पुल अनुरोधों के विरुद्ध एक अलग उत्तर भी हो सकता है। प्रतिक्रिया समय SLA (सेवा स्तर समझौता) चुनते समय, आप सही संतुलन खोजना चाहेंगे। जब आप एक नया पीआर पोस्ट करते हैं, तो हर किसी से यह अपेक्षा करना उचित नहीं है कि वे जो कुछ भी कर रहे हैं उसे तुरंत छोड़ दें और अपने कोड की समीक्षा करें, लेकिन आप यह भी नहीं चाहते कि पीआर घंटों तक बिना समीक्षा के रहें। सही संतुलन खोजें जो आपके साथियों को प्रवाह की स्थिति में आने की अनुमति देता है। उन्हें अपने स्वयं के कोड पर काम करने में सक्षम होना चाहिए और फिर पूरे दिन प्राकृतिक रोक बिंदुओं पर पीआर की समीक्षा करनी चाहिए। व्यक्तिगत रूप से, मुझे आंतरिक टीम पीआर के लिए दो घंटे का प्रतिक्रिया समय एसएलए और बाहरी टीम पीआरएस के लिए 24 घंटे का प्रतिक्रिया समय एसएलए होना पसंद है। आप और आपके साथी जो भी निर्णय लेते हैं, उसके बावजूद, एक टीम समझौता होने से आप एक-दूसरे को जवाबदेह ठहरा सकते हैं। यदि हर कोई किसी विशिष्ट SLA के लिए सहमत हो गया है और आपके किसी PR के लिए वह समय बीत चुका है, तो आप जानते हैं कि इसके बारे में लोगों को परेशान करना ठीक है। #4: जूनियर और मिड-लेवल इंजीनियर्स को प्रशिक्षित करें प्रशिक्षण के अवसर हर जगह हैं। कम अनुभवी इंजीनियरों को सलाह देना केवल उन्हें उन तकनीकों और भाषाओं के बारे में सिखाने से ज्यादा शामिल है, जिनके साथ वे काम कर रहे हैं। इसमें उन्हें सॉफ्ट स्किल्स सिखाना भी शामिल है जैसे कि एक प्रभावी कोड समीक्षा कैसे करें। कोड समीक्षा के दौरान अपने साथियों को सिखाएं कि आप क्या खोज रहे हैं। उन्हें यह समझने में मदद करें कि क्या महत्वपूर्ण है और क्या नहीं। उन्हें अपनी में प्रभावी ढंग से संवाद करने का तरीका सिखाएं, जैसे "नाइट" के साथ गैर-अवरुद्ध सुझावों को उपसर्ग करना। कोड समीक्षा टिप्पणियों अधिक प्रभावी कोड समीक्षक कैसे बनें, इस पर बहुत सारे बेहतरीन संसाधन हैं। Google की संपूर्णता में पढ़ने योग्य है। गाइड में कोड लेखक और कोड समीक्षक दोनों के लिए उत्कृष्ट सलाह है। अधिक चुटीले संसाधन के लिए, , पुल अनुरोध बनाने वाले डेवलपर्स के लिए आसानी से सबसे अच्छी (और मनोरंजक) सलाह है। कोड समीक्षा डेवलपर मार्गदर्शिका अपने कोड समीक्षक को आपसे प्यार कैसे करें # 5: सतत एकीकरण पाइपलाइन सेट करें कोड समीक्षाएं थकाऊ हो जाती हैं, जब अधिकांश टिप्पणियां "मिसिंग सेमीकोलन" या "इंडेंटेशन यहां बंद लगती हैं" जैसी चीजें होती हैं। कोड की समीक्षा के दौरान उन चीजों पर समय बर्बाद न करें जो कोड फॉर्मेटर्स और कोड लिंटर आपके लिए ख्याल रख सकते हैं। कंप्यूटर को तुच्छ चीजों को स्वचालित करने दें ताकि आप उन महत्वपूर्ण चीजों पर ध्यान केंद्रित कर सकें जिनके लिए मानव की आवश्यकता होती है। जावास्क्रिप्ट परियोजनाओं के लिए, अपने रेपो के लिए जैसे और ईएसएलिंट जैसे लिंटर को कॉन्फ़िगर करना आसान है। फिर आप , , , या जैसी किसी चीज़ का उपयोग करके अपने रेपो के लिए निरंतर एकीकरण स्थापित कर सकते हैं। प्रीटीयर फॉर्मेटर Travis CI CircleCI GitHub Actions GitLab CI/CD आपकी सीआई पाइपलाइन आपके यूनिट परीक्षणों के साथ आपके लिए इन स्वरूपण और लाइनिंग कार्यों को चलाएगी। यदि पुल अनुरोध पर किसी भी चरण में CI पाइपलाइन विफल हो जाती है, तो यह उस पुल अनुरोध को विलय होने से रोक देगा। अब, आपने कोड समीक्षा के कई महत्वपूर्ण हिस्सों को स्वचालित कर दिया है, जिससे आपके घंटों की बचत होती है। #6: पुल अनुरोध समीक्षा ऐप्स का उपयोग करें कभी-कभी यह न केवल पुल अनुरोध में कोड की समीक्षा करने के लिए आवश्यक होता है, बल्कि यह सत्यापित करने के लिए कि चीजें अच्छी दिखती हैं, ऐप में परिवर्तनों को मैन्युअल रूप से देखना भी आवश्यक है। जटिल सेटअप चरणों वाले ऐप्स के लिए, किसी और के कोड को नीचे खींचकर और इसे अपनी मशीन पर स्थानीय रूप से चलाने में पांच मिनट से लेकर एक घंटे तक का समय लग सकता है। क्या सिरदर्द है! जब भी कोई नया पीआर बनाया जाता है, तो का उपयोग आपके कोड को अल्पकालिक परीक्षण वातावरण में स्वचालित रूप से तैनात करने के लिए किया जाता है। यह समीक्षकों को कोड को नीचे खींचे बिना और अपनी मशीन पर स्थानीय रूप से चलाए बिना आसानी से UI परिवर्तनों का निरीक्षण करने की अनुमति देता है। इससे न केवल समय की बचत होती है, बल्कि यह समीक्षकों को अपनी समीक्षाओं को आसान बनाकर उन्हें और अधिक गहन बनाने के लिए प्रेरित करता है। पुल अनुरोध समीक्षा ऐप #7: अपने कोड परिवर्तनों की कल्पना करने के लिए आरेख बनाएं GitHub या GitLab में कोड की समीक्षा करते समय, फ़ाइलों को आमतौर पर वर्णानुक्रम में दिखाया जाता है। अपेक्षाकृत छोटे पीआर के लिए, यह कोई समस्या नहीं हो सकती है। लेकिन जब पीआर में दर्जनों फाइलें शामिल होती हैं, तो कभी-कभी उन परिवर्तनों को तार्किक रूप से एक साथ समूहीकृत करना उपयोगी होता है ताकि आप देख सकें कि वे एक बड़ी तस्वीर में एक साथ कैसे फिट होते हैं। आपको यह देखने में मदद करता है कि कौन सी फाइलें बदली गईं और वे बदलाव उनकी अपस्ट्रीम और डाउनस्ट्रीम निर्भरता को कैसे प्रभावित करते हैं। वे आपके पीआर पर स्वचालित रूप से एक टिप्पणी और एक आरेख पोस्ट करने के लिए गिटहब के साथ एकीकृत होते हैं। आप अपने कोड समीक्षकों का मार्गदर्शन करने में सहायता के लिए अपने कोड के इंटरैक्टिव टूर भी बना सकते हैं। सबसे अच्छी बात, कोडसी मैप्स ओपन-सोर्स संगठनों और उनके सार्वजनिक भंडारों के लिए स्वतंत्र हैं। कोडसी रिव्यू मैप्स निष्कर्ष: कोड समीक्षा में अपना समय नाटकीय रूप से कम करने के 7 तरीके संक्षेप में, कोड समीक्षा में अपना समय नाटकीय रूप से कम करने के लिए यहां सात युक्तियां दी गई हैं: पुल अनुरोधों को छोटा रखें। एक समीक्षक के लिए आवश्यक सभी संदर्भ प्रदान करने के लिए पुल अनुरोध टेम्प्लेट का उपयोग करें। प्रतिक्रिया समय SLAs लागू करें। कोड समीक्षा के दौरान आपके द्वारा देखी जाने वाली प्रमुख चीज़ों पर जूनियर और मिड-लेवल इंजीनियरों को प्रशिक्षित करें। लिंटर, फॉर्मेटर और यूनिट परीक्षण चलाने के लिए सीआई पाइपलाइन स्थापित करें। पुल अनुरोध समीक्षा ऐप्स का उपयोग करें ताकि आप आसानी से UI परिवर्तनों का निरीक्षण कर सकें। कोडसी रिव्यू मैप्स जैसे टूल का उपयोग करके अपने कोड परिवर्तनों की कल्पना करने के लिए आरेख बनाएं। पढ़ने के लिए धन्यवाद, और खुश कोडिंग! भी प्रकाशित यहाँ
