जब मैं उस प्रथा से आता हूं, तो मेरी नई जगह पर कोई कोड समीक्षाओं से निपटने के लिए कैसे?

Question

मेरी नई कंपनी की टीम में कोड समीक्षा प्रक्रिया नहीं है।

मैं एक संस्कृति के रूप में कोड की समीक्षा के साथ कंपनियों से आता हूं और इस तरह मैं किसी के द्वारा समीक्षा किए बिना अपने कोड को कमिट करने में सहज महसूस नहीं करता।

मैं एक दृढ़ विश्वास है कि कोड की समीक्षा गुणवत्ता में सुधार करने और समय बचाने का एक तरीका है क्योंकि यह संभावित समस्याओं को पहले से पकड़ता है (ध्यान दें कि मैं जोड़ी प्रोग्रामिंग के बारे में बात नहीं कर रहा हूं)।

• मैं यह कैसे दिखा सकता हूं कि कोड की समीक्षा एक समय नुक़सान नहीं बल्कि एक समय बचाने वाली है?
• यदि आपके पास इकाई परीक्षण हैं तो क्या कोड की समीक्षा को छोड़ दिया जा सकता है?

Comments

ऑफ-साइट संसाधन सिफारिशें स्पष्ट रूप से सहायता केंद्र के प्रति विषय हैं । Meta.programmers.stackexchange.com/questions/6483/…

— gnat

यहाँ यह पूछने पर विचार करें: meta.codereview.stackexchange.com और मेरे दिमाग में, यह सवाल यहाँ से पूछा जा सकता है क्योंकि वह / वह सिर्फ प्रोग्रामिंग से संबंधित कुछ अवधारणा जानना चाहता है।

— xMMogvKW

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

— जोएल

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

— माइकल ड्यूरेंट

मैं यह नहीं देख सकता कि यह "ऑफ-साइट संसाधन अनुशंसा" कैसे है। यह मेरे लिए सही करीबी कारण की तरह नहीं है।

— nyuszika7h 20

Answer 1

यदि आपके पास इकाई परीक्षण हैं तो क्या कोड की समीक्षा को छोड़ दिया जा सकता है?

पर क्यों?

सहकर्मी समीक्षा की प्राथमिक भूमिका बग को पकड़ना नहीं है।

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

कोड की समीक्षा लागू करता कोड रख-रखाव , हालांकि। मैं मांग करूंगा कि उत्पादन में जाने से पहले कोड साफ और समझ में आता है (न केवल अपने लेखक के लिए)।

यूनिट परीक्षणों की उपस्थिति पूरी तरह से ऑर्थोगोनल है। आपके पास 100% कोड कवरेज हो सकता है और सभी परीक्षण पूरी तरह से समझ से बाहर कोड के लिए गुजर रहे हैं।

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

चीजों की व्यापक योजना में, एक व्यक्ति दूसरे लोगों के कोड को पढ़ने से एक डेवलपर के रूप में भी सीखता है और बढ़ता है।

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

Comments

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

— डॉक ब्राउन

@DocBrown सच है कि। हालाँकि प्रतिगमन बग्स को पकड़ना कीड़े को पकड़ने की श्रेणी में आता है, भी। जाहिर है कि यह उन फायदों में से एक है जो यूनिट परीक्षणों में सहकर्मी की समीक्षा (इस पहलू में) से अधिक है, क्योंकि वे एक-बंद ऑपरेशन नहीं हैं। सहकर्मी समीक्षा इस महत्वपूर्ण पहलू से निपटने का प्रयास भी नहीं करता है, क्योंकि यह हर एक परिवर्तन के बाद पूरे कोडबेस की पुन: समीक्षा करने के लिए संभव नहीं है।

— कोनराड मोरावस्की

@DocBrown Peer review doesn't even attempt to tackle this important aspect- ठीक है, यह करता है, की तरह। एक हद तक। मैं अक्सर अपने आप को उदाहरण के लिए इंगित करता हूं। "पार्टनर, आप यहां एक ही तर्क को प्रभावी ढंग से दोहरा रहे हैं, और वह एक टिक बम है। एक दिन यह उस दूसरी जगह को बदलने जा रहा है और हम इसे यहां अपडेट करना भूल जाएंगे ..."

