क्या सीनियर प्रोग्रामर्स के प्रोजेक्ट्स में कोड प्रोग्रामर के रूप में जूनियर प्रोग्रामर्स को शामिल किया जाना चाहिए?

Question

मेरी टीम के सदस्यों में से एक, एक जूनियर प्रोग्रामर, उसके अनुभव के स्तर के लिए प्रभावशाली प्रोग्रामिंग कौशल है।

और कोड समीक्षाओं के दौरान, मैं सीखने पर जोर देने में विश्वास करता हूं, गलतियों को इंगित करने में नहीं।

लेकिन क्या जूनियर प्रोग्रामर को अधिक वरिष्ठ प्रोग्रामर के लिए कोड समीक्षाओं में शामिल होना चाहिए? या कोड की समीक्षा केवल इसी अनुभव के साथ प्रोग्रामर द्वारा भाग लिया जाना चाहिए?

Comments

यह सब "जूनियर" और "वरिष्ठ" सामान क्या है? IMO, प्रोग्रामर अन्य लोगों के कोड की समीक्षा करने के लिए योग्य है या नहीं, यह योग्यता और अनुभव के अनुसार निर्धारित किया जाना चाहिए - शीर्षक नहीं ....

— एंथिल

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

— सुपरएम

लेकिन कभी-कभी यह शीर्षक एचआर राजनीति और खेलों द्वारा निर्धारित किया जाता है :)

— मिशाल फ्रैंक

क्या, वास्तव में, क्या आप "जूनियर प्रोग्रामर" से मतलब है? क्या ये लोग आवेदन में कम अनुभव या उद्योग में कम अनुभव वाले हैं? मेरे अनुभव में, किसी जूनियर कर्मचारी सदस्य को किसी दिए गए प्रोजेक्ट पर सबसे अनुभवी व्यक्ति होना संभव है क्योंकि उन्होंने इस पर सबसे लंबा या सबसे हाल ही में काम किया है।

— थॉमस ओवेन्स

@ThomasOwens, "जूनियर प्रोग्रामर" द्वारा, मेरा मतलब है कि उद्योग में कम अनुभव वाले लोग।

— एमडी महबूबुर्रहमान

Answer 1

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

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

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

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

यह वास्तव में किसी भी तरह की समीक्षा पर लागू होता है - आवश्यकताओं, डिजाइन, कोड ...

Comments

+1 के लिए "समीक्षा में आवश्यक भागीदार वे लोग होने चाहिए जो अपने शीर्षक या वरिष्ठता की परवाह किए बिना इन समस्याओं की पहचान करने के लिए सबसे उपयुक्त हों।" और उत्कृष्ट उत्तर के लिए भी।

— एमडी महबूबुर्रहमान

"कोड समीक्षा का प्राथमिक उद्देश्य दोष या संभावित समस्याओं का पता लगाना है।" पूरी तरह से असहमत। कोड-समीक्षा का प्राथमिक उद्देश्य ज्ञान-साझाकरण है; कोड-समीक्षा का दूसरा उद्देश्य एक कोडिंग मानक स्थापित करना है; समीक्षा के दौरान पाए गए किसी भी कीड़े निर्णय से अधिक भाग्य है। programmer.97things.oreilly.com/wiki/index.php/Code_Reviews

— पीडीआर

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

— थॉमस ओवेन्स

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

— pdr

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

— pdr

Answer 2

क्या वरिष्ठ प्रोग्रामरों की परियोजनाओं में जूनियर प्रोग्रामर को कोड समीक्षक के रूप में शामिल किया जाना चाहिए?

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

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

---

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

Comments

मुझे लगता है कि मौविसिल का मतलब क्या है कि सीनियर्स का कोड डराने वाला हो सकता है, न कि खुद सीनियर्स (अगर ऐसा है, तो हां, टीम के पास गंभीर समस्याएं हैं जो कोड को रिव्यू करने से ज्यादा हो जाता है)।

— यानिस

@YannisRizos - 1) मैं इसे इस तरह नहीं पढ़ता। 2) यही वह जगह है जहां "बहुत कुछ करने की उम्मीद करना नासमझी है" । यदि वरिष्ठ का कोड "डराने वाला" है, तो यह जूनियर के विकास के लिए विशेष रूप से अच्छा है कि इसे पढ़ने / समझने की कोशिश करें।

