किसी ऐसे व्यक्ति से कैसे निपटें जो कोड समीक्षाओं के विचार को नापसंद करता है?


26

जाहिर है, यदि प्रबंधन कोड समीक्षाओं के साथ समय बिताने में खरीदता है, तो सभी को यह करना होगा।

लेकिन हमेशा ऐसे लोग (या गल्स) होते हैं जो अपने होने के हर औंस का विरोध करते हैं।

सहकर्मी समीक्षक के रूप में इसके साथ व्यवहार करते समय आप इस परिदृश्य से प्रभावी ढंग से कैसे निपटते हैं?


19
संभवत: उसी तरह से आप लोग हैं जो ड्रेस कोड, समयबद्धता, बीमार दिनों, आदि जैसे अन्य वस्तुओं के साथ समस्या का
जोश के

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

3
ईमानदारी से: उन्हें बंद करने और करने के लिए कहें। यह उनकी अपनी भलाई के लिए है।
स्टीवन एवर्स

1
विरोध क्या? आप उनके कोड को देख रहे हैं या वे आपको देख रहे हैं? वे संघर्ष से बच सकते हैं, क्या वे संघर्ष की उम्मीद कर सकते हैं? क्या आप जानते हैं कि वे हिचकिचाते क्यों हैं?
मार्टिन माट

जवाबों:


46

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

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

सबसे प्रभावी तरीका जो मैंने किसी को अनब्लॉक करने के लिए पाया है, वह है अपने कोड की समीक्षा करने के लिए पूछने से पहले उसे अपने कोड की समीक्षा करने के लिए कहना

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


3
आप इससे अपरिचित लोगों के लिए "छिपकली मस्तिष्क" की परिभाषा जोड़ना चाहते हैं।
एडम लेअर

@ अन्ना: मैंने केवल एक परिभाषा में लिंक जोड़ा है।

बहुत बढ़िया जवाब पियरे! अंतिम उत्तर के बदले में अब के लिए अपडाउन किया गया।
ozz

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

1
हमेशा की तरह एक उत्कृष्ट जवाब पियरे।
जोश के

5

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

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


जोड़ी प्रोग्रामिंग एक अन्य विषय है, लेकिन बहुत अच्छा सुझाव है!
ओज

आपकी टिप्पणी ने मुझे पीपी के बारे में कुछ और सोचने पर मजबूर कर दिया, इसलिए मैंने एक और Q - प्रोग्रामर शुरू किया ।stackexchange.com/questions/ 39878/… धन्यवाद!
उल्लू

4

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

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


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

2

सच कहूँ तो, इस सवाल का कोई मतलब नहीं है अगर आपके पास एक अच्छी तरह से प्रबंधित दुकान है:

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

2) यदि आपके पास एक अच्छी तरह से प्रबंधित स्रोत नियंत्रण प्रणाली है, (जो कि किसी भी पेशेवर सॉफ़्टवेयर शॉप में होना चाहिए), तो उनके कोड की समीक्षा की जा सकती है कि वे इसे पसंद करते हैं या नहीं। तो उनके कोड की समीक्षा करें:

  • यदि यह अच्छा है, तो उन्हें सूचित करें और उन्हें पीठ पर थपथपाएं - जिससे भागीदारी को बढ़ावा मिलेगा।

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


यह पूरी तरह से निराशाजनक सलाह है, मैं आपके लिए वास्तव में खराब काम के माहौल के साथ एक "दुकान" की उम्मीद करता हूं। Urgghh!
कॉन्यैक सी सी

@ कॉग्नाक - आपको कुछ भी 'फॉरसी' नहीं चाहिए। मैं 25 वर्षों से समूहों में काम कर रहा हूं जहां हमारे पास बहुत अच्छा काम का माहौल है: हम सभी वयस्क हैं और समझते हैं कि पेशेवर होने के लिए और हमारे काम के लिए जवाबदेही की आवश्यकता है।
वेक्टर

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

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

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

1

क्या उन जगहों पर कुछ नकारात्मक अनुभव हैं जहां कोड समीक्षा ठीक से नहीं की गई थी? उनकी वैध चिंताएँ हो सकती हैं।

यदि वे पूरी तरह से व्यायाम के लिए कोई योग्यता नहीं देखते हैं, तो उन्हें धैर्य रखने के लिए कहें और देखें कि उनके कोड और विशेष रूप से अन्य (यदि उन्हें लगता है कि वे एकदम सही हैं) के परिणामस्वरूप क्या होता है।

कोड की समीक्षा 'विकास में सुधार' करना चाहिए, लेकिन जब तक आपके पास एक प्रणाली है जो वास्तव में काम करती है, तो किसी को क्यों करना चाहिए?


धन्यवाद जेफ, सहमत हैं, अगर प्रक्रिया अच्छी नहीं है, तो यह मुश्किल होगा, और किसी के चिड़चिड़े डर के आसपास रहना मुश्किल हो सकता है - कुछ लोग बस नहीं बदलेंगे!
ozz

