कोड की समीक्षा: सफल अनुभव

कोड समीक्षाओं के बारे में इंटरनेट पर एक टन जानकारी है:

• अन्य लोगों के कोड की समीक्षा कंपनी की संस्कृति को कैसे प्रभावित करती है
• नियामक सुरक्षा जाँच
• संक्षिप्त मैनुअल
• सिफारिशों की लंबी सूची
• एक पारस्परिक दृष्टिकोण से कोड की समीक्षा
• मुझे एक कोड समीक्षा की आवश्यकता क्यों है
• सिद्ध तरीके
• सिद्ध तरीकों के बारे में अधिक
• आँकड़े: कितना कोड समीक्षा कीड़े को पकड़ने में मदद करता है
• कोड समीक्षा के दौरान हुई त्रुटियों के उदाहरण

हां, निश्चित रूप से, इस विषय पर किताबें हैं। एक शब्द में, यह लेख बताता है कि कोड समीक्षा का आयोजन पलान्टिर द्वारा कैसे किया जाता है। उन संगठनों में जिनकी संस्कृति इस तरह की सहकर्मी समीक्षा को स्वीकार नहीं करती है, पहले कार्ल ई। वाइजर्स के शानदार निबंध, द कोड रिवीजन विथ ए ह्यूमन फेस को पढ़ना उपयोगी हो सकता है , और फिर इस गाइड का पालन करने का प्रयास करें।

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

• क्यों, क्या और कब हम कोड समीक्षा प्राप्त करने की कोशिश करते हैं
  
• समीक्षा के लिए कोड तैयार करना
  
• कोड समीक्षा निष्पादन
  
• कोड समीक्षा उदाहरण
  

Alconost में अनुवादित


XKCD कॉमिक 'कोड क्वालिटी', CC BY-NC 2.5 लाइसेंस के तहत नकल की जाती है

प्रेरणा

हम कोड की गुणवत्ता में सुधार करने के लिए कोड समीक्षा (आरसी) में लगे हुए हैं और इस प्रकार टीम और कॉर्पोरेट संस्कृति को सकारात्मक रूप से प्रभावित करना चाहते हैं। उदाहरण के लिए:

• कोड के लेखक प्रेरित होते हैं क्योंकि वे जानते हैं कि समीक्षकों की उनकी टीम परिवर्तनों के लिए उनके अनुरोध पर विचार करेगी: लेखक खुरदरापन को साफ करने की कोशिश करता है, कार्य योजना का पालन करता है और आम तौर पर पूरी प्रतिबद्धता में सुधार करता है। जब सहकर्मी लेखन कोड में आपकी व्यावसायिकता को स्वीकार करते हैं - कई प्रोग्रामर के लिए यह खुद पर गर्व करने का एक अवसर है।
  
• ज्ञान साझा करने से विकास टीम को कई तरह से मदद मिलती है:
  

- आरके के तहत, यह स्पष्ट रूप से बताया गया है कि कार्यक्षमता का कौन सा हिस्सा जोड़ा / बदल / हटा दिया गया है ताकि भविष्य में टीम के सदस्य पहले से किए गए काम पर भरोसा कर सकें।

- कोड के लेखक एक तकनीक या एल्गोरिथ्म का उपयोग कर सकते हैं जिस पर समीक्षक खुद कुछ सीखेंगे। कुल मिलाकर, एक कोड समीक्षा पूरे संगठन में गुणवत्ता के लिए बार बढ़ाने में मदद करती है ।

- समीक्षकों को प्रोग्रामिंग तकनीकों या कोड बेस के बारे में कुछ पता हो सकता है जो किए गए परिवर्तनों को सुधारने या समेकित करने में मदद करेगा; उदाहरण के लिए, कोई व्यक्ति एक ही समय में एक ही अवसर को विकसित या संशोधित कर सकता है।

- सकारात्मक संपर्क और संचार टीम के सदस्यों के बीच सामाजिक संबंधों को मजबूत करता है।

• कोड आधार में स्थिरता के कारण , कोड खुद को पढ़ना और समझना बहुत आसान है। बग्स को रोकने और बसे और घुमंतू प्रोग्रामर के बीच सहयोग को बढ़ावा देना आसान है।
  
