क्या हमें अपने सभी कोड की समीक्षा करने का प्रयास करना चाहिए?

Question

वर्तमान में हम विकास प्रक्रिया को संशोधित कर रहे हैं और मुझे आश्चर्य हो रहा है कि क्या हमें अपने कमिटेड पीयर की 100% समीक्षा करने की कोशिश करनी चाहिए।

कोड समीक्षा के संबंध में आपका अनुभव क्या है?

• क्या आप उन पर "बहुत दिन" (प्रति दिन 1/2 घंटे), या केवल 5/10 मिनट अधिकतम के लिए स्किम करते हैं?
• क्या आपके पास प्रति दिन / सप्ताह / स्प्रिंट / परियोजना में खर्च करने के लिए एक निश्चित राशि है?
• सबसे महत्वपूर्ण बात यह है कि आपको लगता है कि लक्ष्य को 100% कोड की समीक्षा के लिए होना चाहिए या यह कि 100% आवश्यक नहीं है?

Comments

20% प्रयास के साथ 80% कोड को छूने का प्रयास करें। सबसे अच्छा स्वचालित उपकरणों में निवेश करें जो पैसे खरीद सकते हैं।

— जॉब

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

— किरेन जॉनस्टोन

Answer 1

हमारे पास प्रत्येक कहानी में एक 'कोड रिव्यू' कार्य है। कोई व्यक्ति आदर्श रूप से उस कहानी के विकास में शामिल नहीं है, उस कहानी से जुड़े सभी कोड परिवर्तनों की समीक्षा करेगा। यह अच्छा काम करता है।

बहुत समय? बहुत अधिक नहीं, इस बात पर निर्भर करता है कि हम कितना कोड - स्पष्ट त्रुटियां, टाइपोस, बुनियादी तर्क विवेक जाँच, बिना किसी अपवाद, आदि की तलाश कर रहे हैं।

यह एक गुणवत्ता वाला कदम है जो बग ढूंढता है, इसलिए इसका कुछ मूल्य है। आवंटित समय ऐसा करने का सबसे अच्छा तरीका नहीं हो सकता है - कैसे के बारे में अगर कुछ काफी जटिल है, तो इसे कोड-समीक्षा किया जाना चाहिए?

वैसे, यह महत्वपूर्ण है कि कोई और कोड समीक्षा करे ..

Comments

"वैसे, यह महत्वपूर्ण है कि कोई और व्यक्ति कोड की समीक्षा करता है ..", क्या प्रश्न का अर्थ है कि वही व्यक्ति जो कोड लिखता है वह इसकी समीक्षा करता है? अगर यह कहाँ है? मैं ठीक करना चाहूंगा :)

— शिमोन

नहीं, ऐसा नहीं है, मैं व्यापक था और कह रहा था कि यह महत्वपूर्ण है

— किरेन जॉनस्टोन

@ शिमोन वास्तव में एक सामान्य रूप से गलत धारणा है कि मालिक अपने कोड की समीक्षा कर सकते हैं। यह पूरे ऑपरेशन को कमज़ोर करता है

— टॉम स्क्वायर्स

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

— हमार

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

— पीटर अज़ताई

Answer 2

एक मुद्दा अधिक महत्वपूर्ण है कि आपके कोड को समीक्षाओं के अनुसार कितना कवर किया गया है, समीक्षा कितनी प्रभावी है। यदि आपकी समीक्षा में कुछ या कोई समस्या नहीं है, तो पूर्ण कवरेज तक पहुंचना बेकार हो जाएगा।

पहले अपनी समीक्षाओं को अधिक प्रभावी बनाने पर काम करें, फिर कवरेज पर निर्णय लें।

समीक्षा न केवल कोड पर, बल्कि डिजाइन पर भी की जानी चाहिए।

इसके अलावा, समीक्षा परीक्षणों और उपकरणों के लिए कोई प्रतिस्थापन नहीं है:

• समीक्षा सूखी कोड चला सकते हैं
• समीक्षा में कोड विश्लेषण शामिल हो सकते हैं
• समीक्षा पुन: उपयोग और पठनीयता की जांच करें
• समीक्षा दक्षता के कुछ पहलुओं की जांच कर सकती है, हालांकि, यह रन टाइम के वास्तविक माप और बोतल गर्दन की खोज को प्रतिस्थापित नहीं करता है
• स्थैतिक कोड विश्लेषण के लिए उपकरण हैं
• कोडिंग सम्मेलनों के परीक्षण के लिए उपकरण हैं, इस पर समीक्षा का समय बर्बाद न करें
• यूनिट, सिस्टम और इंटीग्रेशन टेस्ट वेट रन कोड
• इकाई, प्रणाली और एकीकरण परीक्षण परीक्षण स्वचालित रूप से दोहराया जा सकता है, कोड समीक्षा आमतौर पर एक-नापसंद होती है
• यूनिट परीक्षणों में उच्च कोड कवरेज होना चाहिए और मुख्य सफलता परिदृश्यों और अंतिम स्थितियों दोनों का परीक्षण करना चाहिए, कोड समीक्षाएं केवल आंशिक रूप से ऐसा कर सकती हैं
• एकीकरण परीक्षण इकाइयों या प्रणालियों की एक साथ काम करने की क्षमता का परीक्षण करते हैं, कोड समीक्षा इसे प्रतिस्थापित नहीं कर सकती है
• सिस्टम परीक्षण एक पूरे सिस्टम की कार्यक्षमता का परीक्षण करते हैं, कोड समीक्षा इसे प्रतिस्थापित नहीं कर सकती है

