पहले क्या आना चाहिए: परीक्षण या कोड की समीक्षा?

25

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

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

किस दृष्टिकोण की सिफारिश की जाती है और क्यों?

testing code-reviews

— सिल्वर लाइट
स्रोत

1

ध्यान दें कि प्रश्न इन चरणों के अनुक्रम के बारे में है, न कि उन्हें बिल्कुल भी प्रदर्शन किया जाना चाहिए

— रिक्लेव

8

यदि आप जहां TDD का उपयोग कर रहे हैं तो आपके प्रश्न का कोई मतलब नहीं होगा।

— एडवर्ड स्ट्रेंज

यह भी देखें कि क्या समीक्षकों को समीक्षा के भाग के रूप में कोड परीक्षण करना चाहिए?

— ग्नत

40

डेवलपर इकाई परीक्षण पहले, फिर कोड समीक्षा, फिर क्यूए परीक्षण यह है कि मैं इसे कैसे करता हूं। कभी-कभी कोड की समीक्षा इकाई परीक्षण से पहले होती है, लेकिन आमतौर पर केवल जब कोड समीक्षक को वास्तव में दलदल होता है और केवल यही समय होता है या वह ऐसा कर सकता है।

— HLGEM
स्रोत

1

यह एक अच्छा तरीका है। बस यह जोड़ना चाहते हैं कि कोड की समीक्षा करने के लिए भी मूल्यवान है (मुख्य रूप से कवरेज अंतराल के लिए)।

— केविन ह्स

@KevinHsu, उत्कृष्ट बिंदु

— HLGEM

15

उत्पाद के QA में जाने से पहले हमारा मानक कोड की समीक्षा करना है। इसका कारण यह है कि एक बार उत्पाद का परीक्षण और सत्यापन हो जाने के बाद, रिफैक्टिंग करने के लिए कम प्रोत्साहन मिलता है और अन्यथा कोड इंटर्नल्स को संशोधित किया जाता है। इसके बाद सभी को सेवानिवृत्त होना होगा। ध्यान दें कि हम ज्यादातर मामलों में इकाई परीक्षण भी करते हैं।

— मार्सी
स्रोत

8

आदर्श रूप से, एक चुस्त दुनिया में, दोनों :)

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

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

6

कोड की समीक्षा उन चीजों को "पॉलिश" करने के लिए की जाती है जो पहले से ही काम करती हैं, यह सुनिश्चित करने के लिए कि कोड में वांछित गुणवत्ता स्तर है और कंपनी द्वारा परिभाषित कोड दिशानिर्देशों को पूरा करता है।

कोड समीक्षा भविष्य की सामान्य अनुकूलन गतिविधि के हिस्से के रूप में भी हो सकती है जहां आप रिफ्लेक्टर करते हैं और पुराने कोड में सुधार करते हैं।

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

4

पहले परीक्षण करें। अंतिम परीक्षण। परीक्षण, परीक्षण, परीक्षण

कोड की समीक्षा अच्छी-से-होती है। लेकिन मुश्किल - एक दर्दनाक प्रक्रिया हो सकती है अगर व्यक्तित्व शामिल या अलग राय।

परीक्षण बहुत स्पष्ट है: या तो यह काम करता है या यह काम नहीं करता है। तो परीक्षण, परीक्षण, परीक्षण! और यदि संभव हो तो कोड-समीक्षा करें।

— पीपी।
स्रोत

और कब सोना है?

4

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

— एथेल इवांस

1

असहमत ... कोड समीक्षा महत्वपूर्ण हैं, न केवल सूक्ष्म कीड़े खोजने के लिए, बल्कि शैली त्रुटियों की खोज के लिए, और प्रदर्शन बग जो एक अनुभवी प्रोग्रामर देख कर पता लगा सकता है, लेकिन खोजने में बहुत समय लगेगा

— अमित वाधवा

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

— HLGEM

2

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

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

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

— Cercerilla
स्रोत

2

सबसे पहले, विकसित किए जाने वाले कोड के लिए स्वचालित परीक्षण लिखें। यह सुनिश्चित करने के लिए परीक्षणों की समीक्षा करें कि सभी ज्ञात आवश्यकताओं का परीक्षण किया जा रहा है या नहीं। कोड लिखें। जितनी बार चाहें समीक्षा करें।

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

— केविन क्लाइन
स्रोत

और समीक्षा के बारे में क्या? कोड बदलने के बाद, परीक्षण के बाद (यदि त्रुटियां पाई गईं) तो इसे फिर से करना होगा।

— सिल्वर लाइट 20

2

सबसे पहले अंडा या मुर्गी कौन सी है?
निर्भर करता है।

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

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

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

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

केवल मेरे दो सेंट।

— asoundmove
स्रोत

2

केपर्स-जोन्स, जिन्होंने किसी अन्य से अधिक सॉफ्टवेयर विकास प्रक्रियाओं की परिणामी दक्षता और गुणवत्ता का अध्ययन और माप किया है, दोष हटाने की गतिविधियों के निम्नलिखित अनुक्रम की सिफारिश करते हैं :

डिजाइन निरीक्षण
कोड निरीक्षण
इकाई परीक्षण
नए फ़ंक्शन परीक्षण
प्रतिगमन परीक्षण
प्रदर्शन जांच
सिस्टम परीक्षण
बाहरी बीटा परीक्षण

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

— johnblattner
स्रोत