• अपनी खुद की रचना की पठनीयता का न्याय करने के लिए कोड के लेखक के लिए यह मुश्किल है, और समीक्षक के लिए यह सिर्फ आसान है, क्योंकि वह यह नहीं देखता है कि यह कोड किस संदर्भ में स्थित है। मानव-पठनीय कोड का पुन: उपयोग करना आसान है, इसमें कम कीड़े हैं, और अधिक टिकाऊ है।
  
• यादृच्छिक त्रुटियों (जैसे टाइपो), साथ ही संरचनात्मक त्रुटियों (जैसे गैर-निष्पादन योग्य कोड, तर्क या एल्गोरिदम में त्रुटि, प्रदर्शन और वास्तुकला की समस्याएं) अक्सर एक picky समीक्षक द्वारा पकड़ना बहुत आसान होता है जो पक्ष से कोड को देखता है। शोध के अनुसार, यहां तक ​​कि एक छोटी और अनौपचारिक कोड समीक्षा कोड की गुणवत्ता और बग की घटना को काफी प्रभावित करती है ।
  
• अनुपालन आवश्यकताओं और नियामक ढांचे को अक्सर अनिवार्य समीक्षा की आवश्यकता होती है। एक कोड समीक्षा आम सुरक्षा मुद्दों से बचने का एक शानदार तरीका है। यदि इस वातावरण में या इस अवसर के संबंध में सुरक्षा आवश्यकताओं को बढ़ाया जाता है, तो नियामक अधिकारियों से क्षत्रपों द्वारा समीक्षा (या यहां तक ​​कि अनुरोध) की सिफारिश की जाएगी (एक अच्छा उदाहरण OWASP गाइड है)।

क्या देखना है

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

कोड समीक्षा नियम सभी के लिए समान हैं: भले ही आप टीम के सबसे वरिष्ठ डेवलपर हों, इसका मतलब यह नहीं है कि आपके कोड को समीक्षा की आवश्यकता नहीं है। यहां तक ​​कि अगर (कभी-कभी ऐसा होता है) कोड सही है, तो समीक्षा में सलाह और सहयोग के अवसर खुलते हैं, और कम से कम, विभिन्न आधारों से कोड आधार को देखने में मदद करता है।

कब जांच करनी है?

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

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

समीक्षा के लिए कोड तैयार करना

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

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

- रीफैक्टरिंग से संबंधित परिवर्तन आमतौर पर कई फ़ाइलों में कोड की कई पंक्तियों को प्रभावित करते हैं - इसलिए, इस कोड को सावधानीपूर्वक चेक नहीं किया जाएगा। व्यवहार में अनियोजित परिवर्तन कोड आधार में लीक हो सकते हैं, और कोई भी इसे नोटिस नहीं करेगा।

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

- महंगा काम का समय जो एक व्यक्ति समीक्षा कोड खर्च करता है, उसे प्रोग्राम लॉजिक की जांच करने के लिए जाना चाहिए, न कि कोड की शैली, वाक्यविन्यास या प्रारूपण के बारे में बहस करने के लिए। हम विशेष रूप से, चेकस्टाइल , TSLint , बेसलाइन , प्रीटीयर , आदि स्वचालित उपकरणों का उपयोग करके ऐसे मुद्दों को हल करना पसंद करते हैं।

संदेश दें

निम्नलिखित एक सक्षम प्रतिबद्ध संदेश का एक उदाहरण है, जिसे व्यापक रूप से इस्तेमाल मानक के अनुसार बनाया गया है:

 ( 80 )    ,  ,   .   72 .          ,    —   .   ,       (   );     ,  rebase,    .  -   : « »,   « »   « ».      -,  , ,  git merge  git revert.      .    . 

कमिट के दौरान किए गए बदलावों का वर्णन करने की कोशिश करें, और ये बदलाव कितने सही हैं:

 > .   .    . > .  jcsv-     IntelliJ 

समीक्षकों के लिए खोजें

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

कोड समीक्षा निष्पादन

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

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

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

लक्ष्य

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

कार्यान्वयन

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

पठनीयता और शैली

• इस बारे में सोचें कि आपने इस कोड को कैसे पढ़ा। क्या आप उसकी अवधारणाओं को तेजी से समझ सकते हैं? क्या यह यथोचित रूप से निर्धारित किया गया है, चर और विधियों के नामों पर नज़र रखना आसान है? क्या मैं कई फाइलों या कार्यों पर कोड का पता लगा सकता हूं? क्या आप कभी कहीं असंगत नामकरण से परेशान थे?
  
