एक प्रोग्रामर के लिए कोड की समीक्षा करने का सबसे अच्छा तरीका क्या है?

Question

मैं कोड समीक्षा के लिए काफी नया हूं, लेकिन मैं अपने पीएचडी के दौरान वर्षों से कोडिंग कर रहा हूं - जो आपको हमेशा एक अच्छा प्रोग्रामर नहीं बनाता है!

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

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

Comments

एक कोड समीक्षा को अस्वीकार करने

— gnat

एक चर्चा है, इसकी समीक्षा नहीं है अगर यह सिर्फ एक तरह से ट्रैफ़िक है

— NimChimpsky

@gnat: यह प्रश्न स्पष्ट रूप से एक डुप्लिकेट नहीं है। उस प्रश्न का उत्तर दिया गया मतदान, शीर्ष पर देखें। यदि इसे यहां एक उत्तर के रूप में दिया जाता है, तो इसे अस्वीकृत कर दिया जाता, क्योंकि यह इस प्रश्न का उत्तर नहीं देता है ।

— माइकल शॉ

@MichaelShaw meta.stackexchange.com/questions/194476/…

— gnat

@gnat: दूसरा सवाल यह है कि किसी समीक्षा में किसी और के कोड को कैसे अस्वीकार कर दिया जाए, और यह इस बारे में है कि किसी समीक्षा में किसी के अपने कोड की आलोचना कैसे की जाए। एकमात्र समानता मैं देख सकता हूं कि दोनों में कोड समीक्षाएं शामिल हैं।

— माइकल शॉ

Answer 1

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

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

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

यह भी याद रखें कि समीक्षक पूर्ण नहीं है। उन्हें इस बात का अंदाजा हो सकता है कि Y ऐसा करने का तरीका है, और उन्हें एहसास नहीं है कि X बेहतर है। आपको उन कारणों की व्याख्या करनी चाहिए कि आपने इसे एक्स के रूप में क्यों किया। समीक्षक आपसे सहमत हो सकता है, या वह आपको बता सकता है कि वाई एक बेहतर समाधान क्यों है - ऐसे अन्य कारक भी हो सकते हैं जिन्हें आप नहीं जानते कि वह करता है।

संक्षेप में, समीक्षा टीम के सदस्यों को उनके कोड परिवर्तनों के बारे में संवाद करने का एक तरीका है। इसलिए इसके बारे में समीक्षक से बात करें।

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

Comments

"समीक्षक के पास वास्तविक गैर-अनुपालन और दोषों के लिए कोड की समीक्षा करने की ज़िम्मेदारी होती है, न कि इसे अपने कोड को लिखने के साधन के रूप में उपयोग करने के लिए। वे इसे इंगित करने के लिए।": +1

— जियोर्जियो

+1 "समीक्षाएं उनके कोड परिवर्तन के बारे में संवाद करने के लिए टीम के सदस्यों को प्राप्त करने का एक तरीका है"

— Kwebble

Answer 2

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

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

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

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

Answer 3

अन्य उत्तरों में पहले से ही बहुत अच्छी जानकारी है। मैं कुछ पहलुओं पर थोड़ा विस्तार करना चाहूंगा जिन्हें gbjbaanb द्वारा संकेत दिया गया है (उनके जवाब के लिए मेरी टिप्पणी देखें)।

अपने अनुभव में मैंने कोड समीक्षाओं के दौरान विभिन्न प्रकार की प्रतिक्रिया देखी है:

