समीक्षा कम करें।
केंद्रित रहना मुश्किल है, खासकर कोड समीक्षा के दौरान, लंबे समय तक। इसके अलावा, लंबी कोड समीक्षाएं या तो संकेत दे सकती हैं कि कोड पर कहने के लिए बहुत कुछ है (अगले दो बिंदु देखें) या कि समीक्षा बड़े मुद्दों पर चर्चा बन जाती है, जैसे कि वास्तुकला।
साथ ही, एक समीक्षा एक समीक्षा बनी रहनी चाहिए, चर्चा नहीं। इसका मतलब यह नहीं है कि कोड का लेखक जवाब नहीं दे सकता है, लेकिन उसे विचारों के लंबे आदान-प्रदान में नहीं बदलना चाहिए।
बहुत खराब है जो कोड की समीक्षा से बचें।
निम्न गुणवत्ता कोड की समीक्षा करना समीक्षक और कोड के लेखक दोनों के लिए निराशाजनक है। यदि कोड का एक टुकड़ा भयानक है, तो एक कोड समीक्षा उपयोगी नहीं है। इसके बजाय, लेखक को कोड को फिर से लिखने के लिए कहा जाना चाहिए।
समीक्षा से पहले स्वचालित चेकर्स का उपयोग करें।
स्वचालित चेकर्स गलतियों को इंगित करने में समय बर्बाद करने से बचते हैं जो स्वचालित रूप से मिल सकते हैं। उदाहरण के लिए, सी # कोड के लिए, स्टाइलकॉप, कोड मेट्रिक्स और विशेष रूप से कोड विश्लेषण चलाने के लिए समीक्षा से पहले कुछ त्रुटियों को खोजने का एक अच्छा अवसर है। फिर, कोड की समीक्षा उन बिंदुओं पर खर्च की जा सकती है जो मशीन के लिए करना बहुत कठिन है।
समीक्षा करने वाले व्यक्तियों को ध्यान से चुनें।
दो व्यक्ति जो एक-दूसरे को सहन नहीं कर सकते, वे एक दूसरे के कोड की अच्छी समीक्षा नहीं करेंगे। एक ही समस्या तब उत्पन्न होती है जब एक व्यक्ति दूसरे का सम्मान नहीं करता (चाहे वह समीक्षक हो या लेखक, वैसे)।
साथ ही, कुछ लोग अपने कोड की समीक्षा करने में असमर्थ हैं, इसलिए उन्हें यह समझने के लिए विशिष्ट प्रशिक्षण और तैयारी की आवश्यकता है कि उनकी आलोचना नहीं की जाती है और उन्हें इसे कुछ नकारात्मक के रूप में नहीं देखना चाहिए। एक समीक्षा करना, बिना तैयारी के, मदद नहीं करेगा, क्योंकि वे हमेशा रक्षात्मक रहेंगे और अपने कोड के किसी भी आलोचक को नहीं सुनेंगे (हर सुझाव को एक आलोचना के रूप में लें)।
अनौपचारिक और औपचारिक समीक्षा दोनों करें।
एक चेकलिस्ट होने से दोषों के एक सटीक सेट पर ध्यान केंद्रित करने में मदद मिलती है, नाइट पिकिंग में विकसित होने से बचा जाता है। इस चेकलिस्ट में ऐसे बिंदु हो सकते हैं जैसे:
- एसक्यूएल इंजेक्षन,
- किसी भाषा के बारे में गलत धारणाएँ जिससे त्रुटियाँ हो सकती हैं,
- विशिष्ट परिस्थितियां जो त्रुटियों को जन्म दे सकती हैं, जैसे कि ऑपरेटर पूर्ववर्तीता। उदाहरण के लिए, C # में,
var a = b ?? 0 + c ?? 0;किसी ऐसे व्यक्ति के लिए ठीक लग सकता है जो शून्य पर दो नगण्य संख्याओं को जोड़ना चाहता है, लेकिन ऐसा नहीं है।
- स्मृति का बहिष्कार,
- आलसी लोडिंग (अपने दो जोखिमों के साथ: एक ही चीज़ को एक से अधिक बार लोड करना, और उसे लोड न करना),
- अतिप्रवाह,
- डेटा संरचनाएं (एक हैश सेट के बजाय एक साधारण सूची जैसी त्रुटियों के साथ, उदाहरण के लिए),
- इनपुट सत्यापन और रक्षात्मक प्रोग्रामिंग सामान्य तौर पर,
- धागा सुरक्षा,
- आदि।
मैं यहां सूची को रोकता हूं, लेकिन एक सटीक लेखक के कमजोर बिंदुओं के आधार पर, सैकड़ों बिंदु हैं जो एक चेकलिस्ट में अंकित हो सकते हैं।
उत्तरोत्तर चेकलिस्ट समायोजित करें।
समय के साथ रचनात्मक और उपयोगी रहने के लिए, औपचारिक समीक्षाओं में उपयोग किए गए चेकलिस्ट को समय के साथ समायोजित किया जाना चाहिए, जो गलतियां पाई जा रही हैं। उदाहरण के लिए, पहले अनौपचारिक समीक्षाएं एसक्यूएल इंजेक्शन के जोखिमों की एक निश्चित राशि को प्रकट कर सकती हैं। SQL इंजेक्शन जाँच चेकलिस्ट में शामिल किया जाएगा। जब, कुछ महीनों बाद, ऐसा प्रतीत होता है कि लेखक अब गतिशील बनाम पैरामीरिज्ड प्रश्नों के बारे में बहुत सावधान है, तो SQL इंजेक्शन को चेकलिस्ट से हटाया जा सकता है।