• क्या कोड प्रसिद्ध प्रोग्रामिंग और स्टाइल दिशानिर्देशों का पालन करता है? क्या शैली, एपीआई नामकरण सम्मेलनों, आदि द्वारा पूरी परियोजना से कोड को तोड़ दिया गया है? जैसा कि ऊपर उल्लेख किया गया है, हम स्वचालित टूल का उपयोग करके शैलीगत विवादों को हल करने का प्रयास करते हैं।
  
• क्या कोड में कार्य सूचियाँ (TODOs) हैं? कार्य सूची बस कोड में जमा होती है और अंततः गिट्टी में बदल जाती है। GitHub मुद्दों या JIRA के लिए एक टिकट जमा करने के लिए लेखक को असाइन करें और TODO को एक कार्य संख्या संलग्न करें। प्रस्तावित परिवर्तन में कोई टिप्पणी कोड नहीं होना चाहिए।
  

प्रयोज्य समर्थन

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

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

सम्मान पीयर की समीक्षा की। हालाँकि प्रतिद्वंद्वी की स्थिति स्पष्ट है, आपको इस अवसर का एहसास नहीं था, और आप उसके लिए सब कुछ तय नहीं कर सकते। यदि आप कोड के बारे में एक सहकर्मी की समीक्षा करने वाली राय तक नहीं पहुंच सकते हैं, तो वास्तविक समय परामर्श की व्यवस्था करें और तीसरे व्यक्ति की राय सुनें।

सुरक्षा

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

टिप्पणियाँ: संक्षिप्त, विनम्र, प्रोत्साहन

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

सिफारिशों के बीच अंतर करने की कोशिश करें (जैसे, "सिफारिश: विधि निकालें, यह कोड को स्पष्ट करेगा"), आवश्यक परिवर्तन (जैसे, " ओवरराइड जोड़ें"), और स्पष्टीकरण या चर्चा की आवश्यकता वाले विचारों (जैसे, "क्या यह व्यवहार सही है? (यदि हां, तो कृपया तर्क बताते हुए एक टिप्पणी जोड़ें। ") समस्या के विस्तृत विवरण के लिए लिंक या पॉइंटर्स लगाने की कोशिश करें।

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

प्रतिक्रिया की समीक्षा करें

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

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

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

Tête-à-tête कोड समीक्षा

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

उदाहरण

निम्नलिखित उदाहरणों में, लिस्टिंग में समीक्षक टिप्पणी का उपयोग करके दर्ज किया गया है

 //R: ... 

असंगत नामकरण

 class MyClass { private int countTotalPageVisits; //R:    private int uniqueUsersCount; } 

असंगत विधि हस्ताक्षर

 interface MyInterface { /**  {@link Optional#empty},  s   . */ public Optional<String> extractString(String s); /**  null,  {@code s}   . */ //R:    :    // Optional<> public String rewriteString(String s); } 

पुस्तकालय का उपयोग

 //R:     MapJoiner   Guava String joinAndConcatenate(Map<String, String> map, String keyValueSeparator, String keySeparator); 

व्यक्तिगत प्राथमिकताएँ

 int dayCount; //R: :   numFoo   fooCount;   ,          

कीड़े

 //R:    numIterations+1 –    ? //    –     numIterations? for (int i = 0; i <= numIterations; ++i) { ... } 

वास्तु संबंधी विचार

 otherService.call(); //R: ,      OtherService.    ? 

अनुवादक के बारे में

लेख का अनुवाद अल्कोनोस्ट ने किया था।

Alconost 70 भाषाओं में खेल , एप्लिकेशन और साइटों को स्थानीय करता है। मूल भाषा के अनुवादक, भाषाई परीक्षण, एपीआई के साथ क्लाउड प्लेटफ़ॉर्म, निरंतर स्थानीयकरण, परियोजना प्रबंधक 24/7, स्ट्रिंग संसाधनों का कोई भी प्रारूप।

हम विज्ञापन और प्रशिक्षण वीडियो भी बनाते हैं - Google Play और ऐप स्टोर के लिए बिक्री, छवि, विज्ञापन, प्रशिक्षण, टीज़र, खोजकर्ता, ट्रेलरों के लिए।

अधिक जानकारी