— स्टीफन C

सीखना कि कैसे वरिष्ठ प्रोग्रामर सोचते हैं कि जूनियर डेवलपर्स के लिए कोड समीक्षाओं का एक और मूल्यवान हिस्सा है। जब मैं एक जूनियर डेवलपर कोड बना रहा था तो एक बार वरिष्ठ डेवलपर ने मेरे साथ इसकी समीक्षा की।

— माइकल शॉप्सन

Answer 3

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

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

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

Comments

अब यह एक अच्छा प्रारंभिक वाक्य है।

— पीडीआर

यदि कोड अधिक उन्नत तकनीकों का उपयोग कर रहा है (जैसे सरणियों और छोरों के बजाय सेट संचालन का उपयोग कर रहा है), तो क्या होता है कि टीम में कोई व्यक्ति अपना गेम उठाता है।

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

कोड की समीक्षा करते समय यह एक अत्यंत मजबूत संकेतक होता है कि कोड को एक टिप्पणी या दो की आवश्यकता होती है यदि किसी को यह पूछना पड़ता है कि कोड का एक विशेष टुकड़ा क्या करता है।

— ब्रायन एंडरसन

Answer 4

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

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

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

Answer 5

जूनियर्स को अक्सर कोड को बनाए रखने के लिए कहा जाएगा, यह महत्वपूर्ण है कि वे इसे समझ सकें।

कई बार वरिष्ठ डेवलपर्स के कोड की समीक्षा करने के लिए जूनियर्स ही उपलब्ध होते हैं। क्या QA पर जाने के लिए कोड का इंतजार करना चाहिए (हम कोड समीक्षा के बिना देव से बाहर कुछ भी नहीं करते हैं और मैं इस प्रकार की कोड समीक्षा भी कर रहा हूं) क्योंकि वरिष्ठ बॉस छुट्टी पर हैं?

मैंने विशेष रूप से जूनियर्स को कुछ समीक्षा करने के लिए कहा है जब मुझे पता था कि वे शीघ्र ही एक अलग ग्राहक के लिए कुछ ऐसा ही करेंगे या अगर मुझे पता था कि उन्होंने कुछ और काम किया है जो समान था या उनके पास एक विशेष कौशल सेट था।

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

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

मुझे लगता है कि समीक्षा में जूनियर शामिल होने के कई अच्छे प्रभाव हैं। पहले यह उन्हें और अधिक आश्वस्त करता है जब वे किसी वरिष्ठ व्यक्ति के कोड को समझ सकते हैं। यह उन्हें और भी आश्वस्त करता है जब वे उस कोड में बग ढूंढ सकते हैं।

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

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

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

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

Answer 6

मेरा उत्तर है: कभी-कभी । यह प्रोग्रामर से प्रोग्रामर और कार्य से कार्य के लिए अलग-अलग हो रहा है।

के लिये:

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

विरुद्ध:

• समीक्षाओं का जोखिम जूनियर से गैर-मुद्दों के साथ टकरा रहा है।
• आवश्यक ज्ञान / कौशल का स्तर केवल जूनियर की क्षमताओं से परे हो सकता है। यह न केवल उनका समय बर्बाद करने वाला है, बल्कि संभवत: उनका मनोबल भी बढ़ाएगा।

Answer 7

मैं एक मजबूत विश्वासी हूं कि टीम में हर किसी को कोड समीक्षाओं के दोनों पक्षों में शामिल होना चाहिए। जूनियर्स को वरिष्ठ कोड, और इसके विपरीत की समीक्षा करनी चाहिए। दोनों क्यों? क्योंकि आमतौर पर यह नहीं है कि क्या कोड "समस्या हल करता है"। मैं आपको यह नहीं बता सकता कि कितनी बार मुझे किसी को कोड का एक टुकड़ा समझाना पड़ा और अचानक स्पष्टीकरण के अंत तक इसे करने का एक बेहतर तरीका आया। कोड समीक्षाएँ शायद 3 उद्देश्यों की सेवा:

