एक जूनियर डेवलपर से 'लगभग अच्छे' कोड से कैसे निपटें? [बन्द है]


95

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

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

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

मैं आदमी को पढ़ाने और उसे लगातार आलोचना से नहीं जलाने के बीच की रेखा को कैसे संतुलित करूं? एक जूनियर के लिए यह निराशाजनक हो सकता है यदि आप उसे फिर से सामान देने के लिए कहेंगे कि उसकी आँखों में काम हो रहा है।


7
आपने यह सुनिश्चित करने में कितना समय बिताया है कि वह जानता है कि आपकी अपेक्षाएँ क्या हैं?
ब्लरफुल


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

4
मैंने इसे इस विषय पर और अधिक बनाने के लिए संपादित किया। मेरा मानना ​​है कि यह लिंक किए गए डुप्लिकेट प्रश्न से भी अलग है।
एंडरलैंड

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

जवाबों:


84

यदि आपको लगता है कि मर्ज करने से पहले कोड तय होना चाहिए, तो टिप्पणी करें। अधिमानतः "क्यों" के साथ ताकि देव सीख सकें।

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

हालाँकि, यदि आप खुद को कमेंट करते हुए पाते हैं जो थकाऊ लगता है, तो शायद इस पर विचार करें:

  • क्या आपकी CI प्रक्रिया को पकड़ना चाहिए?
  • क्या आपके पास संदर्भ के लिए एक स्पष्ट "डेवलपर गाइड" है (या आपके सिर में सब कुछ प्रलेखित है)?
  • क्या ये टिप्पणियां वास्तव में कोड गुणवत्ता में योगदान करती हैं?

बहुत से लोग प्रक्रिया या पूर्णता की वेदी पर उत्पादकता का त्याग करते हैं। सावधान रहें आप ऐसा नहीं करते हैं।

यदि संभव हो तो अपने सहकर्मी से मिलने की कोशिश करें। या वीडियो कॉल का उपयोग करें। संबंध बनाने से आलोचना (यहां तक ​​कि कोड समीक्षा) का प्रबंधन करना आसान हो जाता है।

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

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


65
@ 9000 यह आश्चर्यजनक है कि लोग अक्सर अपने मानकों के अनुसार योगदान नहीं करने वाले लोगों के बारे में निराश होते हैं, जब उन मानकों को कहीं भी प्रलेखित नहीं किया जाता है ...
एंडरलैंड

32
कोड के इरादे का वर्णन करने में परिवर्तनीय नाम पूरी तरह से महत्वपूर्ण हैं ; विधि / फ़ंक्शन नाम, और भी बहुत कुछ। नामों को सही तरीके से प्राप्त करना व्यर्थ पूर्णतावाद नहीं है, इसे बनाए रखने के लिए आवश्यक है।
9000

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

6
@ ज़ालोमन (जारी) फ्लिप पक्ष पर, एक वरिष्ठ देव जिसने मेरी पीठ के पीछे बदलाव किया (भले ही आप उसे बाद में बताएं, यह अभी भी उसकी पीठ के पीछे है) पूरी तरह से मनोबलहीन कर रहा था - इससे मुझे ऐसा महसूस हुआ कि मैं एक ऑटोक्रेट के साथ काम कर रहा था कि मैं कैसे पता करने के लिए कृपया था।
dj18

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

19

लेखक के बजाय कोड पर आलोचना रखें।

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

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

शारीरिक हाव - भाव

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

ईमानदार सकारात्मक प्रतिक्रिया दें

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


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

6

आदमी आलोचना के लिए खुला है और सीखने के लिए तैयार है, लेकिन मुझे कुछ संदेह है कि मुझे कुछ सामान को कितना धक्का देना चाहिए।

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

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

इसके अलावा, यदि आप वापस पकड़ते हैं, तो आप मदद नहीं कर रहे हैं, बल्कि संरक्षण दे रहे हैं।

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

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


5

आपके विवरण के आधार पर, मैं इस पर छोड़ देता हूं: "यह अच्छा है। कुछ चीजें हैं जो मैंने अलग तरीके से की होंगी, लेकिन वे बहुत महत्वपूर्ण नहीं हैं।"

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