समीक्षाओं के लिए प्रति माह (या प्रति स्प्रिंट) समय की पूर्व निर्धारित राशि समर्पित करने का प्रयास करें। उस कोड का चयन करें जिसे आप अगले समर्पित स्लॉट पर समीक्षा करना चाहते हैं जैसे कि एक अनुमानी का उपयोग करके:

• कोड जिसमें अज्ञात बग हो सकता है जो रिपोर्ट किया गया था
• उस कोड के साथ हाल ही में इसके भीतर कीड़े की पहचान की गई है
• प्रदर्शन के मुद्दों के साथ कोड (बोतल गर्दन)
• नए डेवलपर्स द्वारा लिखित कोड
• लिगेसी कोड जो हाल ही में किसी व्यक्ति द्वारा अपडेट किया गया था जो पहले से परिचित नहीं था
• नए क्षेत्रों में कोड
• मौजूदा कोड जिसे आप नए डेवलपर्स के बारे में सीखना चाहते हैं
• कोड जो जटिल मुद्दों को हल करता है
• कोड जिसे विश्लेषण उपकरण द्वारा जटिल के रूप में पहचाना गया था

और याद रखें, आप कोड (या डिज़ाइन या परीक्षण) की समीक्षा कर रहे हैं और लेखकों की नहीं।

मैं निम्नलिखित पठन सामग्री की सिफारिश करता हूं:

चयनात्मक होमवर्कलेस समीक्षा
सहकर्मी कोड समीक्षा के सर्वश्रेष्ठ केप्ट सीक्रेट

Answer 3

निर्भर करता है।

यह इस बात पर निर्भर करता है कि आपका सॉफ्टवेयर क्या कर रहा है:

• यदि यह एक इलेक्ट्रॉनिक पेसमेकर या एक अंतरिक्ष यान को नियंत्रित करता है, तो निश्चित रूप से हाँ।

• यदि यह एक फेंकू प्रोटोटाइप है, तो शायद नहीं।

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

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

Answer 4

सबसे पहले, आपको इस प्रश्न का उत्तर देने की आवश्यकता है: आप कोड की समीक्षा क्यों करते हैं?

हाथ में उस उत्तर के साथ, आप यह पता लगा सकते हैं कि किस कोड की समीक्षा करने की आवश्यकता है।

कुछ कोड समीक्षाएँ वास्तव में परीक्षण क्या करता है या किया होता है। यदि वह आपकी समीक्षाओं का लक्ष्य है, तो 100% के करीब होना एक अच्छा विचार है यदि आपके पास थोड़ा परीक्षण है। हालाँकि, परीक्षण उपकरण को ऐसा करने से कोड की सभी समीक्षा की आवश्यकता कम हो जाएगी।

अधिकांश अच्छी समीक्षा ज्ञान साझा करने और समीक्षा में डेवलपर्स की क्षमताओं को बढ़ाने पर ध्यान केंद्रित करने लगती हैं (या तो कोड लिखने वाले या कोड की समीक्षा करने वाले)। समीक्षाओं के लिए एक प्राथमिक कारण के रूप में, 100% कोड की समीक्षा करना सुनिश्चित करता है शायद ओवरकिल।

Answer 5

एक आदर्श दुनिया में, सब कुछ स्पष्ट रूप से कम से कम एक अन्य व्यक्ति द्वारा समीक्षा की गई लेखक और सहकर्मी द्वारा पढ़ा जाएगा, आवश्यकताओं से लेकर उपयोगकर्ता मैनुअल से लेकर परीक्षण मामलों तक। लेकिन समीक्षा, यहां तक ​​कि सरल डेस्क की जांच, समय और लागत पैसे लेती है। इसका मतलब है कि आपको यह चुनने की आवश्यकता है कि आपको क्या समीक्षा करनी चाहिए और कब आपको इसकी समीक्षा करनी चाहिए।

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

जहां तक ​​समय है, यह सब वापस जाता है कि घटक कितना उच्च प्राथमिकता है। ऐसे समय आए हैं जहां मैंने 10-15 मिनट की समीक्षा की है, और अन्य बार जब कई लोगों ने कोड को व्यक्तिगत रूप से पढ़ा है, तब एक कमरे में जाकर एक और अधिक औपचारिक निरीक्षण प्रक्रिया हुई जो 30-45 मिनट तक रहती है (आकार के आधार पर) मॉड्यूल)।

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

Answer 6

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

सुसंगत टीमें बेहतर परियोजनाओं का निर्माण करती हैं। लोग बकवास या पूर्णता के अनुरोध पर रिश्तों को ढीला कर सकते हैं। हमेशा ऐसा होता है कि एक व्यक्ति जो इस या उसके बारे में शिकायत करेगा और दूसरों को सिर्फ इसलिए कि वह ऐसा है ...

