क्या जूनियर डेवलपर्स के लिए कोड समीक्षा आवश्यक है?

39

मैंने दो कंपनियों में काम किया है, जिनके पास कोड की समीक्षा के समय एक अलग कार्यप्रणाली थी:

पहली कंपनी में, टीम के नेताओं द्वारा एक कोड समीक्षा की गई थी और हर मॉड्यूल के पूरा होने के बाद आवश्यक था।

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

इसलिए मैं उलझन में हूं। क्या कोड समीक्षा प्रक्रिया की वास्तव में आवश्यकता है? यदि है, तो क्यों? और अगर ऐसा नहीं है, तो क्यों नहीं?

code-reviews junior-programmer

— रेव्स , 4 उपयोगकर्ता 35% user8
स्रोत

28

यदि वरिष्ठ डेवलपर्स कनिष्ठ डेवलपर्स को एक निश्चित तरीके से काम करने के लिए कहते हैं, तो अक्सर एक बहुत अच्छा कारण होता है ....

2

@ टिलसन द फाइटर: यह अच्छा है कि आप सवाल पूछ रहे हैं - जिज्ञासु है, या होना चाहिए, एक प्रोग्रामर का करतब है - लेकिन कृपया उन्हें समझने और पढ़ने में आसान बनाएं।

— गैब्लिन

9

@ थोरबॉर्न - यह केवल तभी सच है जब वरिष्ठ डेवलपर्स कौशल के कारण वरिष्ठ हैं और अवधि के कारण नहीं। मैंने वरिष्ठ इंजीनियरों द्वारा बहुत बुरा कोड और डिज़ाइन देखा है

— KallDrexx

8

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

— कालड्रेक्स

4

+1 KallDrexx - यही मैंने भी पाया है। मेरे पास अक्सर एक "वरिष्ठ" डेवलपर होता है, यह नहीं जानता कि आपको सब कुछ स्थिर वर्ग में क्यों नहीं रखना चाहिए, या परीक्षण के बारे में कुछ भी पता नहीं होना चाहिए, या किसी भी उचित डिजाइन पैटर्न को जानना चाहिए .. "वरिष्ठ" आमतौर पर कार्यकाल से संदर्भित होता है और कौशल से नहीं मैं क्या बता सकता हूं।

— वेन मोलिना

107

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

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

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

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

— साइबर
स्रोत

8

Actaully, केवल टीमलीडर के पास कोड समीक्षा नहीं करने का एक बिंदु है। यहां तक कि एक कम अनुभवी डेवलपर को कोड का पालन करने में सक्षम होना चाहिए। :)

— गुफ़ा

63

टीम लीड्स को अपने कोड की भी समीक्षा करनी चाहिए, क्योंकि अक्सर जूनियर डेवलपर्स मूल्यवान तकनीक सीख सकते हैं या कम से कम यह देख सकते हैं कि "अच्छा" कोड को कैसे देखना चाहिए। और सिर्फ इसलिए कि आप एक टीम लीड हैं इसका मतलब यह नहीं है कि आप गलती नहीं कर सकते।

— TMN

4

@ टीएमएन, मैं और अधिक सहमत नहीं हो सकता। टीम लीड हमेशा अपने कौशल या अनुभव के कारण नहीं चुने जाते हैं; कभी-कभी वे सभी बड़े पैमाने पर पलायन के बाद छोड़ दिए जाते हैं (जो कि कई बार जहां मैं काम करता हूं), या एक बड़ी छंटनी हुई। सभी का कोड अनुभव, स्थिति या शीर्षक की परवाह किए बिना समीक्षा से गुजरना चाहिए।

— शयनकक्ष

2

@TMN बहुत सही। "वरिष्ठ डेवलपर" शीर्षक का अर्थ "गलतियाँ करने में असमर्थ" या "सुधार करने में असमर्थ" है। अगर ऐसा होता है, तो मैं अपनी टीम के वरिष्ठ डेवलपर की तरह नहीं हूं।

— ब्रैंडन ड्यूरेट

2

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

— डेविड थॉर्नले

37

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

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

दुर्भाग्य से बहुत कम लोग ऐसा करना चाहते हैं, लेकिन व्यवसाय की दृष्टि से देखा जाना अनिवार्य है।

