Google के इंजीनियरिंग प्रथाओं के प्रलेखन सेयह मार्गदर्शिका वर्षों के अनुभव के आधार पर कोड समीक्षा करने के लिए सर्वोत्तम अभ्यास प्रदान करती है। एक साथ, वे एक दस्तावेज़ बनाते हैं, जिसे कई खंडों में विभाजित किया गया है। यह उन सभी को पढ़ने के लिए आवश्यक नहीं है, लेकिन अक्सर अपने और आपकी टीम के लिए गाइड का पूरा अध्ययन करना बेहतर होता है।
उन डेवलपर्स पर विस्तृत सलाह के
लिए CL लेखक की मार्गदर्शिका भी देखें जिनकी समीक्षा की जाती है।
कोड समीक्षा मानक
कोड समीक्षा का मुख्य उद्देश्य Google कोडबेस के निरंतर सुधार की गारंटी देना है। सभी उपकरण और प्रक्रियाएं इस लक्ष्य के लिए समर्पित हैं।
यहां कई तरह के समझौतों की जरूरत है।
सबसे पहले, डेवलपर्स को
अपनी समस्याओं को सफलतापूर्वक
हल करने में सक्षम होना चाहिए। यदि आप कभी भी एक कोड नहीं भेजते हैं, तो कोड आधार कभी नहीं सुधरेगा। इसके अलावा, यदि समीक्षक
किसी काम को बहुत जटिल करता है, तो भविष्य में, डेवलपर्स को सुधार के प्रस्ताव में कोई दिलचस्पी नहीं है।
दूसरी ओर, यह सुनिश्चित करने के लिए समीक्षक की जिम्मेदारी है कि सीएल की गुणवत्ता समय के साथ कोड आधार की समग्र गुणवत्ता को कम न करे। यह मुश्किल हो सकता है, क्योंकि अक्सर समय के साथ कोड की गुणवत्ता में मामूली कमी के कारण गिरावट होती है, खासकर अगर टीम समय सीमा से गंभीर दबाव में होती है और उसे लगता है कि उसे तकनीकी ऋण बढ़ाने का अधिकार है।
इसके अलावा, समीक्षक कोड की समीक्षा करने के लिए जिम्मेदार है। वह यह सुनिश्चित करना चाहता है कि कोड आधार सुसंगत बना रहे, समर्थित हो और
" खंड में
क्या जांचना है" अनुभाग में उल्लिखित सब कुछ मेल खाता है।
इस प्रकार, हमें कोड समीक्षा के लिए निम्नलिखित नियम एक मानक के रूप में मिलते हैं:
आमतौर पर, समीक्षकों को सीएल का समर्थन करना चाहिए जैसे ही यह राज्य में पहुंचता है जहां यह निश्चित रूप से सिस्टम कोड की समग्र गुणवत्ता में सुधार करता है, भले ही सीएल सही न हो।सभी सिद्धांतों के बीच यह
मुख्य कोड समीक्षा है।
बेशक, उसकी सीमाएँ हैं। उदाहरण के लिए, यदि CL एक फ़ंक्शन जोड़ता है जो समीक्षक सिस्टम में नहीं देखना चाहता है, तो समीक्षक निश्चित रूप से प्रतिबद्ध करने से इनकार कर सकता है, भले ही कोड अच्छी गुणवत्ता का हो।
यहाँ मुख्य बिंदु यह है कि कोई "सही" कोड नहीं है - केवल
बेहतर कोड है। समीक्षक को लेखक को हर छोटे टुकड़े को चमकाने की आवश्यकता नहीं होनी चाहिए। बल्कि, समीक्षक को प्रस्तावित परिवर्तनों के महत्व पर आगे की प्रगति की आवश्यकता को संतुलित करना चाहिए। आदर्श के लिए प्रयास करने के बजाय, समीक्षक को
निरंतर सुधार के लिए प्रयास करना चाहिए। एक प्रतिबद्धता, जो आमतौर पर प्रणाली की स्थिरता, पठनीयता और समझदारी में सुधार करती है, उसे दिनों या हफ्तों के लिए विलंबित नहीं किया जा सकता है क्योंकि यह "सही" नहीं है।
समीक्षक
हमेशा कोड को बेहतर बनाने पर कोई भी टिप्पणी छोड़ सकते
हैं , लेकिन बहुत महत्वपूर्ण बदलावों को चिह्नित नहीं किया जाना चाहिए, उदाहरण के लिए,
नाइट उपसर्ग के साथ
: ताकि लेखक को पता हो कि यह केवल एक दृष्टिकोण है जिसे वह अनदेखा कर सकता है।
नोट। इस दस्तावेज़ में कुछ भी सीएल को सही नहीं ठहराता है जो निश्चित रूप से सिस्टम कोड
की समग्र गुणवत्ता को
नीचा दिखाता है। यह केवल
आपात स्थिति में ही संभव है।
सलाह
एक कोड समीक्षा डेवलपर्स को भाषा, संरचना या सॉफ़्टवेयर डिज़ाइन के सामान्य सिद्धांतों के बारे में कुछ नया सिखाने के लिए भी महत्वपूर्ण हो सकती है। टिप्पणियों को छोड़ना हमेशा अच्छा होता है जो डेवलपर को कुछ नया सीखने में मदद करता है। ज्ञान साझा करना समय के साथ सिस्टम कोड को बेहतर बनाने में योगदान देता है। बस यह ध्यान रखें कि यदि आप विशुद्ध रूप से शैक्षिक टिप्पणी छोड़ते हैं जो यहां वर्णित मानकों को पूरा करने के लिए महत्वपूर्ण नहीं है, तो उसमें
निति उपसर्ग जोड़ें
: या अन्यथा इंगित करें कि लेखक को इसकी अनुमति देने की आवश्यकता नहीं है।
सिद्धांतों
- तकनीकी तथ्य और डेटा की राय और व्यक्तिगत प्राथमिकताएँ।
- शैली के मामलों में, पूर्ण अधिकार शैली का मार्गदर्शक है । किसी भी विशुद्ध रूप से शैलीगत विस्तार (स्थान, आदि) जो शैली गाइड में शामिल नहीं है, व्यक्तिगत प्राथमिकता का विषय है। स्टाइल को मैच करना चाहिए वह क्या है। यदि कोई पिछली शैली नहीं है, तो लेखक को स्वीकार करें।
- सॉफ्टवेयर डिजाइन के पहलू लगभग पूरी तरह से शुद्ध शैली या व्यक्तिगत पसंद की बात नहीं हैं। वे मौलिक सिद्धांतों पर आधारित हैं और इन सिद्धांतों द्वारा निर्धारित किया जाना चाहिए, न कि केवल व्यक्तिगत राय। कभी-कभी कई वैध विकल्प होते हैं। यदि लेखक (या तो डेटा का उपयोग कर या ठोस इंजीनियरिंग सिद्धांतों पर आधारित) प्रदर्शित कर सकता है कि कुछ दृष्टिकोण समान रूप से प्रभावी हैं, तो समीक्षक को लेखक की वरीयता को स्वीकार करना चाहिए। अन्यथा, चुनाव मानक विकास सिद्धांतों द्वारा निर्धारित किया जाता है।
- यदि कोई अन्य नियम लागू नहीं है, तो समीक्षक लेखक को वर्तमान कोड आधार के साथ एकरूपता का पालन करने के लिए कह सकता है, यदि यह सिस्टम की सामान्य स्थिति को खराब नहीं करता है।
संघर्ष का संकल्प
किसी भी संघर्ष में, पहला कदम हमेशा डेवलपर और समीक्षक की इच्छा होना चाहिए कि वह इस दस्तावेज़ की सामग्री और
सीएल लेखक की मार्गदर्शिका और इस
समीक्षक मार्गदर्शिका के अन्य दस्तावेजों के आधार पर एक आम सहमति पर आए।
जब आम तौर पर आम सहमति तक पहुंचना मुश्किल होता है, तो समीक्षक और लेखक के बीच एक व्यक्तिगत बैठक या वीडियो कॉन्फ्रेंस मदद कर सकता है (यदि आप करते हैं, तो भविष्य के पाठकों के लिए एक टिप्पणी में चर्चा के परिणामों को लिखना सुनिश्चित करें)।
यदि यह स्थिति को हल नहीं करता है, तो सबसे आम तरीका वृद्धि है। अक्सर इसमें टीम के साथ व्यापक चर्चा होती है, टीम लीड को आकर्षित करना, अनुचर या विकास प्रबंधक से संपर्क करना। लेखक और समीक्षक एक समझौते पर नहीं आ सकते हैं, इस तथ्य के कारण प्रतिबद्ध नहीं होने दें।
कोड में क्या जांचना है
नोट। इनमें से प्रत्येक आइटम पर विचार करते समय,
मानक कोड समीक्षा पर विचार करना सुनिश्चित
करें ।
डिज़ाइन
कोड समीक्षा में समग्र परियोजना (डिजाइन) पर विचार करना सबसे महत्वपूर्ण है। क्या कोड के अलग-अलग हिस्सों के बीच बातचीत से समझ में आता है? क्या यह परिवर्तन आपके कोडबेस या लाइब्रेरी पर लागू होता है? क्या सीएल बाकी सिस्टम के साथ अच्छी तरह से एकीकृत होता है? क्या अब इस कार्यक्षमता को जोड़ने का समय है?
कार्यक्षमता
क्या यह सीएल करता है जो डेवलपर का इरादा है? क्या यह इस कोड के उपयोगकर्ताओं के लिए अच्छा है? "उपयोगकर्ताओं" से हमारा मतलब है कि दोनों अंतिम उपयोगकर्ता (यदि वे परिवर्तन से प्रभावित हैं) और डेवलपर्स (जिन्हें भविष्य में इस कोड का "उपयोग" करना होगा)।
असल में, हम उम्मीद करते हैं कि कमिट करने से पहले भी, डेवलपर्स सही तरीके से काम करने के लिए अपने कोड का अच्छी तरह से परीक्षण करेंगे। लेकिन एक समीक्षक के रूप में, आपको अभी भी चरम मामलों के बारे में सोचने की जरूरत है, समवर्ती समस्याओं की तलाश करें, एक उपयोगकर्ता के रूप में सोचने की कोशिश करें, और यहां तक कि कोड को पढ़ते समय देखें कि कोई स्पष्ट त्रुटियां नहीं हैं।
यदि आप चाहें, तो आप प्रदर्शन की जांच कर
सकते हैं । यह सबसे महत्वपूर्ण है यदि कोड उपयोगकर्ताओं को प्रभावित करता है, जैसे
कि यूआई बदलना । यह समझना मुश्किल है कि जब आप कोड पढ़ते हैं तो कुछ परिवर्तन उपयोगकर्ताओं को कैसे प्रभावित करेंगे। इस तरह के बदलावों के लिए, आप डेवलपर को एक डेमो प्रदान करने के लिए कह सकते हैं यदि आपके लिए कोड में तल्लीन करना बहुत मुश्किल है और इसे स्वयं आज़माएँ।
एक अन्य बिंदु जब कोड की समीक्षा के दौरान कार्यक्षमता के बारे में सोचना विशेष रूप से महत्वपूर्ण है यदि सीएल में किसी प्रकार की
समानांतर प्रोग्रामिंग होती है, जो सैद्धांतिक रूप से गतिरोध या दौड़ की स्थिति पैदा कर सकती है। इस तरह की समस्याओं को केवल कोड चलाकर पता लगाना बहुत मुश्किल है; आमतौर पर यह आवश्यक है कि कोई व्यक्ति (डेवलपर और समीक्षक दोनों) सावधानी से उन पर विचार करें और सुनिश्चित करें कि कोई समस्या पेश नहीं की गई है (ध्यान दें कि यह भी एक अच्छा कारण है कि समानता के मॉडल का उपयोग न करें जहां दौड़ की स्थिति या गतिरोध संभव है - यह कोड के माध्यम से किया जा सकता है समझने में बहुत मुश्किल या कोड की समीक्षा)।
जटिलता
क्या सीएल से अधिक जटिल होना चाहिए? इसे हर स्तर पर जांचें: अलग-अलग लाइनें, फ़ंक्शन, कक्षाएं। "अत्यधिक जटिलता" का मतलब आमतौर पर
पढ़ने के दौरान जल्दी से समझने में
असमर्थता है । इसका मतलब यह भी हो सकता है कि
डेवलपर्स इस कोड को कॉल या संशोधित करने की कोशिश करते समय त्रुटियों को पेश करने की अधिक संभावना रखते हैं ।
एक विशेष प्रकार की जटिलता ओवर-इंजीनियरिंग है, जब डेवलपर्स ने कोड को अधिक सार्वभौमिक बना दिया है, जो कि होना चाहिए, या कार्यक्षमता को जोड़ा है जो कि वर्तमान में सिस्टम की आवश्यकता नहीं है। समीक्षकों को ओवर-इंजीनियरिंग के बारे में विशेष रूप से सतर्क होना चाहिए। एक समस्या को हल करने के लिए डेवलपर्स को प्रोत्साहित करें, जो निश्चित रूप से अब हल होना चाहिए, बजाय एक समस्या के जिसे भविष्य में हल करने की आवश्यकता हो सकती है। प्रकट होने पर भविष्य की समस्या को हल किया जाना चाहिए, और आप भौतिक ब्रह्मांड में इसके वास्तविक रूप और आवश्यकताओं को देख सकते हैं।
परीक्षण
अनुरोध इकाई, एकीकरण, या अंत-से-अंत परीक्षण जो परिवर्तन के लिए प्रासंगिक हैं। सामान्य तौर पर, परीक्षण को उसी सीएल में उत्पादन कोड के रूप में जोड़ा जाना चाहिए यदि सीएल
आपातकाल को संभाल नहीं करता है।
सुनिश्चित करें कि परीक्षण सही, उचित और मददगार हैं। टेस्ट स्वयं परीक्षण नहीं करते हैं, और हम शायद ही कभी अपने परीक्षणों के लिए परीक्षण लिखते हैं - एक व्यक्ति को यह सुनिश्चित करना चाहिए कि परीक्षण मान्य हैं।
क्या परीक्षण वास्तव में टूटे हुए कोड पर विफल होते हैं? यदि कोड बदलता है, तो क्या झूठी सकारात्मकता होगी? क्या प्रत्येक परीक्षण सरल और उपयोगी कथन करता है? क्या परीक्षण सही तरीके से विभिन्न परीक्षण विधियों के बीच विभाजित हैं?
याद रखें कि परीक्षण कोड हैं जिनका समर्थन भी किया जाना है। उनमें जटिलता की अनुमति न दें क्योंकि यह मुख्य बाइनरी फ़ाइल का हिस्सा नहीं है।
नामांकन
क्या डेवलपर ने हर जगह अच्छे नाम चुने हैं? एक अच्छा नाम पूरी तरह से यह बताने के लिए पर्याप्त है कि तत्व क्या है या यह क्या करता है, बिना इतने लंबे समय तक कि इसे पढ़ना मुश्किल हो जाए।
टिप्पणियाँ
क्या डेवलपर ने स्पष्ट टिप्पणियां सादे भाषा में लिखी हैं? क्या सभी टिप्पणियां आवश्यक हैं? टिप्पणियां आमतौर पर उपयोगी होती हैं जब वे समझाते हैं कि कुछ कोड क्यों मौजूद हैं, और यह नहीं बताना चाहिए कि यह कोड क्या करता है। यदि कोड खुद को समझाने के लिए पर्याप्त स्पष्ट नहीं है, तो इसे सरल किया जाना चाहिए। कुछ अपवाद हैं (उदाहरण के लिए, कोड के कार्यों की व्याख्या करने वाली टिप्पणियां अक्सर नियमित अभिव्यक्तियों और जटिल एल्गोरिदम के लिए बहुत उपयोगी होती हैं), लेकिन ज्यादातर टिप्पणियां ऐसी जानकारी के लिए होती हैं जो कोड में स्वयं शामिल नहीं हो सकती हैं, उदाहरण के लिए, एक निर्णय की पुष्टि करना।
पिछले कोड में टिप्पणियों को देखने के लिए भी उपयोगी हो सकता है। शायद एक TODO है, जिसे अब हटाया जा सकता है, या एक टिप्पणी जो इस परिवर्तन को शुरू करने की अनुशंसा नहीं करती है, आदि।
ध्यान दें कि टिप्पणियां कक्षाओं, मॉड्यूल या फ़ंक्शन के लिए
प्रलेखन से अलग हैं, जो कोड के कार्य का वर्णन करता है, इसका उपयोग कैसे किया जाना चाहिए, और यह कैसे व्यवहार करता है।
शैली
हमारे पास सभी प्रमुख भाषाओं के लिए Google
शैली मार्गदर्शिकाएं हैं, और यहां तक कि अधिकांश नाबालिग भी हैं। सुनिश्चित करें कि सीएल प्रासंगिक शैली गाइड के साथ संघर्ष में नहीं है।
यदि आप कुछ तत्वों को सुधारना चाहते हैं जो स्टाइल गाइड में नहीं हैं, तो टिप्पणी पर टिप्पणी जोड़ें (
Nit :) । डेवलपर को पता चल जाएगा कि यह आपकी व्यक्तिगत टिप्पणी है, जो बाध्यकारी नहीं है। केवल अपनी व्यक्तिगत प्राथमिकताओं के आधार पर कमिट्स भेजने को ब्लॉक न करें।
लेखक को अन्य परिवर्तनों के साथ महत्वपूर्ण शैली परिवर्तनों को संयोजित नहीं करना चाहिए। इससे सीएल में बदलाव देखना मुश्किल हो जाता है, मर्ज, कोड रोलबैक और अन्य समस्याओं का कारण बनता है। उदाहरण के लिए, यदि लेखक संपूर्ण फ़ाइल को पुन: स्वरूपित करना चाहता है, तो एक सीएल में एक शैली परिवर्तन के लिए पूछें, और फिर कार्यात्मक परिवर्तनों के साथ सीएल भेजें।
प्रलेखन
यदि सीएल आउटपुट असेंबली, टेस्टिंग, इंटरैक्शन प्रक्रियाओं या कोड रिलीज़ में कुछ बदलता है, तो संबंधित दस्तावेज़ों के अपडेट की जांच करें, जिसमें README फाइलें, g3doc पृष्ठ और सभी उत्पन्न संदर्भ दस्तावेज़ शामिल हैं। यदि सीएल कोड हटाता है या इसे अप्रचलित बनाता है, तो विचार करें कि क्या दस्तावेज को भी निकालना है। यदि दस्तावेज गायब है, तो इसके निर्माण का अनुरोध करें।
हर पंक्ति
कोड में
प्रत्येक पंक्ति देखें। यद्यपि किसी भी डेटा फ़ाइल, उत्पन्न कोड, या बड़े डेटा संरचनाओं की संक्षिप्त समीक्षा की जा सकती है, लेकिन किसी व्यक्ति द्वारा लिखे गए प्रत्येक वर्ग, फ़ंक्शन या कोड ब्लॉक को ध्यान से पढ़ें, कभी भी डिफ़ॉल्ट रूप से यह नहीं मानें कि सब कुछ क्रम में है। जाहिर है, कुछ कोड दूसरे की तुलना में अधिक गहन अध्ययन के योग्य हैं - आप अपने लिए निर्णय लेते हैं, लेकिन आपको कम से कम यह सुनिश्चित होना चाहिए कि आप पूरे कोड
के संचालन को
समझते हैं ।
यदि आपके लिए कोड पढ़ना बहुत कठिन है और यह समीक्षा को धीमा कर देता है, तो आपको डेवलपर को सूचित करना चाहिए और तब तक इंतजार करना चाहिए जब तक वह जारी रखने से पहले स्पष्ट न कर दे। Google में, हम महान सॉफ़्टवेयर इंजीनियरों को नियुक्त करते हैं, और आप उनमें से एक हैं। यदि आप कोड को नहीं समझ सकते हैं, तो यह बहुत संभावना है कि अन्य डेवलपर्स नहीं कर पाएंगे। इस तरह, आप डेवलपर से स्पष्टता पूछते समय भविष्य के डेवलपर्स को भी इस कोड को समझने में मदद करते हैं।
यदि कोड समझ में आता है, लेकिन आप एक निश्चित टुकड़े का मूल्यांकन करने के लिए पर्याप्त योग्य महसूस नहीं करते हैं, तो सुनिश्चित करें कि सीएल में एक समीक्षक है जो योग्य है, विशेष रूप से जटिल समस्याओं जैसे कि सुरक्षा, संगामिति, पहुंच, अंतर्राष्ट्रीयकरण आदि के लिए।
प्रसंग
सीएल को व्यापक संदर्भ में देखना अक्सर उपयोगी होता है। आमतौर पर, एक कोड समीक्षा टूल केवल परिवर्तन की जगह के पास कुछ लाइनें दिखाता है। कभी-कभी आपको यह सुनिश्चित करने के लिए संपूर्ण फ़ाइल को देखने की आवश्यकता होती है कि परिवर्तन वास्तव में समझ में आता है। उदाहरण के लिए, आप केवल चार लाइनों को जोड़ते हैं, लेकिन यदि आप पूरी फ़ाइल को देखते हैं, तो ये चार लाइनें 50-पंक्ति विधि में हैं, जिन्हें अब वास्तव में छोटे लोगों में तोड़ना होगा।
संपूर्ण रूप से सिस्टम के संदर्भ में सीएल के बारे में सोचना भी उपयोगी है। क्या यह सिस्टम कोड की गुणवत्ता में सुधार करता है या इसे अधिक जटिल, कम परीक्षण, आदि बनाता है?
उस अपमान को स्वीकार न करें जो सिस्टम कोड को नीचा दिखाता है। अधिकांश सिस्टम कई छोटे परिवर्तनों के योग से जटिल होते हैं, इसलिए वहां भी छोटी कठिनाइयों को रोकना महत्वपूर्ण है।
एक अच्छा
यदि आप कमिट में कुछ अच्छा देखते हैं, तो डेवलपर को बताएं, खासकर जब उसने आपकी टिप्पणियों में वर्णित समस्या को सबसे अच्छे तरीके से हल किया हो। कोड समीक्षाएं अक्सर केवल बग पर ध्यान केंद्रित करती हैं, लेकिन उन्हें अच्छे अभ्यास को प्रोत्साहित और महत्व देना चाहिए। सलाह देने के दृष्टिकोण से, कभी-कभी डेवलपर को यह बताना और भी अधिक महत्वपूर्ण होता है कि उसने सही क्या किया, और न कि जहां उसने गलती की।
सारांश
कोड समीक्षा निष्पादित करते समय, सुनिश्चित करें कि:
- कोड अच्छी तरह से डिजाइन किया गया है।
- कोड उपयोगकर्ताओं के लिए कार्यक्षमता अच्छी है।
- UI में कोई भी बदलाव उचित हैं और अच्छे लगते हैं।
- कोई भी समवर्ती प्रोग्रामिंग सुरक्षित है।
- कोड से अधिक जटिल नहीं होना चाहिए।
- डेवलपर अज्ञात संभावनाओं के साथ भविष्य में क्या आवश्यक हो सकता है को लागू नहीं करता है।
- कोड उपयुक्त इकाई परीक्षणों के साथ पंक्तिबद्ध है।
- परीक्षण अच्छी तरह से डिजाइन किए गए हैं।
- डेवलपर ने हर जगह स्पष्ट नामों का उपयोग किया।
- टिप्पणियां समझने योग्य और उपयोगी हैं, और मूल रूप से इस सवाल का जवाब क्यों? लेकिन क्या नहीं ?
- कोड ठीक से प्रलेखित है (आमतौर पर g3doc में)।
- कोड हमारी शैली गाइडों का अनुपालन करता है।
समीक्षा के दौरान, कोड
की प्रत्येक पंक्ति को देखना सुनिश्चित करें,
संदर्भ को देखें , सुनिश्चित करें कि आप
कोड की गुणवत्ता में सुधार कर रहे हैं और डेवलपर्स को उस
अच्छे की प्रशंसा करें जो वे करने में कामयाब रहे।
कोड समीक्षा में सीएल नेविगेशन
सारांश
अब जब आप जानते हैं
कि कोड में क्या
जांचना है , तो कई फाइलों पर कोड समीक्षा करने का सबसे कुशल तरीका क्या है?
- क्या यह परिवर्तन समझ में आता है? क्या उसका अच्छा वर्णन है ?
- सबसे पहले सबसे महत्वपूर्ण भाग को देखें। क्या यह अच्छी तरह से डिज़ाइन किया गया है?
- बाकी सीएल को उचित क्रम में देखें।
एक कदम: पूरी प्रतिबद्ध के चारों ओर एक नज़र रखना
सीएल विवरण को देखें और यह सामान्य रूप से क्या करता है। क्या यह परिवर्तन बिल्कुल समझ में आता है? यदि इसे शुरू में नहीं लिखा जाना चाहिए था, तो कृपया इसकी व्याख्या के साथ तुरंत जवाब दें कि इसकी आवश्यकता क्यों नहीं है। जब आप इस तरह के परिवर्तन को अस्वीकार करते हैं, तो डेवलपर को प्रस्ताव देना अच्छा है कि इसके बजाय क्या करना है।
उदाहरण के लिए, आप कह सकते हैं, "लगता है कि आपने अच्छा काम किया है, धन्यवाद!" हालाँकि, हम वास्तव में FooWidget सिस्टम को हटाने जा रहे हैं, इसलिए हम अभी कोई नया बदलाव नहीं करना चाहते हैं। कैसे के बजाय आप हमारे नए BarWidget वर्ग के बारे में बता रहे हैं? "
कृपया ध्यान दें कि समीक्षक ने न केवल वर्तमान सीएल को अस्वीकार कर दिया है और एक वैकल्पिक सुझाव भी दिया है, लेकिन यह भी
विनम्रता से किया है । इस तरह का शिष्टाचार महत्वपूर्ण है क्योंकि हम दिखाना चाहते हैं कि हम एक-दूसरे का डेवलपर्स के रूप में सम्मान करते हैं, तब भी जब हम एक-दूसरे से असहमत होते हैं।
यदि आपको कुछ अवांछित सीएल प्राप्त होते हैं, तो आपको सीएल लिखते समय संचार में सुधार के लिए अपनी टीम पर विकास प्रक्रिया या बाहरी योगदानकर्ताओं के लिए प्रकाशित नियमों की समीक्षा करनी चाहिए। एक टन का काम करने से पहले लोगों को "नहीं" बताना बेहतर होगा, जिसे बहुत दूर फेंकना या फिर से लिखना होगा।
चरण दो: सीएल के मूल भागों को जानें
इस सीएल के "मुख्य" भाग का प्रतिनिधित्व करने वाली फ़ाइल या फ़ाइलों का पता लगाएँ। अक्सर सबसे तार्किक परिवर्तनों के साथ एक फ़ाइल होती है, और यह सीएल का मुख्य भाग होता है। पहले इन मुख्य भागों को देखें। यह सीएल के छोटे भागों के संदर्भ को समझने में मदद करता है, और आमतौर पर कोड समीक्षा निष्पादन को गति देता है। यदि सीएल बहुत बड़ी है, तो डेवलपर से पूछें कि पहले क्या देखना है, या उसे
सीएल को भागों में विभाजित करने के लिए कहें।
यदि आप सीएल के मुख्य भाग में गंभीर समस्याएं देखते हैं, तो आपको तुरंत इन टिप्पणियों को भेजना चाहिए, भले ही आपके पास अभी सीएल के बाकी हिस्सों को देखने का समय नहीं है। वास्तव में, बाकी कोड को देखना समय की बर्बादी हो सकती है, क्योंकि यदि समस्याएं पर्याप्त रूप से महत्वपूर्ण हैं, तो प्रश्न में कोड के कई अन्य टुकड़े गायब हो जाएंगे और कोई फर्क नहीं पड़ेगा।
दो मुख्य कारण हैं कि इन मुख्य टिप्पणियों को तुरंत भेजना कितना महत्वपूर्ण है:
- डेवलपर्स अक्सर सीएल भेजते हैं, और फिर तुरंत एक कोड समीक्षा के परिणाम की प्रतीक्षा करते हुए, उसके आधार पर एक नया काम शुरू करते हैं। यदि सीएल में गंभीर समस्याएं हैं, तो उन्हें अगले सीएल को फिर से तैयार करना होगा। समस्याग्रस्त डिजाइन के शीर्ष पर बहुत सारे अतिरिक्त काम करने से पहले त्रुटियों को जल्द से जल्द पहचानना उचित है।
- मामूली बदलावों की तुलना में बड़े बदलाव में अधिक समय लगता है। लगभग सभी डेवलपर्स की समय सीमा होती है। उनके भीतर रखने के लिए और कोड की गुणवत्ता को कम नहीं करने के लिए, किसी भी प्रमुख रिफैक्टरिंग को जल्द से जल्द शुरू करना चाहिए।
चरण तीन: उचित क्रम में शेष सीएल के माध्यम से स्क्रॉल करें।
यह सुनिश्चित करने के बाद कि पूरी तरह से सीएल के डिजाइन के साथ कोई गंभीर समस्याएं नहीं हैं, फाइलों को देखने के लिए तार्किक अनुक्रम का पता लगाने की कोशिश करें और सुनिश्चित करें कि कुछ भी याद नहीं है। आमतौर पर, जब आप मुख्य फ़ाइलों को देखते हैं, तो सबसे आसान तरीका यह है कि बस उस क्रम में बाकी के माध्यम से जाना जाए जिसमें कोड समीक्षा उपकरण उन्हें प्रस्तुत करता है। यह कभी-कभी पहले परीक्षणों को पढ़ने के लिए भी उपयोगी होता है, और फिर मुख्य कोड, क्योंकि तब आपको इस बात का अंदाजा होगा कि परिवर्तन का अर्थ क्या है।कोड की समीक्षा की गति
कोड की समीक्षा जल्दी क्यों की जानी चाहिए?
Google में, हम सहयोग की गति को अनुकूलित करते हैं , व्यक्तिगत डेवलपर्स की गति को नहीं। व्यक्तिगत कार्य की गति महत्वपूर्ण है, टीम वर्क की गति की तुलना में यह सिर्फ इतनी प्राथमिकता नहीं है ।जब आप धीरे-धीरे कोड को देखते हैं, तो कई चीजें होती हैं:- एक पूरे के रूप में टीम की गति कम हो जाती है। हां, यदि कोई व्यक्ति किसी कोड की समीक्षा के लिए जल्दी प्रतिक्रिया नहीं देता है, तो वह दूसरा काम करता है। हालांकि, टीम के बाकी हिस्सों के लिए, नई सुविधाओं और बग फिक्स दिनों, हफ्तों, या महीनों तक देरी कर रहे हैं, क्योंकि प्रत्येक सीएल एक कोड समीक्षा और एक दोहराया कोड समीक्षा की प्रतीक्षा करता है।
- -. , , . , «» . (, ), , . - .
- कोड की गुणवत्ता को नुकसान हो सकता है। कोड की समीक्षा को धीमा करने से जोखिम बढ़ जाता है जो डेवलपर्स को अच्छे सीएल के रूप में नहीं भेजेंगे जैसा कि वे हो सकते हैं। धीमी समीक्षा भी कोड क्लीनअप, रीफैक्टरिंग और मौजूदा सीएल में सुधार में बाधा डालती है।
कोड समीक्षा को जल्दी से कैसे निष्पादित करें?
यदि आप एक केंद्रित कार्य के बीच में नहीं हैं, तो आपको उसके आने के तुरंत बाद एक समीक्षा कोड बनाना चाहिए।एक व्यावसायिक दिन एक उत्तर के लिए अधिकतम समय है (यानी, अगली सुबह यह पहली बात है)।इन दिशानिर्देशों का पालन करने का मतलब है कि एक विशिष्ट सीएल को एक दिन के भीतर समीक्षा (यदि आवश्यक हो) के कई दौर प्राप्त होने चाहिए।गति और व्याकुलता
एक क्षण ऐसा होता है जब व्यक्तिगत गति की प्राथमिकता टीम की गति से अधिक हो जाती है। यदि आप एक केंद्रित कार्य के बीच में हैं, जैसे कि कोड लिखना, कोड की समीक्षा से विचलित न हों। अध्ययनों से पता चला है कि एक डेवलपर को व्याकुलता के बाद एक चिकनी विकास प्रवाह पर लौटने में लंबा समय लग सकता है। इस प्रकार, कोडिंग से व्याकुलता वास्तव में टीम के एक और डेवलपर से कोड समीक्षा के लिए थोड़ा इंतजार करने की तुलना में अधिक खर्च होती है।इसके बजाय, अपने काम में एक ब्रेकपॉइंट की प्रतीक्षा करें। उदाहरण के लिए, वर्तमान कार्य को पूरा करने के बाद, दोपहर के भोजन के बाद, एक बैठक से वापस आना, एक कार्यालय पाकगृह से वापस आना, आदि।त्वरित जवाब
जब हम कोड की समीक्षा गति के बारे में बात करते हैं, तो हम प्रतिक्रिया समय में रुचि रखते हैं , और पूरी प्रक्रिया के अंत तक कितना समय आवश्यक है। आदर्श रूप से, पूरी प्रक्रिया भी तेज होनी चाहिए, लेकिन यह और भी अधिक महत्वपूर्ण है कि व्यक्तिगत उत्तर पूरी प्रक्रिया की तुलना में जल्दी आते हैं ।भले ही पूरी कोड समीक्षा प्रक्रिया समय लेने वाली हो, लेकिन पूरी प्रक्रिया के दौरान समीक्षक की त्वरित प्रतिक्रियाओं की उपलब्धता उन डेवलपर्स के जीवन को बहुत सरल बनाती है जो "धीमी" प्रतिक्रियाओं से परेशान हो सकते हैं।यदि आप अनुरोध प्राप्त करने के तुरंत बाद पूर्ण समीक्षा के लिए बहुत व्यस्त हैं, तो आप अभी भी समय सीमा के बारे में एक संदेश के साथ जवाब दे सकते हैं या अन्य समीक्षकों को समीक्षा की पेशकश कर सकते हैं जो तेजी से प्रतिक्रिया दे सकते हैं, याकुछ प्रारंभिक सामान्य टिप्पणियां प्रदान करें (ध्यान दें: इसका कोई मतलब नहीं है कि आपको ऐसी प्रतिक्रिया भेजने के लिए भी कोडिंग को बाधित करना होगा - अपने काम में एक उचित ब्रेकपॉइंट पर प्रतिक्रिया भेजें)।यह महत्वपूर्ण है कि समीक्षक समीक्षा के लिए पर्याप्त समय व्यतीत करें और सुनिश्चित करें कि उनका "LGTM" का अर्थ है "यह कोड हमारे मानकों का अनुपालन करता है "। हालांकि, अलग-अलग जवाब अभी भी आदर्श होना चाहिए तेजी से ।समय क्षेत्रों के बीच कोड की समीक्षा
अलग-अलग समय क्षेत्रों के बीच काम करते समय, लेखक को जवाब देने की कोशिश करें, जबकि वह अभी भी कार्यालय में है। यदि वह पहले ही घर जा चुका है, तो अगले दिन कार्यालय लौटने से पहले उत्तर भेजने का प्रयास करना सुनिश्चित करें।आरक्षित LGTM
गति कारणों के लिए, कुछ परिस्थितियां हैं जिनमें समीक्षक को एलजीटीएम / अनुमोदन देना चाहिए, यहां तक कि सीएल पर असंसदीय टिप्पणियों के मामले में भी। यह किया जाता है अगर:- समीक्षक को भरोसा है कि डेवलपर शेष सभी टिप्पणियों पर ठीक से विचार करेगा।
- अन्य परिवर्तन मामूली और वैकल्पिक हैं ।
समीक्षक को यह बताना चाहिए कि इनमें से कौन सा विकल्प स्पष्ट होने पर उसका अर्थ है।डेवलपर और समीक्षक अलग-अलग समय क्षेत्रों में होने पर आरक्षित LGTM विशेष रूप से उपयोगी होते हैं, अन्यथा डेवलपर "LGTM स्वीकृत" प्राप्त करने के लिए पूरे दिन इंतजार करेगा।बड़े सी.एल.
यदि कोई आपको एक समीक्षा कोड भेजता है तो यह सुनिश्चित करता है कि जब आप इसे देख सकते हैं तो आप निश्चित नहीं हैं, तो विशिष्ट उत्तर यह होगा कि डेवलपर को सीएल को कई छोटे सीएल में विभाजित करने के लिए कहें । यह आमतौर पर समीक्षकों के लिए संभव है और बहुत उपयोगी है, भले ही इसके लिए डेवलपर से अतिरिक्त काम की आवश्यकता हो।यदि सीएल को छोटे सीएल में नहीं तोड़ा जा सकता है और आपके पास जल्दी से यह सब देखने का समय नहीं है, तो कम से कम समग्र सीएल डिजाइन पर कुछ टिप्पणियां लिखें और उन्हें सुधार के लिए डेवलपर को वापस भेजें। एक समीक्षक के रूप में आपका एक लक्ष्य हमेशा डेवलपर को "अनलॉक" करना या उसे कोड की गुणवत्ता का त्याग किए बिना किसी भी आगे की कार्रवाई करने की अनुमति देना होना चाहिए।समय के साथ कोड की समीक्षा में सुधार हुआ
यदि आप इन सिफारिशों का पालन करते हैं और सख्ती से कोड की समीक्षा करते हैं, तो आप पाएंगे कि पूरी प्रक्रिया समय के साथ तेज और तेज हो जाती है। डेवलपर्स यह पता लगाएंगे कि उच्च-गुणवत्ता वाले कोड के लिए क्या आवश्यक है और आपको सीएल भेजते हैं जो बहुत शुरुआत से महान हैं, जिन्हें देखने के लिए कम और कम समय की आवश्यकता होती है। समीक्षक तुरंत प्रतिक्रिया देना सीखते हैं और समीक्षा प्रक्रिया में अनावश्यक देरी नहीं करते हैं। लेकिन काल्पनिक गति सुधार के लिए कोड समीक्षा मानकों या गुणवत्ता से समझौता नहीं करते - वास्तव में, आपने लंबे समय में समग्र त्वरण हासिल नहीं किया है।आपातकालीन स्थिति
ऐसी आपातकालीन स्थितियां भी होती हैं जब सीएल को पूरी कोड समीक्षा प्रक्रिया से बहुत जल्दी गुजरना पड़ता है, और जहां गुणवत्ता के सिद्धांतों को नरम करना होगा। लेकिन कृपया इस बात का वर्णन पढ़ें कि कौन सी स्थितियाँ आपातकाल के रूप में योग्य हैं और कौन सी नहीं।कोड समीक्षा में टिप्पणियाँ कैसे लिखें
सारांश
- विनम्र बनो।
- अपना तर्क स्पष्ट कीजिए।
- केवल समस्याओं को इंगित करके और डेवलपर को निर्णय लेने से स्पष्ट आदेश से बचें।
- जटिलता के लिए सरल स्पष्टीकरण के बजाय कोड को सरल बनाने या टिप्पणियों को जोड़ने के लिए डेवलपर्स को प्रोत्साहित करें।
शिष्टाचार
सामान्य तौर पर, विनम्र और सम्मानजनक होना महत्वपूर्ण है, और डेवलपर के लिए बहुत स्पष्ट और सहायक भी है जिसका कोड आप देख रहे हैं। ऐसा करने का एक तरीका यह सुनिश्चित करना है कि आप हमेशा कोड के बारे में टिप्पणी करें और डेवलपर के बारे में कभी नहीं । आपको हमेशा इस अभ्यास का पालन करने की आवश्यकता नहीं है, लेकिन जब आप कुछ अप्रिय या विवादास्पद कहते हैं, तो आपको इसका उपयोग करना होगा। उदाहरण के लिए:
बुरा: " अगर आप यह स्पष्ट है कि संगामिति का कोई फायदा नहीं है तो आपने यहां धाराओं का उपयोग क्यों किया ?"अच्छा: "यहाँ संगामिति मॉडल प्रणाली में जटिलता जोड़ता है, और मुझे कोई वास्तविक प्रदर्शन लाभ नहीं दिखता है। चूंकि कोई प्रदर्शन लाभ नहीं है, इसलिए इस कोड के लिए कई थ्रेड्स का उपयोग करने के बजाय एकल-थ्रेडेड होना सबसे अच्छा है। "कारण स्पष्ट करें
उपरोक्त "अच्छा" उदाहरण में, आप देख सकते हैं कि यह डेवलपर को यह समझने में मदद करता है कि आप अपनी टिप्पणी क्यों कर रहे हैं। आपको हमेशा इस जानकारी को अपनी टिप्पणियों में शामिल करने की आवश्यकता नहीं है, लेकिन कभी-कभी यह आपके तर्क के बारे में थोड़ा और स्पष्टीकरण देने के लिए उपयुक्त है, आपके द्वारा पालन की जाने वाली सर्वोत्तम प्रथाओं, या आपके सुझाव से कोड की गुणवत्ता में सुधार कैसे होता है।अनुदेश
सामान्य तौर पर, सुधार करना डेवलपर का कार्य है, समीक्षक का नहीं। आपको डेवलपर के लिए एक विस्तृत ड्राफ्ट समाधान विकसित करने या कोड लिखने की आवश्यकता नहीं है।हालांकि, इसका मतलब यह नहीं है कि समीक्षक यहां मदद नहीं कर सकता है। सामान्य तौर पर, समस्याओं की पहचान करने और प्रत्यक्ष सहायता प्रदान करने के बीच एक उचित संतुलन होना चाहिए। समस्याओं को इंगित करना और डेवलपर को निर्णय लेने का अवसर देना अक्सर डेवलपर को सीखने में मदद करता है और कोड समीक्षा को आसान बनाता है। यह एक बेहतर समाधान भी पैदा कर सकता है, क्योंकि डेवलपर समीक्षक की तुलना में कोड के करीब है।हालांकि, प्रत्यक्ष निर्देश, सुझाव, या यहां तक कि कोड कभी-कभी अधिक उपयोगी होते हैं। एक कोड समीक्षा का मुख्य उद्देश्य सबसे अच्छा संभव सीएल प्राप्त करना है। माध्यमिक लक्ष्य डेवलपर्स के कौशल में सुधार करना है ताकि समीक्षा उनके लिए कम और कम समय ले।स्पष्टीकरण स्वीकार करें
यदि आप डेवलपर को कोड के एक समझदार टुकड़े को समझाने के लिए कहते हैं, तो आमतौर पर यह इस तथ्य को जन्म देगा कि वह अधिक स्पष्ट रूप से फिर से लिखेगा । कभी-कभी एक टिप्पणी जोड़ना भी एक उचित उत्तर है, यदि यह बहुत जटिल कोड का स्पष्टीकरण नहीं है।केवल समीक्षा उपकरण में लिखे गए स्पष्टीकरण भविष्य के पाठकों की मदद नहीं करेंगे। वे केवल कुछ मामलों में स्वीकार्य हैं, उदाहरण के लिए, जब आप एक ऐसे क्षेत्र को देखते हैं जिससे आप बहुत परिचित नहीं हैं, और डेवलपर बताते हैं कि साधारण कोड पाठकों को पहले से ही क्या जानना चाहिए।कोड समीक्षा प्रक्रिया में प्रतिरोध को कैसे दूर किया जाए
कभी-कभी एक डेवलपर एक कोड समीक्षा प्रक्रिया में तर्क देता है। या तो वह आपके प्रस्ताव से सहमत नहीं है, या शिकायत करता है कि आप सामान्य रूप से बहुत सख्त हैं।कौन सही है?
जब डेवलपर आपके प्रस्ताव से सहमत नहीं होता है, तो पहले उसकी स्थिति पर विचार करने के लिए समय निकालें। अक्सर यह आपके कोड के करीब होता है और इसलिए यह वास्तव में कुछ पहलुओं का बेहतर विचार हो सकता है। क्या यह उसके तर्क में समझ में आता है? क्या यह कोड गुणवत्ता के संदर्भ में समझ में आता है? यदि ऐसा है, तो स्वीकार करें कि वह सही है, और सवाल गायब हो जाएगा।हालांकि, डेवलपर्स हमेशा सही नहीं होते हैं। इस मामले में, समीक्षक को यह स्पष्ट करना चाहिए कि वह क्यों मानता है कि उसका प्रस्ताव सही है। एक अच्छी व्याख्या डेवलपर की प्रतिक्रिया और परिवर्तन की आवश्यकता के बारे में अतिरिक्त जानकारी दोनों को समझती है।विशेष रूप से, जब समीक्षक यह मानता है कि उसके प्रस्ताव में कोड की गुणवत्ता में सुधार होगा, तो उसे इस पर जोर देना चाहिए यदि वह समझता है कि परिणामी गुणवत्ता में सुधार अतिरिक्त कार्य को सही ठहराता है। कोड की गुणवत्ता में सुधार, एक नियम के रूप में, छोटे चरणों में होता है।कभी-कभी यह वास्तव में स्वीकार किए जाने से पहले स्पष्टीकरण के कई दौर लेता है। बस यह सुनिश्चित करें कि आप हमेशा विनम्र बने रहें , और डेवलपर को बताएं कि आप इसे सुनते हैं, बस सहमत नहीं हैं।डेवलपर्स की नाराजगी के बारे में
समीक्षक कभी-कभी महसूस करते हैं कि एक डेवलपर परेशान है अगर एक समीक्षक सुधार पर जोर देता है। कभी-कभी डेवलपर्स वास्तव में परेशान होते हैं, लेकिन आमतौर पर लंबे समय तक नहीं होते हैं, और बाद में वे बहुत आभारी होंगे कि आपने उन्हें अपने कोड की गुणवत्ता में सुधार करने में मदद की। आमतौर पर, यदि आप अपनी टिप्पणियों में विनम्र हैं, तो डेवलपर्स वास्तव में बिल्कुल परेशान नहीं हैं, और चिंता केवल समीक्षक के सिर में है। टिप्पणियों की शैली आमतौर पर कोड की गुणवत्ता के बारे में समीक्षक की दृढ़ता से अधिक निराशा होती है।लंबित संपादन
विवाद का एक विशिष्ट स्रोत यह है कि डेवलपर्स (स्पष्ट कारणों के लिए) काम करना चाहते हैं। वे इस सीएल के लिए समीक्षाओं के दूसरे दौर से गुजरना नहीं चाहते हैं। इसलिए, वे कहते हैं कि वे बाद के सीएल में कुछ हटा देंगे, और अब आपको इस सीएल के लिए एलजीटीएम बनाना होगा । कुछ डेवलपर्स इसे बहुत अच्छी तरह से करते हैं, और तुरंत एक और सीएल लिखते हैं जो समस्या को ठीक कर देगा। हालांकि, अनुभव से पता चला है कि मूल सीएल के बाद जितना अधिक समय बीतता है, कम संभावना है कि यह संपादन होगा। वास्तव में, आमतौर पर अगर डेवलपर एडिटिंग तुरंत नहीं करता हैयह आमतौर पर कभी नहीं होता है। इसलिए नहीं कि डेवलपर्स गैर-जिम्मेदार हैं, बल्कि इसलिए कि उनके पास बहुत काम है, और संपादन अन्य काम के रैंप के तहत खो जाता है या भूल जाता है। इस प्रकार, यह आमतौर पर कमिट कोडबेस में जाने से पहले एक तत्काल फिक्स पर जोर देने के लिए सबसे अच्छा है और "पूरा" है। लंबित संपादन अनुमति दें कोड आधारों को पतित करने का एक विशिष्ट तरीका है।यदि सीएल एक नई जटिलता का परिचय देता है, तो इसे भेजने से पहले तय किया जाना चाहिए, अगर यह आपातकाल नहीं है। यदि सीएल अन्य समस्याओं को दिखाता है जो अभी हल नहीं किया जा सकता है, तो डेवलपर को ट्रैकर में एक बग दर्ज करना चाहिए और इसे खुद को असाइन करना चाहिए ताकि वह खो न जाए। वह इस त्रुटि के संबंध में कोड में TODO टिप्पणी को वैकल्पिक रूप से लिख सकता है।गंभीरता की सामान्य शिकायतें
यदि आप एक सतही कोड की समीक्षा करते थे, और सख्त मोड पर स्विच करते थे, तो कुछ डेवलपर्स बहुत जोर से शिकायत करना शुरू कर देंगे। बढ़ी हुई कोड समीक्षा गति आमतौर पर इन शिकायतों का समाधान करती है।कभी-कभी शिकायतों को गायब होने में महीनों लग सकते हैं, लेकिन अंत में, डेवलपर्स सख्त कोड समीक्षाओं के मूल्य को देखते हैं क्योंकि वे देखते हैं कि कोड कितना महान है। कभी-कभी सबसे जोर से विरोध करने वाले भी आपके सबसे मजबूत समर्थक बन जाते हैं जब कुछ ऐसा होता है जो उन्हें वास्तव में कठोर समीक्षाओं का मूल्य दिखाई देता है।संघर्ष का संकल्प
यदि आप उपरोक्त सभी कर रहे हैं, लेकिन अभी भी संघर्ष का सामना कर रहे हैं, तो सिफारिशों और सिद्धांतों के लिए कोड समीक्षा मानक अनुभाग देखें जो संघर्ष को हल करने में मदद कर सकते हैं।