1
लेकिन जब तक आपके पास एक प्रणाली है जो वास्तव में काम करती है, तो किसी को क्यों करना चाहिए? मुझे इस पर एक जंगली छुरा लेने दो: ऐसा करो ताकि आप यह पता लगा सकें कि आप सिस्टम क्यों काम नहीं कर रहे हैं ?
वेक्टर

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

@ जेफ़ो - ठीक है, मैं आपकी बात देखता हूं: यदि सिस्टम वास्तव में काम नहीं करता है, तो यह "कोड समीक्षा" का सवाल नहीं है, सवाल प्रोग्रामर की क्षमता है, और इतना सरल "कोड समीक्षा" समाधान नहीं है। मैं इस से सहमत हूँ।
वेक्टर

1

मैं व्यक्तिगत रूप से कुछ झगड़े हैं जो 100% आबादी के साथ नहीं जीते जा सकते हैं।

मैं पर्याप्त कारण देख सकता हूं कि जब कोई ऐसा करने के लिए मजबूर होता है तो जोड़ी प्रोग्रामिंग क्यों काम नहीं करेगी।

लेकिन कोड समीक्षा अलग हैं - वे आपकी उत्पादकता को बदलते हैं, जरूरी नहीं कि आपके काम की आदतें।

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

यदि वे ऐसा करते हैं, तो सभी को भाग लेने के लिए, IMHO की आवश्यकता होती है। जिस कंपनी के लिए मैं अब विश्व स्तर पर काम कर रहा हूँ - आप बस मालिक की मंजूरी के बिना जमा नहीं कर सकते। और जबकि यह चीजों को धीमा कर देता है, यह बहुत सारी दुर्घटनाओं को रोकता है।


पूरी तरह से उरी सहमत ... कुछ लोग हैं जो आप पर जीत नहीं सकते हैं। हो सकता है कि वे अपने तरीके से सेट हों, आलसी, अपने तरीके को सही मानें, या सिर्फ सादा परवाह न करें !!
ozz

0

हमने कोड-समीक्षा को अनिवार्य बनाने के लिए तकनीकी उपायों का उपयोग किया।

जिस तरह से हमने कोड की समीक्षा शुरू की है, वह यह है कि हमारे स्रोत नियंत्रण में, उस कोड को मर्ज करना असंभव है जिसे किसी और ने हस्ताक्षर नहीं किया है, फिर जिसने इसे धक्का दिया।


-1

उन्हें आग लगाओ

यह इतना आसान है - या तो उन्हें एक अकेला आदमी प्रोजेक्ट मिलता है, या उन्हें जाना पड़ता है। उन्हें अपनी टीम से दूर करें। वे न केवल अपना हिस्सा कर रहे हैं, वे टीम के मनोबल और प्रथाओं को मिटा देते हैं।

अब, अगर ऐसा लगता है कि आपको अपनी टीम का 50% फायर करना है, तो ...

समझना

कुछ मना क्यों? क्या उनके पास समय नहीं है? क्या वे जले हुए हैं? क्या किसी ऐसी चीज के बारे में समीक्षा की जा रही है जिसका उन्हें कोई अनुभव नहीं है? क्या उन्हें लगता है कि यह समय की बर्बादी है, यदि ऐसा है तो क्यों?

चंचल कार्यप्रणाली यहां मदद करेगी - मैं आपके सिलोस के खिलाफ लगातार काम कर रहा हूं (यानी बस कारक को कम करने के लिए), और आपकी टीम में व्यक्ति अन्य लोगों को शामिल करते हैं।

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

क्या प्रत्येक व्यक्ति एक ही परियोजना पर काम करता है?

क्या परियोजना पहले से ही तकनीकी ऋण के पहाड़ के नीचे दबी हुई है?

क्या वे परियोजना और निरंतर सुधार में विश्वास करते हैं?


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

@ डंक, क्या आप एक समीक्षक-विरोधी हैं? तब आप मेरी टीम में नहीं होंगे। क्या आप समर्थक समीक्षक हैं? तब आप पहले से ही मेरे दावे का समर्थन जानते हैं। क्या आप अनिर्दिष्ट हैं? कृपया अपना मन
बनाये

मैं कोई समीक्षक नहीं हूं, लेकिन मैं यह भी मानता हूं कि जब कुछ लागत के सापेक्ष उचित लाभ नहीं दे रहा है। कुछ परियोजनाओं / टीमों को आधिकारिक कोड समीक्षाओं की आवश्यकता होती है, जबकि अन्य परियोजनाएं / टीमें केवल तभी करती हैं जब इसके लाभकारी होते हैं। आपकी यह धारणा कि कोड समीक्षाएं हमेशा आवश्यक होती हैं, मुझे बताती हैं कि आपको वास्तविक लाभ और सीमाएं भी नहीं पता हैं। तो आप सही हैं। मैं आपकी टीम में नहीं रहूंगा और यह आपके लिए बहुत बड़ी क्षति होगी।
डंक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.