— उपयोगकर्ता 1249 को प्रकट करता है
स्रोत

@ Mr.Thorbjorn रेवन एंडरसन: क्या आप कृपया बता सकते हैं कि कोड समीक्षा प्रक्रिया के फायदे और नुकसान क्या हैं?

— संकर गणेश

2

आपको इस कोड समीक्षा प्रस्ताव में रुचि हो सकती है । यह अच्छा होगा अगर हम इस पर गेंद को घुमा सकते हैं।

— महानवमी

@ विक्टर, एक दिलचस्प दृष्टिकोण और मैं आपको शुभकामनाएं देता हूं।

@Sankar गणेश: वहाँ कोड की समीक्षा के बारे में एक नि: शुल्क पुस्तक है कि चर्चा के फायदे और नुकसान: smartbear.com/best-kept-secrets-of-peer-code-review

— Joeri Sebrechts

17

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

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

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

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

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

कोड की समीक्षा के लिए सबसे अधिक प्रतिरोधी लोग अक्सर वे लोग होते हैं जिनसे संगठन को छुटकारा पाने की सबसे अधिक आवश्यकता होती है क्योंकि वे अपने दिल में जानते हैं कि उनका कोड कोड समीक्षा पारित नहीं कर सकता है।

— दर्शाता है
स्रोत

3

"हमने कोड की समीक्षा करके और अधिक महत्वपूर्ण रूप से नई हायर के साथ सक्षमता की समस्याओं को अपेक्षाकृत तेजी से पाया है कि वे कोड समीक्षा का जवाब कैसे देते हैं" - यह एक बहुत ही महत्वपूर्ण लाभ है (और मैं सहमत हूं, वे कैसे जवाब देते हैं जो वे गलतियों से अधिक बताते हैं) ।

— स्टीफन सी। स्टील

1

+1 को कैप्चर करने के लिए +1

11

फुर्तीले आदमी कहते हैं: "आपको कोड समीक्षा की आवश्यकता नहीं है, बस जोड़ी प्रोग्रामिंग करें और अच्छे परीक्षण लिखें" :)

— इलिया के।
स्रोत

9

और अक्सर जोड़े स्विच करें और यह पहचानें कि टीम, किसी व्यक्ति की नहीं, कोड का मालिक है।

— डॉन रॉबी

18

फुर्तीला आदमी गलत है। कोड की समीक्षा एक दिमाग से की जानी चाहिए जो कि मन से स्वतंत्र है (जिसने इसे बनाया है)। (यह प्रोग्रामर्स की एक जोड़ी के लिए एक दूसरे से बात करने के लिए एक अंधे गली के नीचे यह एहसास किए बिना बात करना बहुत आसान है!)

— पीटर बॉटन

6

जोड़ी प्रोग्रामिंग निरंतर कोड समीक्षा है।

3

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

— टॉम एंडरसन

2

जोड़ी प्रोग्रामिंग कोड की समीक्षाओं के साथ मुख्य समस्या को ठीक करती है - वे बहुत देर से होती हैं। मुझे यह देखने के लिए कोड समीक्षा में जाने से नफरत है कि डेवलपर ने लाइब्रेरी एल्गोरिथम या डेटा संरचना को पुनर्विकास करने में एक सप्ताह बिताया है।

— केविन क्लाइन

8

कोड समीक्षा टीम के माध्यम से ज्ञान और अच्छे अभ्यास के प्रसार का एक अच्छा तरीका है। मेरे अनुभव में यह सुनिश्चित करना एक अच्छा विचार है कि सभी कोड की समीक्षा हो जाती है, और जो कोड की समीक्षा करता है उसे अलग-अलग करने का प्रयास करें।

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

— flamingpenguin
स्रोत

2

हां, कोड समीक्षा उतनी ही गुणवत्ता नियंत्रण है जितना कि ज्ञान साझाकरण। हर कोई एक अच्छे कोड की समीक्षा से सीख सकता है। Reviwer और समीक्षक।

— Guillaume

1

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

— जिम टेक्सास में

5

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

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

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

— user6061
स्रोत

4

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

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

— ब्रैंडन ड्यूरेट
स्रोत

