Google द्वारा कोड की समीक्षा कैसे करें

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

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

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

मूल लेख में प्रयुक्त शब्द:

सीएल - चेंजलिस्ट। लेकिन आमतौर पर इसे मर्ज रिक्वेस्ट या पुल रिक्वेस्ट कहा जाता है, इसलिए लेख में मैं संक्षिप्त नाम MR का उपयोग करूंगा

LGTM - मुझे अच्छा लगता है। संक्षेप में, जब वे "स्वीकृत" बटन दबाते हैं। मैं "aprov" शब्द का उपयोग जनता के लिए अधिक समझने योग्य के रूप में करूँगा।

आदर्शता श्री

व्यवहार में, कोई एमआर पर विचार करते समय विभिन्न चरम सीमाओं पर आ सकता है। किसी को एक पूरी टीम zadalivaet टिप्पणियों के रूप में, जब तक कि सब कुछ इस मुद्दे पर trifled है, सही किया जाता है, कोई तर्क के बारे में देखता है और "upruv" दबाता है।

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

कोई भी MR कोड को बदतर नहीं बनाना चाहिए। एकमात्र अपवाद यह है कि एमआर किसी चीज के लिए एक जरूरी फिक्स है।

टिप्पणी करने की स्वतंत्रता

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

व्यक्तिगत वरीयताओं पर तथ्य

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

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

यदि समीक्षक और MR के लेखक एक दूसरे से सहमत नहीं हैं

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

टिप्पणियों में चर्चा की गई -> व्यक्तिगत रूप से चर्चा की गई -> एक टीम में चर्चा की गई -> आगे बढ़ रही है

MR जाँच की गति

गति अत्यंत महत्वपूर्ण है। यदि आप हर कुछ दिनों में एक टिप्पणी देते हैं, तो एमआर के लेखक शिकायत करेंगे कि वे उसके साथ गलती करते हैं और उसे काम करने से रोकते हैं।

यदि एमआर की बहुत जल्दी जांच की जाती है, तो किसी भी टिप्पणी से कोई बड़ी समस्या नहीं होगी - आखिरकार, उनके सुधार यहां जांचे जाएंगे, और कार्य चल जाएगा।

Google आपको सलाह देता है कि आप अपने कार्य पर ध्यान केंद्रित करने से विचलित न हों, लेकिन यदि आप विचलित हैं, तो देखें कि संशोधित करने के लिए कुछ है या नहीं। उदाहरण के लिए, वह दोपहर के भोजन से लौटा - उसने संशोधित किया। काम करने के लिए आया - संशोधित। आदि

एमआर देखने का आदेश

पहले आपको एमआर को समग्र रूप से देखना होगा। क्या यह आवश्यक है, सही जगह पर कोड है (या यह एक अलग पुस्तकालय में होना चाहिए), क्या कोई वैश्विक समस्याएं हैं।
यानी कुछ कार्यान्वयन विवरणों को देखने का कोई मतलब नहीं है अगर कोड नहीं है और बिल्कुल नहीं है।

सामान्य तौर पर, लेखक को जल्द से जल्द प्रतिक्रिया देने के लिए देखने का क्रम महत्वपूर्ण है (पिछले पैराग्राफ देखें)।

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

फिर से, किसी भी समस्या को तुरंत रिपोर्ट किया जाना चाहिए, भले ही आपने अभी तक एमआर का निरीक्षण नहीं किया हो और आम तौर पर बाद में निरीक्षण करने का फैसला किया हो।

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

देखने पर क्या देखना है

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

टू बिग एमआर

बहुत बड़े एमआर को तोड़ने का अनुरोध किया जाना चाहिए। यह लगभग हमेशा संभव है।

कोड समीक्षा पर टिप्पणियाँ कैसे लिखें

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

अगर आप अपनी राय से सहमत नहीं हैं

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

लेखक एमआर को परेशान करने का डर

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

"मैं इसे बाद में ठीक कर दूंगा।"

यदि डेवलपर सहमत है कि कोड में कोई समस्या है, लेकिन एमआर के लिए पूछता है, यह वादा करते हुए कि वह इसे दूसरी बार ठीक करेगा, तो, Google से लोगों की राय में, यह "बाद में" सबसे अधिक बार कभी नहीं होता है। इसलिए, यदि एमआर कुछ जरूरी बगफिक्स नहीं है, तो आपको एक फिक्स पर जोर देने की आवश्यकता है।

निष्कर्ष

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

यदि यह लेख पाठकों के लिए दिलचस्प लगता है और कई फायदे उठाता है, तो मैं निम्नलिखित भाग लिखूंगा: लेखक एमआर द्वारा कोड समीक्षा प्रक्रिया।

अद्यतन: यहाँ लेख का दूसरा भाग

साथ ही, जिंक सेल के आगामी अंक में, हम विभिन्न कोणों से समीक्षा कोड के बारे में विस्तार से चर्चा करेंगे। तो हमारे विकास पॉडकास्ट की सदस्यता सुनिश्चित करें!