कोड लिखने और समीक्षा करने के कई वर्षों में, मैंने बेहतर पुल अनुरोधों और समीक्षा कोड को अधिक कुशलता से तैयार करने के कुछ रहस्य सीखे।
मैंने इन सभी रहस्यों को अपनी नई पुस्तक पुल रिक्वेस्ट्स एंड कोड रिव्यू में डाला है, लेकिन आपको यहां इन 13 युक्तियों के साथ एक पूर्वावलोकन मिलेगा, जिन्हें आप पहले से ही अपनी डेवलपर गतिविधि में उपयोग कर सकते हैं।
क्या आप और युक्तियों के बारे में सोच सकते हैं? उन्हें टिप्पणियों में साझा करें 😉
एक पीआर ड्राफ्ट आपको अपने विचारों को व्यवस्थित करने और अपनी प्रगति का दस्तावेजीकरण करने में मदद करता है, जबकि आप अभी भी अपनी सुविधा पर काम कर रहे हैं।
त्वरित और कुशल समीक्षा पाने का सबसे अच्छा तरीका है कि आप अपने पीआर को छोटा और अच्छी तरह से प्रलेखित रखें (सभी आवश्यक संदर्भ के साथ)। अभी बेहतरीन कोड प्रदान करके आप भविष्य में पीआर के लिए अपनी संभावनाएं भी बढ़ाएंगे!
मेरी निःशुल्क पुस्तक पुल रिक्वेस्ट्स एंड कोड रिव्यू: जूनियर से टीम लीड तक डेवलपर्स के लिए सर्वोत्तम अभ्यास में अधिक वास्तविक जीवन के उदाहरणों और कार्रवाई योग्य अंतर्दृष्टि के साथ इन सभी युक्तियों को ढूंढें।
अपने आप को अपने समीक्षक के स्थान पर रखें, प्रश्नों का पूर्वानुमान लगाएं और जब आपको लगे कि इससे उन्हें मदद मिल सकती है तो अपने स्वयं के कोड पर टिप्पणी करें।
अपने पीआर को पूरी दुनिया को न सौंपें। अनुमोदन के लिए बहुत लंबा इंतजार किए बिना, प्रासंगिक समीक्षा प्राप्त करने के लिए अपने समीक्षकों को सावधानीपूर्वक चुनें।
प्रतिक्रिया के लिए खुले रहें, स्पष्टीकरण मांगें, जब आप असहमत हों तो कहें (सम्मान के साथ), और हमेशा टिप्पणियों का जवाब दें।
हर किसी के पास समीक्षा करने के लिए बहुत सारे पीआर होते हैं और बहुत कम खाली समय होता है। यदि आप अन्य पीआर की समीक्षा करते हैं, तो आपकी समीक्षा होने की संभावना भी बढ़ जाती है।
एक जूनियर डेवलपर के रूप में, जब आप कोड का कोई हिस्सा नहीं समझते हैं तो आप दूसरों को बता सकते हैं, क्योंकि इसे टीम में किसी भी डेवलपर द्वारा समझा जाना चाहिए।
मेरी पोस्ट में इसके बारे में अधिक जानकारी जूनियर डेवलपर के रूप में कोड समीक्षा कैसे दें? .
कोड समीक्षा का लक्ष्य बग और किनारे के मामलों की जांच करना और कार्यान्वयन को चुनौती देना है। इसका उपयोग न तो छोटी प्रारूपण या स्टाइलिंग प्राथमिकताओं के बारे में आलोचना करने के लिए किया जाना चाहिए, न ही बड़े पैमाने पर वास्तुशिल्प चर्चाओं के लिए किया जाना चाहिए।
"आपको करना चाहिए" के बजाय "क्यों नहीं" का प्रयोग करें, खुले और सकारात्मक रहें और जब आप बदलाव के लिए पूछें तो हमेशा एक विकल्प सुझाएं।
सभी टिप्पणियों में बदलाव की आवश्यकता नहीं है, और पीआर को स्वीकृत करने के लिए सभी पूछे गए परिवर्तनों की आवश्यकता नहीं है। यदि परिवर्तन अत्यावश्यक नहीं है तो अपनी टिप्पणी में स्पष्ट रहें।
अपनी समीक्षा को सार्वजनिक करने से पहले, प्रत्येक टिप्पणी को दोबारा पढ़ें: आपके द्वारा उपयोग किए जाने वाले लहजे की जांच करें और सुनिश्चित करें कि आप पीआर प्रस्तुतकर्ता की मदद के लिए सभी संदर्भ प्रदान करते हैं।
आप नहीं चाहेंगे कि समीक्षक आपके द्वारा पूछे गए सभी परिवर्तन करने के बाद दो दिन तक आपकी स्वीकृति की प्रतीक्षा करे। जब आप इसकी समीक्षा करते हैं, तो मान लें कि सभी सुधार होते ही आप इसे स्वीकृत कर देंगे।
जब कोई टिप्पणी थ्रेड आपके पीआर में बहस बन जाता है, तो बेहतर होगा कि आप इसे काट दें और चर्चा को कहीं और जारी रखने का सुझाव दें, उदाहरण के लिए स्लैक थ्रेड में। यदि आवश्यक हो, तो इसके लिए एक बैठक समर्पित करें, और/या किसी तीसरे पक्ष को शामिल करें।
इतना ही! आपने इन युक्तियों के बारे में क्या सोचा? क्या आप एक टिप के बारे में सोच सकते हैं जो आप अन्य डेवलपर्स को देना चाहेंगे?
उन्हें यहां टिप्पणियों में साझा करें 👇
यदि आपको ये युक्तियाँ पसंद आईं और आप कुछ और सीखना चाहते हैं, तो मेरी पुस्तक पुल रिक्वेस्ट्स एंड कोड रिव्यू देखें, यह मुफ़्त है!
यहाँ भी प्रकाशित किया गया है.