क्या आपके पास 8-12 बार सस्ता होने पर चर्चा करने वाला एक आधिकारिक लेख है? हम आंतरिक रूप से इस पर चर्चा कर रहे हैं।

@ Thorbjørn - हम करते हैं: goo.gl/7dMf । यह हमारी पुस्तक की कोड समीक्षा पर आता है, जिसे आप (और किसी को भी) मुफ्त में पा सकते हैं: codereviewbook.com

— ब्रैंडन ड्यूरेट

2

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

— Gratzy
स्रोत

7

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

— STW

3

@Gratzy - मैं इसके द्वारा पूरी तरह से शपथ लेता हूं; आम तौर पर यह ~% 10 को देव-चक्र में जोड़ता है; हम कितना जल्दी पकड़ते हैं, इसके लिए एक छोटा सा निवेश।

— एसटीडब्ल्यू

4

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

— STW

5

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

— पीटर बॉटन

7

बेशक वे नहीं करना चाहिए, लेकिन इसका मतलब यह नहीं है कि वे नहीं कर रहे हैं! (कितनी टीमों के पास सही डेवलपर हैं?) आप किस कोड की समीक्षा नहीं करते हैं? आप कैसे निर्णय लेते हैं कि किसी विशेष फ़ाइल में किसी विशेष परिवर्तन की समीक्षा की जानी चाहिए या नहीं?

— पीटर बॉटन

2

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

लेकिन उन कंपनियों के बारे में क्या है जो कोड की समीक्षा नहीं करते हैं? वे शायद ऐसी कंपनियां हैं जिनके पास बहुत सारी तकनीकी समस्याएं हैं और बहुत सारे हैं, जैसा कि वे उपभोक्ताओं को बताते हैं, "क्रैश" ;-)।

इसलिए मुझे आपके सभी सवालों का जवाब देना चाहिए:

हां समीक्षा प्रक्रिया आवश्यक है।
क्यूं कर? मेरे द्वारा ऊपर बताए गए कारणों की वजह से।

— गतिशील
स्रोत

2

कोड की समीक्षा : कोड समीक्षा प्रक्रिया सभी के लिए एक महत्वपूर्ण होनी चाहिए , मैं समझाऊंगा कि कोड समीक्षा के संचालन के कारण सभी को कौन से लाभ मिलते हैं और साथ ही वे कौन से लाभ प्राप्त कर रहे हैं।

1. कोड की समीक्षा के कारण कंपनी द्वारा प्राप्त लाभ: यदि बार-बार कोड की समीक्षा की जाती है, तो कंपनी अंतिम उत्पादों को बेहतर अनुकूलित तरीके से प्राप्त कर सकती है जो उन्हें अपने बाजार में ब्रांडेड नाम प्राप्त करने में मदद करते हैं और कंपनी की मदद भी करते हैं। अपने वर्तमान CMMI स्तर को प्राप्त करें या उसमें सुधार करें ।

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

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

इसलिए मेरा निष्कर्ष कोड की समीक्षा है [सभी के लिए एक बहुत ही महत्वपूर्ण प्रक्रिया है [यहां तक कि टीम के सदस्य के लिए भी], क्योंकि कोड की समीक्षा करने से हमें अपने कोड में हमारी लापरवाह गलतियों को ठीक करने में मदद मिलती है, क्योंकि हम सभी मानव प्राणी हैं, इसलिए हम यह अनुमान नहीं लगा सकते हैं कि हम कभी नहीं कोड में लापरवाह गलतियाँ करते हैं।

— शंकर गणेश
स्रोत

1

आपके कोड (समीक्षा) में जाँच करने से पहले या बाद में बग के कारण आपके विचारों में हस्तक्षेप करने में क्या अंतर है, बहुत चालाक / समझने में मुश्किल, या स्वीकृत मानक प्रथाओं का पालन नहीं करना? क्या यह आपका अहंकार है?

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

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

— JeffO
स्रोत

1

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

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

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

1

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

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

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

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

— पॉल कसाई
स्रोत

-1

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

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

— emremp
स्रोत

-1

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

— टिम क्लासन
स्रोत

-1

वे बिल्कुल आवश्यक हैं क्योंकि उनके पास बहुत कम अनुभव है।

— pacoespinoza
स्रोत

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

— gnat