मेरे समुदाय में किसी ने आज पुल अनुरोधों (पीआर) की समीक्षा करने में बेहतर होने के बारे में पूछा, जिसने इस पोस्ट को प्रेरित किया। उम्मीद है, आपको यहां कुछ मददगार लगा होगा। अगर आप ऐसा करते हैं तो मुझे आपसे सुनना अच्छा लगेगा! और यदि आप नहीं करते हैं, तो भी ठीक है। मेरी प्रक्रिया में सुधार के लिए सुझावों का स्वागत है! वर्चुअल कॉफ़ी सबसे पहले, मैंने यह देखने के लिए शीर्षक और विवरण पढ़ा कि यह सब क्या है। यदि कोई मुद्दे या अन्य पीआर संदर्भित हैं, तो मुझे और संदर्भ की आवश्यकता होने पर मैं उनकी जांच करता हूं। अगर यूजर इंटरफेस (यूआई) में बदलाव होते हैं, तो मैं स्क्रीनशॉट के पहले और बाद में देखता हूं। यदि कोई स्क्रीनशॉट नहीं हैं और UI परिवर्तन मौजूद हैं, तो मैं समीक्षक से कुछ शामिल करने के लिए कहता हूं। यह उच्च-स्तरीय नज़र से परिवर्तनों का आकलन करना बहुत आसान बनाता है। ठीक है! आइए इसका परीक्षण करने के लिए कोड चलाएं! वाह, अभी नहीं। इसके बाद, मैं सभी बदली हुई फाइलों के माध्यम से स्किम करना शुरू करता हूं। अगर फाइलों में कई बदलाव होते हैं, तो पीआर समीक्षा डराने वाली और बोझिल हो सकती है। सामान्य तौर पर, पीआर कुछ कारणों से छोटा होना चाहिए: समीक्षा करना आसान है आपके पास कोड में जितने कम बदलाव होंगे, बग्स की संभावना उतनी ही कम होगी। मैं संभावित कहता हूं क्योंकि एक-लाइनर भी बग पैदा कर सकता है। कभी-कभी काफी बड़े पीआर के अलावा कोई विकल्प नहीं होता है। मैंने इसे मुख्य रूप से UI कार्य में देखा है, लेकिन यह बैकएंड कार्य पर भी लागू होता है, आमतौर पर एक ऑल-ऑर-नथिंग परिदृश्य। यदि उपरोक्त नहीं होता है, तो ये कारण हैं कि मैं देखता हूं कि पीआर क्यों फूला हुआ है: व्यक्ति रिफैक्टरिंग या बग फिक्स करता है जो वे कर सकते हैं, लेकिन वे पीआर से संबंधित नहीं हैं। उन्हें एक अलग पीआर में डालने के लिए कहें और पीआर को काम पर रखने के लिए कहें। किया जाने वाला काम टूटा नहीं है। वह कार्य करें जो अधिक व्यापक कार्य को आगे ले जाए। उदाहरण के लिए, पूरे फीचर में उपयोग किया जाने वाला एक उपयोगिता फ़ंक्शन एक अलग पीआर में हो सकता है। क्या व्यक्ति एक नया UI बना रहा है? वे स्वतंत्र रूप से घटकों का निर्माण कर सकते हैं और एक अलग पीआर रख सकते हैं, संभावित रूप से उन्हें बनाने के लिए जैसे टूल का उपयोग कर सकते हैं। स्टोरीबुक याद रखें कि किसी मुद्दे या फीचर को एक पीआर के साथ मैप करने की जरूरत नहीं है। अंत में, मैं कुछ कोड देखता हूं! मैं उन मुद्दों की खोज करता हूं जो पीआर को नीचे खींचे बिना और मेरे स्थानीय पर कोड चलाए बिना मेरे सामने खड़े होते हैं। मैं स्वरूपण/कोडिंग शैली के मुद्दों के बारे में बात नहीं कर रहा हूं क्योंकि आजकल, कई परियोजनाओं में लिंटर या कोड फॉर्मेटर्स जैसे टूलिंग होते हैं। जिन चीजों की मैं तलाश करता हूं: तर्क त्रुटियां एक भाषा विशेषता जिसके बारे में व्यक्ति को पता नहीं हो सकता है जिसका उपयोग पीआर . में किया जा सकता है कोडबेस में मौजूदा उपयोगिता कार्यों का लाभ उठाना परीक्षण प्रलेखन अभिगम्यता के मुद्दे कुछ मामलों में, कोडिंग शैली सामने आ सकती है, उदाहरण के लिए, किसी फ़ंक्शन या विधि में कोई शर्त विफल होने पर जल्दी लौटना। यदि समीक्षा के दौरान परिवर्तन आते हैं जिन्हें स्वचालित रूप से बदला जा सकता है, तो स्वचालित रूप से दूर हो जाएं! हालांकि, इसे एक अलग पीआर में करें। मैं कोड के पहले स्वीप के बाद, अगर मेरे पास परिवर्तन अनुरोध हैं तो मैं पीआर को समीक्षाकर्ता को वापस भेज देता हूं। एक सेकंड रुको? क्या आपने अभी तक कोड भी नहीं चलाया है? एक समीक्षक के रूप में, मुझे अपना काम भी करना है, इसलिए मैं टेस्ट ड्राइव के लिए पीआर लेने पर रोक लगाऊंगा। प्रारंभिक समीक्षा के बाद, मैं किए गए परिवर्तनों और प्रतिक्रिया की जांच करता हूं। मैं और प्रतिक्रिया दे सकता हूं। एक बार जब कोई परिवर्तन नहीं छोड़ा जाता है (फिलहाल), तो मैं कोड को नीचे खींचता हूं और इसे स्थानीय रूप से चलाता हूं। प्रोजेक्ट के सेटअप के आधार पर, यह Netlify या Vercel जैसे होस्ट पर PR के लिए प्रीव्यू डिप्लॉयमेंट या परीक्षण के लिए कुछ कंटेनरीकृत वातावरण हो सकता है। भले ही, अब पीआर के इरादों को सत्यापित करने का समय है। इस बिंदु पर, अभी भी समीक्षा प्रतिक्रिया होने की सबसे अधिक संभावना है, इसलिए मैं परिवर्तनों की समीक्षा करने और पीआर के इरादों को सुनिश्चित करने के चक्र को जारी रखता हूं। कार्य के आधार पर, समीक्षा प्रक्रिया में कुछ समय लग सकता है; समय क्षेत्र के अंतर समीक्षा समय को बढ़ा सकते हैं। महत्वपूर्ण है, खासकर अब जब बहुत सारे तकनीकी उद्योग आगे बढ़ रहे हैं/दूरस्थ संस्कृति में चले गए हैं। एसिंक्स संचार में महान बनना अंत में, समीक्षा का स्वर मायने रखता है। मैं नामक टिप्पणी के लिए एक फ्रेमवर्क का उपयोग करने का आदी हो गया हूं। यदि आप और अधिक सीखने में रुचि रखते हैं, तो मैंने पिछले साल थी। Netlify ने नामक एक समान प्रणाली बनाई। कन्वेंशनल कमेंट्स पारंपरिक टिप्पणियों पर एक हल्की-फुल्की बात की फीडबैक लैडर्स यदि आपने इसे इतना दूर कर लिया है, तो आपका पीआर स्वीकृत हो गया है! मैं धन्यवाद और अगली बार तक! . पर द्वारा फोटो Unsplash मार्कस विंकलर यहां भी प्रकाशित: https://www.iamdeveloper.com/posts/how-i-review-pull-requests-44nl/