— कोनराड मोरावस्की

Answer 2

क्या कोई समीक्षा और आंकड़े दिखा रहे हैं कि कोड की समीक्षा एक समय नुक़सान नहीं बल्कि एक समय बचाने वाली है?

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

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

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

यदि आपके पास इकाई परीक्षण हैं तो क्या कोड की समीक्षा को छोड़ दिया जा सकता है?

नहीं। यदि आप परीक्षणों के महत्व पर विश्वास करते हैं, तो वास्तव में आपके परीक्षणों की समीक्षा की जानी चाहिए। अगर वे बकवास कर रहे हैं तो क्या होगा? या अगर कवरेज घटिया है? या यदि वे व्यवहार के बजाय कार्यान्वयन का परीक्षण करते हैं?

Comments

मुझे लगता है कि आपने परीक्षण मामलों के लिए कोड समीक्षा पर एक वास्तविक अच्छा बिंदु बनाया है। धन्यवाद!

— जपरकोल 8

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

— डॉक्टर ब्राउन

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

— डेविड विल्किंस

"क्या होगा अगर वे बकवास कर रहे हैं? या अगर कवरेज घटिया है?" या यूँ कहें return true;।

— बुरहान अली

कोड समीक्षाओं के गहन उपचार और उनके उपयोग का समर्थन करने वाले अध्ययनों और आँकड़ों के लिए कोड 20 का अध्याय 20 पढ़ें । यहाँ कुछ अच्छे सारांश दिए गए हैं: जेफ एटवुड का ब्लॉग और दूसरा लड़का

— माइक पार्ट्रिज 18

Answer 3

मुझे मिली कुछ रैंडम स्लाइड्स से लिया गया , लेकिन स्टीव मैककॉनेल की कोड कम्प्लीट बुक से हार्ड डेटा आता है:

क्या कोड समीक्षाएं उपयोगी हैं?

"मुझे विश्वास है कि सहकर्मी कोड समीक्षाएं आपके कोड को बेहतर बनाने के लिए सबसे बड़ी चीज हैं जो आप कर सकते हैं"

जेफ एटवुड ने कोडिंग हॉरर की http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-in.html पर

---

"व्यक्तिगत निरीक्षण आमतौर पर लगभग 60 प्रतिशत दोषों को पकड़ते हैं, जो प्रोटोटाइपिंग और उच्च-मात्रा बीटा परीक्षण को छोड़कर अन्य तकनीकों से अधिक है।"

स्टीव मैककोनेल, कोड पूरा 2 संस्करण, पृष्ठ 485

यह 60% आंकड़ा आईईईई पेपर से आता है शुल एट अल 2002 हमने फाइटिंग डिफेक्ट्स के बारे में क्या सीखा है जिसमें शीर्षक शामिल है:

"सहकर्मी समीक्षाएँ 60% दोषों को पकड़ते हैं"

Comments

मुझे लगता है कि 2006 में यह समस्या है, हमने अभी तक पूरी तरह से जोड़ी प्रोग्रामिंग को अभी तक नहीं अपनाया है, जो मुझे लगता है कि एक तरह से सहकर्मी कोड समीक्षा करने के लिए प्रतिस्थापन की तरह बन गया है। मुझे लगता है कि वे कुछ मायनों में तुलनीय नहीं हैं।

— जेपी सिल्वाशी

Answer 4

अस्वीकरण: यह उत्तर मेरा व्यक्तिगत अनुभव है :)

मैंने कोड में कोड समीक्षाओं के साथ बहुत बुरे अनुभव किए जो हम बनाए रखते हैं। क्योंकि हमारे पास आमतौर पर केवल एक लाइनर या ऐसा होता है और समीक्षा करने के लिए बहुत कुछ नहीं होता है।

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

तो मैं कहूंगा कि यह इस बात पर निर्भर करता है कि आप क्या कर रहे हैं, आप कितने लोग हैं आदि।

यह भी कि एक युद्ध में आपके कोडरेव्यू समाप्त होने का जोखिम कम नहीं है।

Answer 5

आप अपने टीम लीडर और / या सहकर्मी से अपने कोड की सहकर्मी-समीक्षा करने के लिए कह सकते हैं, भले ही कोड समीक्षा सामान्य रूप से नहीं की गई हो, शायद आपके प्रशिक्षण के हिस्से के रूप में।

