कोड समीक्षा प्रक्रिया की प्रभावशीलता का निर्धारण कैसे करें?


14

हमने अपने संगठन के भीतर एक कोड समीक्षा प्रक्रिया शुरू की है और यह अच्छी तरह से काम कर रहा है। हालाँकि, मैं समय के साथ प्रक्रिया की प्रभावशीलता को मापने में सक्षम होना चाहता हूं, अर्थात क्या हम कीड़े नहीं ढूंढ रहे हैं क्योंकि कोड साफ है या लोग सिर्फ कीड़े नहीं उठा रहे हैं?

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

क्या किसी को भी इस मुद्दे पर आने से पहले या कोड समीक्षा को मापने में अच्छी तरह से काम करता है पर कोई विचार है?


7
बग ढूंढना केवल कोड समीक्षाओं का उद्देश्य नहीं है। वे कोडिंग मानकों को मजबूत करने, क्रॉस-प्रशिक्षण, विचारों और प्रौद्योगिकियों के क्रॉस-परागण, आदि के लिए भी उपयोगी हैं
जेसन

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

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

@maple_shaft: कमजोर सादृश्य। दुर्घटनाओं से मृत लोगों के लिए इस्तेमाल किए जाने वाले ताबूतों की संख्या को मापने की कोशिश करने के लिए बग दर को नापने की कोशिश करना अधिक पसंद है।
एस.लॉट

1
सभी कोड समीक्षाओं में मैंने भाग लिया है, कई कीड़े पहले से ही इकाई और उच्च-स्तरीय परीक्षण में तय किए गए हैं। यही है, कोड समीक्षा के लिए तैयार नहीं है क्योंकि यह संकलन करता है।
पीट विल्सन 20

जवाबों:


7

कई मीट्रिक हैं जिन्हें कोड समीक्षाओं से इकट्ठा किया जा सकता है, कुछ परियोजना के जीवन चक्र में भी फैली हुई हैं।

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

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

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

आप इस लेख में द गन्सल ग्रुप के निरीक्षणों और कैसरस्टॉक में कैपर्स जोन्स के एक लेख के बारे में भी दोषपूर्ण क्षमता और डीआरई के बारे में दिलचस्पी ले सकते हैं ।


2

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

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

जैसा कि आप एक औसत दर्जे की प्रभावशीलता चाहते थे - यहाँ मैं सुझाव दूंगा:

  1. पुनर्प्राप्ति की मात्रा से संबंधित मीट्रिक - एक ही दिए गए मॉड्यूल / ऑब्जेक्ट / कार्य मद में बार-बार लागू होने की संख्या मापनीयता के संदर्भ में उस कोड के खराब होने का एक उपाय है । जब प्रभावी कोड-समीक्षा लागू होती है, तो हम एक ही मॉड्यूल पर कितनी बार पुन: कार्य अनुरोध को कम करने में सक्षम होते हैं?

  2. परिवर्तन की मात्रा से संबंधित मीट्रिक जो प्रत्येक परिवर्तन अनुरोध को पूरा करता है। जब हर बार एक परिवर्तन अनुरोध होता है - एक खराब तथ्यात्मक कोड में हमेशा बड़ी संख्या में मॉड्यूल प्रभावित होंगे। एक उपाय संभवतः संकेत देगा कि कोड समीक्षा के बाद - क्या अतीत में इसी तरह के परिवर्तन अनुरोध के लिए परिवर्तन के प्रसार में कोई कमी आई थी ?

  3. औसत गति से संबंधित मीट्रिक जिसके साथ एक परिवर्तन अनुरोध का जवाब दिया जा सकता है। जब कोड क्लीनर होता है - तेज और बेहतर यह आवश्यक परिवर्तनों का जवाब देना है। समीक्षा प्रक्रिया में कोड को साफ करने के बाद, मरने के समान आकार के अनुरोध का जवाब देने में हमें कोई गति मिलती है।

मैं उपायों की सटीक इकाइयां नहीं डाल रहा हूं - आप शायद इस दृष्टिकोण से इसके बारे में अधिक सटीक उपाय तैयार कर सकते हैं। इस पर उपरोक्त दृष्टिकोण में अधिक विस्तार औपचारिकता हो सकती है।

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


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

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

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

@ डंक कोड समीक्षा की लागत कोड समीक्षा के प्रकार पर निर्भर करती है। 3-5 पाठकों, एक मॉडरेटर और लेखक की उपस्थिति के साथ एक औपचारिक निरीक्षण महंगा है (एक कमरे में 5-7 लोग)। एक डेस्क चेक जिसमें 10-15 मिनट के लिए कोड पर एक और डेवलपर glancing शामिल है, एक कोड समीक्षा भी है, लेकिन बहुत कम औपचारिक और बहुत सस्ता। यहां तक ​​कि जोड़ी प्रोग्रामिंग को "कोड समीक्षा" प्रकार की तकनीक माना जा सकता है। उपयुक्त तकनीक कोड की महत्वपूर्णता, वांछित दोष दर और निवेश किए जाने वाले समय / धन की मात्रा सहित (लेकिन सीमित नहीं) कारकों से निर्धारित होती है।
थॉमस ओवेन्स

@ डंक - मुझे लगता है कि आपने परियोजना प्रबंधक के हाथों से "हमें कोड की समीक्षा करनी चाहिए" निर्णय लेने के लिए एक तर्क दिया है, और इसे प्रबंधक के हाथों में रखा है, जिनके पास सॉफ़्टवेयर प्लेटफ़ॉर्म लॉन्ग टर्म के लिए ज़िम्मेदारी है। आईएमओ, आम तौर पर बोल रहा है, सभ्य कोड समीक्षाओं के लिए विकास पर अतिरिक्त 5-10% खर्च करना प्रणाली विकसित होने की लंबी उम्र के संदर्भ में एक सार्थक निवेश है। लेकिन शायद वर्तमान परियोजना के बजट और समय के संदर्भ में नहीं।
दाऊद इब्न करीम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.