कोड समीक्षाओं में, क्या समीक्षक को हमेशा मुद्दों का समाधान प्रस्तुत करना चाहिए? [बन्द है]

Question

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

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

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

इसलिए आम तौर पर, एक समीक्षक के रूप में, "यह कोड त्रुटिपूर्ण है, क्योंकि यह कहना ठीक है ..., क्या यह अलग है" या क्या आपको एक विशिष्ट समाधान के साथ आना है?

Comments

जब कोड समीक्षा के लिए कोड सबमिट किया जाता है तो क्या करना

— gnat

@gnat: नहीं, कोड बहुत जटिल नहीं है। और यह सिर्फ एक उदाहरण है। मैं आम तौर पर पूछ रहा हूं कि क्या समीक्षक समाधान प्रस्तुत करने के लिए जिम्मेदार है।

— फ्रैंक पफर

नहीं, मैं कहूंगा कि एक समीक्षक के रूप में आप यह बताने के लिए बाध्य नहीं हैं कि इसे कैसे सुधारें। यदि आप वर्णन कर सकते हैं कि वहां क्या गलत लगता है, तो इसे करें; यदि नहीं - बस सामान्य टिप्पणी प्रदान करें। (सबसे उपयोगी समीक्षा टिप्पणियों में से एक जो मुझे याद है, वह सचमुच "इस वर्ग का कुल कचरा है" की तरह है)

— gnat

"इसे हल करने का मानक तरीका वर्ग को विभाजित करना और विरासत का उपयोग करना होगा।" मुझे यकीन है कि आशा है कि आप मेरे कोड की समीक्षा नहीं कर रहे हैं!

— गार्डेनहेड

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

— मार्टिन माट

Answer 1

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

इन उद्देश्यों में से कुछ में आमतौर पर एक निर्णय कॉल शामिल होगा कि क्या उद्देश्य पूरा हुआ है या नहीं। उदाहरण के लिए, कोड को बनाए रखने वाले उद्देश्य को आमतौर पर एक निर्णय कॉल की आवश्यकता होती है।

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

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

Comments

एक साथ समाधान के लिए आने के लिए चर्चा के लिए +1 - यह वह तरीका है जो मैं अपने कोड की समीक्षा करने वाले वरिष्ठ प्रोग्रामरों से सबसे अधिक सीखता हूं

— dj18

+1। प्रतिक्रिया देते समय, जब भी संभव हो रचनात्मक आलोचना करना सबसे अच्छा है।

— FrustratedWithFormsDesigner

मैं विशेष रूप से अंतिम बिट से सहमत हूं। यह कहना पूरी तरह से ठीक है, "यह समाधान गलत लगता है क्योंकि ...," या "मुझे चिंता है कि यह हिस्सा समस्याग्रस्त हो सकता है क्योंकि ..." बिना समाधान दिए।

— डेनियल टी।

@dotancohen: "क्या हम इस पर चर्चा कर सकते हैं" एक सवाल था। व्यक्तिगत रूप से, मेरी चर्चा वैसे भी होगी, भले ही यह केवल स्वयं कुछ सीखने के लिए हो।

— बार्ट वैन इनगेन शेनॉ

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

— कैंडिड_ऑरेंज

Answer 2

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

Answer 3

इसलिए आमतौर पर, एक समीक्षक के रूप में, "यह कोड त्रुटिपूर्ण है, इसे अलग तरीके से कहते हैं" या क्या आपको एक विशिष्ट समाधान के साथ आना ठीक है?

दोनों में से कोई भी आदर्श IMO नहीं है। सबसे अच्छी बात यह है कि लेखक से बात करें और समस्या को सहयोग से ठीक करें।

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

Comments

"नौकरशाही प्रक्रिया" इसे लगाने का एक अच्छा तरीका है!

— frnhr

Answer 4

कोड समीक्षाओं में, क्या समीक्षक को हमेशा मुद्दों का समाधान प्रस्तुत करना चाहिए ?

यदि आप ऐसा कर रहे हैं कि आप समीक्षक नहीं हैं, तो आप अगले कोडर हैं।

कोड समीक्षाओं में, क्या समीक्षक को मुद्दों के लिए कभी समाधान नहीं प्रस्तुत करना चाहिए ?

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

एक समीक्षक को मुद्दों का हल कब पेश करना चाहिए?

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

Comments

एक वैक्यूम में कोड न करें, क्योंकि यह बेकार है।

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

— jpmc26

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

— jpmc26

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

— कैंडिड_ऑरेंज

"कोड बंदर उठो कॉफी। कोड बंदर नौकरी पर चले जाते हैं। कोड बंदर बोरिंग प्रबंधक के साथ उबाऊ बैठक है। रॉब का कहना है कि कोड बंदर बहुत मेहनती है, लेकिन उसका उत्पादन बदबू ..."

— बाल्ड्रिक

Answer 5

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

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

Comments

+100 कोड समीक्षा के साथ मेरी सबसे आम निराशा यह है कि अगर मैं एक बेहतर तरीका जानता था, तो मैंने शायद उस तरह से लिखा होगा।

— रबरडक