सुनिश्चित करें कि समीक्षा से पहले आपका कोड अच्छी तरह से लिखा और परीक्षण किया गया है।

जब मैं एक टीम लीडर था, तो मैं नए कर्मचारियों के कोड रिव्यू खुद करता था, जब तक (थोड़ी देर बाद) मैं उनके कोड में आलोचना करने के लिए बग या कुछ और ढूंढना बंद कर दूंगा, और मैं उनके साथ कोड रिव्यू करना बंद कर दूंगा; ऐसा तब होगा जब:

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

कोड समीक्षा के कई उद्देश्य हैं:

• कोड में दोषों का पता लगाना
• टीम के सदस्यों के बीच ज्ञान हस्तांतरण

मुझे लगता है कि नए कर्मचारियों की कोड समीक्षा करना ठीक है, भले ही टीम अनुभवी टीम के सदस्यों के बीच कोड की समीक्षा को छोड़ दे।

Answer 6

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

कोड समीक्षाएं आमतौर पर की जाती हैं जहां 2 से अधिक डेवलपर्स की एक टीम होती है और एक तकनीकी नेतृत्व होता है जहां तकनीकी नेतृत्व आवेदन की गुणवत्ता सुनिश्चित करना चाहता है और यह सुनिश्चित करता है कि भविष्य के संवर्द्धन के लिए आवेदन को स्केल करने और इसे अलग करने के लिए अपग्रेड करने के लिए कोड मानकों का पालन किया जाए। आगामी संस्करण।

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

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

Answer 7

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

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

यह भयानक स्थितियों से भी बचता है जहां कोड समीक्षाएं एगोस के संघर्ष की ओर ले जाती हैं - ऐसी स्थिति जहां प्रोग्रामर ए विधि एक्स का उपयोग करेगा, जबकि बी विधि वाई का उपयोग करेगा, इसलिए यदि ए वह कोड लिखता है जो विधि एक्स का उपयोग करता है, तो समीक्षक बी विधि वाई पर जोर देता है। इसलिए A विधि Y का उपयोग करते हुए कोड को फिर से लिखता है, जबकि यदि B ने कोड लिखा होता और A की समीक्षा होती तो ठीक इसके विपरीत होता।

Answer 8

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

मूल रूप से, आप जो चाहते हैं उसे प्राप्त करने के लिए, आपको एक कार्यस्थल संस्कृति परिवर्तन की आवश्यकता है - और यह कभी भी सरल या आसान नहीं है। यह मत भूलो कि भले ही आपका कार्यस्थल 100% हो, लेकिन यह माना जाता है कि कोड समीक्षाएं उत्कृष्ट हैं और वे उन्हें अपनाना चाहते हैं, वास्तव में काम करने के नए तरीके में शिफ्ट करना अभी भी समय, ऊर्जा और उत्पादकता के महत्वपूर्ण निवेश की आवश्यकता होगी। इस निवेश को खुद वापस भुगतान करना चाहिए - लेकिन आपको केवल भुगतान के लिए नहीं, बल्कि निवेश के लिए खरीदना होगा। रॉय ओशेरोव के वीडियो "यूनिट टेस्टिंग एंड टीडीडी - हाउ टू मेक इट हैपन" देखें - कोड की समीक्षा को अपनाने की चुनौतियाँ बहुत हद तक यूनिट परीक्षण को अपनाने के समान हैं।

इस बीच, वह करें जो आप कर सकते हैं जितना आप कर सकते हैं:

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

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

Answer 9

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

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

इसके बाद जांच करने से पहले सब कुछ परख लें। सबसे महत्वपूर्ण बात यह है कि यह सही तरीके से काम करता है।

Comments

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

— जोर्जेन फॉग

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

— DoubleDouble

यह संभव है कि लाभ लागत के लायक नहीं हैं। हालांकि, यह तथ्य कि टीम कोड समीक्षा नहीं करती है, हमें इस बारे में कुछ नहीं बताती है कि उन्हें क्या करना चाहिए या नहीं।

— जोर्जेन फॉग

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

— Dancrumb

Answer 10

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