मैं चाय के क्षण की अवधारणा में विश्वास करता हूं । यदि डेवलपर के पास पर्याप्त मानसिक क्षमता है, तो वह आपसे अलग-अलग कामों के बारे में विवरण मांग सकता है। (एस) वह नहीं हो सकता है और यह ठीक है। लोगों को बाहर जला दिया जाता है और कैरियर की शुरुआत में यह बाद में सरल लगने वाली चीजों को पूरा करने के लिए बहुत अधिक मानसिक ऊर्जा ले सकता है।


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

1
मुझे नहीं लगता कि देव को यह बताने के लिए एक अच्छा विचार है कि "वे बहुत महत्वपूर्ण नहीं हैं" यदि वे ओपी के लिए महत्वपूर्ण हैं कि वे वापस जाएं और बाद में बदल दें।
एंडरलैंड

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

5

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

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

तो आप यह नहीं कहते कि "मैं आपके काम को अस्वीकार करता हूँ क्योंकि यह बहुत अच्छा नहीं है"। आप कहते हैं (ए) "मैं आपके काम को स्वीकार करता हूं क्योंकि यह काफी अच्छा है", और फिर (बी) "लेकिन मैं इसे बेहतर चाहता हूं"।


3
या "(बी) और मुझे पता है कि आप बेहतर कर सकते हैं।" अगर वह पूछता है "मुझे सिखाओ" तो आप जानते हैं कि वह सही रास्ते पर है। :)
मचाडो

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

4

सुंदर विस्तृत खुला प्रश्न है, लेकिन यहाँ एक दो विचार हैं।

  1. सहकर्मी समीक्षा (जूनियर डेवलपर द्वारा)

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

  2. प्रारंभिक प्रतिक्रिया / कार्य समीक्षा

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


3
मुझे सहकर्मी की समीक्षा का विचार पसंद है, फिलहाल यह टीम में हममें से केवल दो हैं लेकिन मैं उसे अपने कोड की समीक्षा कर सकता हूं। अगर वह समझ सकता है कि मैं क्या करता हूं और कुछ असंगतताएं पा सकता हूं तो यह कोड गुणवत्ता और उसके मनोबल दोनों के लिए सहायक हो सकता है। इससे मुझे मदद मिली जब मैं सीख रहा था कि मैं केवल एक ही गलतियाँ नहीं कर रहा था +1
ज़ालोमन

2

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

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

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


2

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

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

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

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


1

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

ये वास्तविक संभावनाएं और वैध चिंताएं हैं। डेवलपर से पूछें कि वे इसके बारे में कैसा महसूस करते हैं।


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

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

1

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

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

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


0

मैं एक जूनियर डेवलपर के साथ काम कर रहा हूं जो एक कोडिंग कारखाने से दूरस्थ रूप से काम कर रहा है।

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

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

... एसआरपी का उल्लंघन, भगवान की वस्तुओं, तरीकों या चर के लिए गैर-सार्थक नाम; मैं इंगित करता हूं कि उसे क्या ठीक करना है और यह समझाने की कोशिश करना कि यह गलत क्यों है।

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

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

यह सब आपके हिस्से पर अधिक प्रयास की आवश्यकता होगी, लेकिन वर्तमान में आपके पास समस्याग्रस्त संबंध को देखते हुए, यह संभवतः सार्थक होगा।


-1

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

हमेशा उन्हें बताएं कि उन्होंने क्या सही किया और अगली बार वे कैसे सुधार कर सकते हैं। हम हमेशा कुछ क्षेत्र में बेहतर कर सकते हैं। किसी भी चीज़ में बेहतर बनने के लिए प्रतिक्रिया महत्वपूर्ण है।


-1

"बहुत अधिक आलोचना" से निपटने के लिए एक और विचार समय-समय पर अपने आप से एक कार्य करना है, और एक जूनियर डेवलपर को आपके लिए एक कोड समीक्षा करने दें। इसके कम से कम दो फायदे हैं:

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

मुझे यह जानकर खुशी होगी कि मेरी पोस्ट में क्या गलत है। एक अपमान असहमति का एक समझ में आने वाला संकेत है, लेकिन वोट हटा दें ?!
बार्टोज़केपी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.