Answer 7

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

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

Comments

क्या यह एक औसत है? एक घंटे के लिए एक जटिल समीक्षा को सीमित करना अजीब लगता है, और अगर समीक्षा करने के लिए इतना कुछ नहीं है .. तो मैं यह नहीं देख सकता कि एक दिन में एक घंटा कैसे काम करने योग्य होगा?

— कीरेन जॉनस्टोन

वह कोई सीमा नहीं है। मैंने समय को इस आधार पर निर्धारित किया कि इसमें कितना समय लगा, अन्य तरीके से नहीं। मैं आमतौर पर एक घंटे में 2 समीक्षा कर सकता हूं। यदि इससे अधिक समय लगता है, तो आपका चेक इन बहुत बड़ा है, आपको हाथ से पहले पर्याप्त डिज़ाइन समीक्षा नहीं मिल रही है, या आपके कोड समीक्षा टूल बहुत बोझिल हैं। कोड समीक्षा एक जांच है, एक नया स्वरूप नहीं है।

— कार्ल बेवलफेल्ट

Answer 8

हमने कोड के लिए 100% समीक्षाएं की हैं। यह परीक्षण की तुलना में कहीं सस्ता है, खासकर 100% कोड कवरेज परीक्षण। हम उन पर बहुत अधिक समय नहीं बिताते हैं, प्रति दिन एक घंटे से अधिक समय तक समीक्षा करना कम उत्पादक बन जाता है। (30 मिनट बहुत नहीं है)।

जैसा कि आप प्रक्रिया में शून्य कर रहे हैं, नोट रखें। आपको क्या मिला? QA ने बाद में क्या पाया? आपके ग्राहकों को क्या मिला? वे कीड़े आपसे क्यों बच गए?

Comments

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

— थॉमस ओवंस

@MSalters के दावे अनसुने नहीं हैं, हालांकि मुझे भी इसमें संदेह है कि इसमें केवल 30 मिनट लगते हैं .. मैंने केवल एक ही जगह के बारे में पढ़ा है जहां यह मामला था कि निरीक्षण स्वचालित इकाई परीक्षण की तुलना में अधिक लागत प्रभावी था और वह नासा था। उस मामले में उन्होंने अंततः यूनिट परीक्षण को पूरी तरह से गिरा दिया क्योंकि यह कोड का मैन्युअल रूप से निरीक्षण करने के लिए सस्ता था। बेशक, नासा के पास अभी भी एक 12: 1 परीक्षक: डेवलपर अनुपात था, इसलिए वे बहुत अधिक अन्य परीक्षण भी कर रहे थे ...

— माइकल

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

— MSALERS

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

— थॉमस ओवेन्स

Answer 9

नियमित रूप से टीम के निर्माण और कार्यान्वयन पर विचारों को साझा करने के लिए नियमित रूप से कोड समीक्षा करें। आप अपने सहकर्मियों से इस तरह से बहुत कुछ सीख सकते हैं।

Comments

यह केवल कुछ लाभों को इंगित करता है। क्या आपको लगता है कि त्रुटियों को ढूंढना महत्वपूर्ण है? यदि हां, तो कितना?

— जेएफओ

बेशक त्रुटियां खोजना महत्वपूर्ण हैं लेकिन बड़ा लाभ यह है कि कोड समीक्षाओं से प्राप्त दीर्घकालिक ज्ञान। शायद एक बग एक खराब दृष्टिकोण से बनाया गया था जिसे भविष्य में रोका जा सकता है

— कोडर

Answer 10

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

ये बहुत समय नहीं लेते हैं, और चूंकि वे साथियों के बीच किए जाते हैं, इसलिए उनके लिए कोई विषाक्त वयस्क-बाल पहलू नहीं है।

Answer 11

कोड की समीक्षा, IMO, जरूरत है। आप 99.999 हैं ... समय का% हमेशा सही नहीं होने वाला है, इसलिए आपको यह सुनिश्चित करने की आवश्यकता है कि यह सही है। क्या मेरे पास एक निर्धारित समय है? नहीं, लेकिन मैं अपने कोड की जांच करने के लिए समय लेता हूं। आमतौर पर मेरे पास एक सहयोगी ऐसा ही होता है।

Answer 12

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

सहकर्मी की समीक्षाओं पर कितना समय बिताने के लिए, एक अच्छा अभ्यास कोड समीक्षा के संचालन और प्रतिक्रिया के लिए आपके कुल अनुमानित विकास समय का 5-10% छोड़ने के लिए है।

हमारे पास प्रभावी कोड समीक्षा करने पर एक व्हाइटपेपर है जो आपको दाहिने पैर पर शुरू करने में मदद कर सकता है। यह एक कदम से कदम गाइड है और आम समस्याओं पर चर्चा करता है जिनका आप सामना कर सकते हैं और उन्हें कैसे हल कर सकते हैं। आप इसे हमारी वेबसाइट से डाउनलोड कर सकते हैं ।