भाग दो Google समीक्षा कोड समीक्षा कैसे प्राप्त करें

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

चूंकि लेख को बहुत अधिक पसंद आया, इसलिए मैं कोड की समीक्षा के बारे में वादा जारी रखता हूं - कोड परिवर्तन के लेखक से

हमेशा की तरह, हम सीएल के बजाय एमआर (मर्ज अनुरोध) कहेंगे, क्योंकि कुछ लोग सीएल शब्द को समझते हैं।

Google के अनुसार MR के लेखकों के लिए मूल निर्देश यहां मिल सकते हैं , और मैं एक संक्षिप्त निचोड़ दूंगा।

तो चलिए चलते हैं

MR का विवरण

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

पहली पंक्ति (शीर्षक में) एमआर में क्या किया गया था, यह वर्णन करते हुए एक वाक्यांश होना चाहिए। इसके अलावा, परंपरा के अनुसार, एक अनिवार्य (अनिवार्य) शैली का उपयोग किया जाता है, अर्थात्। ब्लाब्लाबला हटाएं , ब्लाबलैबला नहीं हटाएं

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

"फिक्स बग" प्रकार का एक विवरण, ज़ाहिर है, अपर्याप्त माना जाता है।

एमआर जितना संभव हो उतना छोटा होना चाहिए

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

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

बेशक, कोई कठोर और तेज नियम नहीं हो सकता है, जिसे एमआर बड़ा माना जाएगा, जो छोटा। कोड की 100 लाइनें बड़ी हैं या नहीं? कौन जानता है।

• एमआर को एक काम करना होगा। आमतौर पर यह पूरी सुविधा नहीं है, लेकिन इसका हिस्सा है
• एक अलग एमआर में अलग रिफैक्टरिंग

एमआर छोटा लेकिन आत्मनिर्भर होना चाहिए

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

दिल पर मत लेना

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

यदि आप टिप्पणियों में बातचीत के लहजे की तरह नहीं हैं, तो इस व्यक्ति को ढूंढना और उससे व्यक्तिगत रूप से बात करना बेहतर है, यह समझाने के लिए कि आपको क्या पसंद नहीं है।

यदि यह मदद नहीं करता है, तो Google प्रबंधक से संपर्क करने की सलाह देता है।

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

कोड समझाएं

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

समीक्षक टिप्पणियाँ का जवाब

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

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

निष्कर्ष

सामान्य तौर पर, जैसा कि मैंने Google के एक दस्तावेज़ से समझा, एमआर के लेखक को समीक्षक को आसान बनाने के लिए सब कुछ करना चाहिए; समीक्षक को यह समझने के लिए कि कोड क्यों बनाया गया था, कोड कैसे बनाया गया था, समझने के लिए आवश्यक सभी संदर्भ होने चाहिए, आदि।

यह अवश्यंभावी है कि असहमतियों को एक विनम्र पेशेवर रूप में आम सहमति से हल किया जाएगा।

जिंक सेलिंग के अगले अंक में, हम निश्चित रूप से इस लेख (और भी बहुत कुछ) पर चर्चा करेंगे, इसलिए हमारे पॉडकास्ट की सदस्यता सुनिश्चित करें, अन्यथा मज़ेदार भाग को छोड़ दें!