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