मुझे आपका पहला वाक्य पसंद है। इसने मुझे खुद से पूछने के बारे में सोचा: "क्या यह कोड काफी अच्छा है?" फिर एक सिक्का उछालकर यह तय करना कि उसे सुधारना है या नहीं! (आम तौर पर मैं इसे केवल तब तक रखता हूं जब तक कि मैं समय से बाहर न चला

आईएमओ "यह कोड जटिल है क्योंकि यह कानून के कानून को तोड़ता है" एक बुरी टिप्पणी है। "यह कोड जटिल है क्योंकि X, Y और Z से बहुत अधिक युग्मित है" बेहतर है।

— इमिबिज़

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

— gnasher729

Answer 6

दो प्रकार के बुरे प्रोग्रामर हैं: वे जो मानक प्रथाओं का पालन नहीं करते हैं और जो "केवल" मानक प्रथाओं का पालन करते हैं।

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

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

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

मुझे लगता है कि यह एक स्पष्ट समाधान की तुलना में समस्या के लिए एक दृष्टिकोण है। सभी स्थितियों को कवर करने के लिए बहुत अधिक परिवर्तनशीलता होने जा रही है।

Comments

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

— वाइल्डकार्ड

कभी-कभी नियमों में कोई अपवाद नहीं होता है, लेकिन आमतौर पर वे ऐसा नहीं करते हैं।

@Wildcard - जो इसे देखने वाले लोगों की क्षमता और पसंद / राय पर निर्भर करता है।

— जेएफओ

@Wildcard मैं दृष्टिकोण लेता हूं कि फीडबैक को एक प्रश्न के रूप में व्यक्त किया जाना चाहिए, लेकिन जवाब होगा (अंततः) एक टिप्पणी का रूप लेगा, या शायद एक कोड परिवर्तन (जैसे बेहतर नामकरण)। यह डेवलपर के लिए उनकी सोच को समझाने के लिए दरवाजा खुला छोड़ देता है, और विकल्पों पर चर्चा करने के बजाय, एक मांग की तरह महसूस कर रहा है, या गलती से उनके लिए अपना काम कर रहा है।

— IMSoP

Answer 7

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

Answer 8

कई कारणों से अधिकांश मामलों में कोड उपलब्ध नहीं कराने की दिशा में मेरी राय मजबूत होती जा रही है:

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

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

फिर भी, 3 कारण के कारण, एक नमूना देते समय यह उदाहरण के लिए कहने योग्य हो सकता x.foo()है "पूर्ण समाधान के बजाय" इस सरल का उपयोग करेगा "- और लेखक को इसे लिखने दें। इससे आपका समय भी बचता है।

Comments

आपके 5 वें बिंदु ने मुझे मुस्कुरा दिया, मैं "द्वंद्वयुद्ध कीबोर्ड" की कल्पना कर रहा था कि कौन पहले एक महान समाधान प्राप्त कर सकता है। कौन जानता था कि पेयर प्रोग्रामिंग उन दो रेसकार आर्केड गेम, या एक पूर्ण संपर्क खेल की तरह हो सकता है? " स्टीव ने बीएसओडी में रॉन को क्रूरता से चेक किया, 2 मिनट पेनल्टी बॉक्स में ... "

Answer 9

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

यदि आपके पास नियमों का एक स्पष्ट सेट है, तो समाधान की पेशकश करने की कोई आवश्यकता नहीं होनी चाहिए। आप बस जाँच कर रहे हैं कि नियमों का पालन किया गया है या नहीं।

यदि वैकल्पिक देव केंट नियमों को मानने वाले फ़ीचर को लागू करने के तरीके के बारे में सोचता है, तो केवल एक वैकल्पिक प्रश्न ही सामने आएगा। मान लें कि आपके पास प्रदर्शन की आवश्यकता है, लेकिन कई अनुकूलन प्रयासों के बाद यह सुविधा आपकी सीमा से अधिक समय लेती है।

हालाँकि! यदि आपके नियम व्यक्तिपरक हैं "नाम मेरे द्वारा अनुमोदित होने चाहिए!" फिर, हाँ, आपने अभी-अभी खुद को प्रमुख नियुक्त किया है और स्वीकार्य नामों की सूची के लिए अनुरोधों की अपेक्षा करनी चाहिए।

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

Comments

"मुझे लगता है कि समीक्षा से पहले नियमों पर सहमत होने के लिए कोड समीक्षा की कुंजी है।" यह आदर्श मामला होगा। व्यवहार में हम यह नहीं मान सकते हैं कि प्रत्येक डेवलपर सभी नियमों को जानता है। इस ज्ञान को फैलाने और व्यावहारिक उदाहरणों के साथ नियमों को समझाने के लिए कोड समीक्षाएं उपयोगी हैं। हो सकता है कि कोड समीक्षा करने का यह सबसे बड़ा लाभ हो ..

— फ्रैंक पफर

नियमों को कोडिंग मानकों के दस्तावेज़ में नीचे लिखें और नए देवों को दें

— ईवान

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

— फ्रैंक पफर

Answer 10

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

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

Answer 11

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

लिखित संचार से बड़ी मात्रा में समय बर्बाद होता है, साथ ही नाराजगी और गलतफहमी भी होती है।

आमने-सामने, बैंडविड्थ बहुत अधिक है, और किसी में शत्रुता को रोकने के लिए भावनात्मक साइड-चैनल है।

यदि आप वास्तव में लड़के से बात करते हैं, तो यह बहुत जल्दी है, और आप एक नया दोस्त बना सकते हैं और पा सकते हैं कि आप दोनों अपनी नौकरी का अधिक आनंद लेते हैं।

Comments

ऐसा लगता है कि किए गए अंकों से अधिक कुछ भी नहीं दिया जा रहा है और पहले के 11 जवाबों में समझाया गया है

— gnat