1. सुनिश्चित करें कि कोड सही है
2. लेखक इस बारे में विचार करें कि अन्य लोग अपना कोड कैसे देखेंगे
3. क्या सुधार किया जा सकता है और आंखों की एक सामान्य दूसरी जोड़ी पर पाठक की प्रतिक्रिया प्राप्त करें

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

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

Answer 8

बिल्कुल, जूनियर इंजीनियरों को वरिष्ठ इंजीनियरों के कोड की समीक्षा करनी चाहिए, कम से कम कुछ समय।

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

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

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

इन दोनों पहलुओं में, एक जूनियर समीक्षक एक वरिष्ठ से अधिक लाभान्वित होता है।

Answer 9

जूनियर प्रोग्रामर को बिल्कुल अपने वरिष्ठ सहयोगियों के लिए कोड समीक्षा करना चाहिए!

हालाँकि, उन्हें केवल समीक्षक नहीं होना चाहिए । उन्हें एक अधिक अनुभवी डेवलपर प्रति कोड समीक्षा के साथ जोड़ी।

लाभ के असंख्य हैं:

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

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

• कनिष्ठ देव बेहतर कोडिंग प्रथाओं को सीखेंगे। कोड समीक्षाएं उदाहरण के द्वारा सिखाने का अवसर हैं।

• कनिष्ठ देव एक अधिक प्रभावी कोड समीक्षक होगा। कोड की समीक्षा कठिन है । अधिक अनुभवी हर कोई कोड समीक्षाओं के साथ होता है, तेज़ और अधिक प्रभावी कोड समीक्षाएं बन जाती हैं।

• कनिष्ठ देव को कोड आधार का गहरा ज्ञान होगा। स्वार्थी हो! कनिष्ठ देवों को जल्दी खींचकर, आप इसे जल्द ही सौंप देंगे।

• कनिष्ठ देव अधिक शामिल महसूस करेंगे। जूनियर देव "सीनियर" कोड (और उनके सहयोगियों) को कम विदेशी और डराने वाले के रूप में देखना शुरू कर देंगे। यह कोड समीक्षाओं का एक जबरदस्त और अक्सर अनदेखी लाभ है।

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

• वरिष्ठ देवों को जवाबदेह ठहराया जाता है। मैंने अक्सर ऐसी स्थितियों को देखा है जहां वरिष्ठ देवता एक-दूसरे के कोड (विश्वास, आलस्य, आदि) पर चमकते हैं। आँखों का एक अतिरिक्त सेट इसे हतोत्साहित करने में मदद करता है।

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

Answer 10

कोड की समीक्षा कोड की समीक्षा के लिए की जाती है, सीखने के लिए नहीं। यदि मैं एक जूनियर प्रोग्रामर होता, तो मुझे सीनियर कोड की समीक्षा करने के लिए धमकाया जाता।

दूसरी ओर, वरिष्ठ कोड पढ़ना सीखने का एक शानदार तरीका है, बशर्ते कि वरिष्ठ सभी सवालों के जवाब देने के लिए उपलब्ध हो।

दो विकल्प हो सकते हैं:

• जूनियर्स को कोड की समीक्षा बैठकों में शामिल होने दें और प्रत्येक परिचर को कुछ शिक्षण / सीखने की चर्चाओं के लिए खुला रहने दें
• जोड़ी प्रोग्रामिंग का अभ्यास करें

Comments

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

— यानिस

ओपी ने स्पष्ट रूप से कहा कि जूनियर प्रोग्रामर में अच्छे कौशल हैं। कम अनुभव का मतलब हमेशा निम्न-गुणवत्ता कोड की समीक्षा नहीं होता है।

— Cascabel

@ जेफ्रोमी: ओपी ने स्पष्ट रूप से कहा कि वह सीखने के लिए कोड समीक्षा का उद्देश्य निर्धारित करना चाहता है। मैं सिर्फ यह कहता हूं कि यह वह नहीं है जो वे चाहते हैं।

— मौविसील

हम्म, मुझे लगता है कि हम ओपी को अलग तरह से समझते हैं - पोस्ट सीखने पर जोर देती है, लेकिन यह "कोड समीक्षकों के रूप में शामिल" भी है, यह कहते हुए कि जूनियर प्रोग्रामर एकमात्र व्यक्ति नहीं है।

— कास्काबेल