1. "मैं ईमानदारी से मानता हूं कि यह गलत / उप-अपनाने योग्य है और आपको इसे इस तरह बदलना चाहिए।" मैं आम तौर पर इस तरह की प्रतिक्रिया को गंभीरता से लेता हूं, और मैं केवल सुझाए गए बदलाव का विरोध करूंगा यदि मुझे लगता है कि मेरे पास इसके खिलाफ एक मजबूत बिंदु है।
2. "मुझे आपका समाधान ठीक लग रहा है, इस विकल्प पर विचार करें लेकिन यह आप पर निर्भर है कि आप बदलाव स्वीकार करते हैं या नहीं।" मैं इस तरह की प्रतिक्रिया को भी गंभीरता से लेता हूं: समीक्षक एक विकल्प का सुझाव दे रहा है, भले ही उनके पास मजबूत राय नहीं है कि उनका समाधान बेहतर है। मुझे कुछ सीखने का अवसर मिला है और अगर मुझे यह अच्छा लगता है तो मैं बदलाव को स्वीकार करूंगा। अन्यथा, समीक्षक इसे ठीक पाता है यदि मैं अपने स्वाद के अनुसार कोड रखता हूं।
3. "मैंने इसे अलग तरह से किया होगा इसलिए आपको इसे बदलना होगा, अवधि।", या यहां तक ​​कि "ओह, मैंने आपका कोड बदल दिया है क्योंकि ...", परिवर्तन का सुझाव नहीं दिया गया है, यह पहले से ही प्रतिबद्ध है! परिवर्तन के संबंध में कुछ त्वरित स्पष्टीकरण दिए गए हैं, इस संकेत के साथ कि विवरणों पर चर्चा करने के लिए बहुत समय नहीं है क्योंकि हमें अगले कार्य पर जाना है।
4. समीक्षक तुच्छ प्रकृति के छोटे बदलावों का सुझाव देता है जो कोड में सुधार नहीं करते हैं बल्कि इसे अलग बनाते हैं। जब सुझाए गए परिवर्तनों पर चर्चा करने के लिए कहा जाता है, तो समीक्षक तुच्छ विवरण के बारे में लंबी चर्चा में हो जाता है जब तक कि आप थकावट से बाहर नहीं निकलते।

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

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

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

यदि परिस्थितियां 3 और 4 भी अक्सर होती हैं, तो टीम का काम काफी अप्रिय हो सकता है। ऐसे में मैं टीम छोड़ने पर विचार करूंगा।

Comments

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

— स्कैगर

@ सागर: सच: एक हमेशा तथ्यों से चिपके रहने की कोशिश करता है। हालाँकि, यह कभी-कभी थकाऊ हो सकता है। उदाहरण (एक विस्तृत प्रतिबद्धता के संदर्भ में): आपको एक std :: string की QString से तुलना करनी होगी। आपका समाधान: std :: string को QString में कनवर्ट करें और तुलना करने के लिए QString विधि का उपयोग करें। समीक्षक का परिवर्तन: QString को std :: string में परिवर्तित करें और तुलना करने के लिए std :: string विधि का उपयोग करें। आप कोड को समतुल्य कोड में बदलने के बारे में अनंत भिन्नताओं के बारे में सोच सकते हैं बस यह दिखाने के लिए कि आप वहां हैं। रचनात्मक प्रतिक्रिया और नाइटपैकिंग के बीच अंतर करना बहुत महत्वपूर्ण है।

— जियोर्जियो

Answer 4

जब आप असहमत हों तो अपने मुद्दे का समाधान करने के लिए ...

यह बात करना हमारा रास्ता है क्योंकि ज्यादातर लोग पहले ही बता चुके हैं।

यदि आप पहले से ही ऐसा कर चुके हैं, तो शायद एक से अधिक बार भी, एक उपयोगी तकनीक जो हम उपयोग करते हैं, अगर किसी क्षेत्र में अभी भी असहमति है, तो यह कहना है कि हाँ, यह अच्छा होगा कि रिफ्लेक्टर किया जाए -

क्या हम उसके लिए अलग टिकट रख सकते हैं?

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

Answer 5

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

Answer 6

कोड की समीक्षा दोनों संभावित मुद्दों को पकड़ने और समीक्षक और कोडर दोनों के लिए ज्ञान पर पारित करने का अवसर है।

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

विकास के समय कोडर्स के निर्णयों पर चर्चा / समझ के बिना कोड में बदलाव का परिणाम नहीं होना चाहिए।

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

एक कोडर के रूप में एक समीक्षा प्राप्त करने पर आपको एक संभावित मुद्दे से सुरक्षित किया जा रहा है जब तैनात किया जाता है, कुछ नया सीखने का मौका दिया जा रहा है, और समीक्षक के साथ अपने ज्ञान को साझा करने का अवसर।

वरिष्ठता के बावजूद आपके सोचने का तरीका एक ऐसा समाधान लेकर आ सकता है, जो सिर्फ कुछ के लिए नहीं होता है, इसलिए समीक्षा आपके लिए सिर्फ वही करने का मौका दे सकती है, जिसे आप सही मानते हैं।

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

Answer 7

ऐसा लगता है कि आपने अभी तक अपने कोड की समीक्षा नहीं की है :-)

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

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

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

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

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

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