एक विकास प्रबंधक द्वारा "गोल प्रवृत्ति" को कैसे संभाला जाना चाहिए?


12

पहले मुझे एक शब्द गढ़ने की अनुमति दें:

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

इस प्रथा के कुछ नियम और विपक्ष हैं जिनकी मैंने पहचान की है:

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

अस्वीकरण: निष्पक्ष होने के लिए, मैं वास्तव में एक विकास प्रबंधक नहीं हूं, मैं डेवलपर हूं जो वास्तव में "गोल करने" के लिए कर रहा हूं।

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

इसलिए, यदि आप प्रबंधक थे, तो आप इस समस्या का समाधान कैसे करेंगे?

अद्यतन: इसका मतलब यह नहीं है कि यह बहुत अधिक स्थानीय हो सकता है, लेकिन कुछ ने पूछा है, इसलिए शायद कुछ पृष्ठभूमि रोशन होगी। मुझे तीन साल पहले एक विशाल परियोजना (200K LoC) सौंपी गई थी, और हाल ही में (1 वर्ष पहले) परियोजना में अतिरिक्त डेवलपर्स जोड़े गए थे, जिनमें से कुछ वास्तुकला से अपरिचित हैं, अन्य जो अभी भी भाषा सीख रहे हैं (C #)। मुझे आम तौर पर उत्पाद की समग्र स्थिरता के लिए जवाब देना पड़ता है, और जब कोड आधार के कोर वास्तुशिल्प भागों में आश्चर्यजनक रूप से परिवर्तन किए जाते हैं, तो मैं विशेष रूप से घबरा जाता हूं। यह आदत इसलिए पड़ी क्योंकि पहले तो मैं दूसरे डेवलपर के योगदानों के बारे में आशावादी था, लेकिन उन्होंने कई गलतियाँ कीं, जिससे गंभीर समस्याएँ पैदा हुईं, जिन्हें हफ्तों बाद तक खोजा नहीं जा सकेगा, जहाँ मुझे अस्थिर कोड लिखने के लिए उंगली उठाई जाएगी। अक्सर ये "


3
जाहिर है कि आपके डेवलपर्स आपके टायर को पर्याप्त रूप से पंप नहीं कर रहे हैं। अपने लक्ष्य को FxCop या कुछ समान के साथ बदलें और उन मानकों को स्वचालित रूप से लागू करें ताकि वे जांच न कर सकें।
जॉन रेन्नोर

2
Con: यह तुम्हारा काम नहीं है। इन लोगों को अपना लक्ष्य साधना चाहिए।
रॉबर्ट हार्वे

10
एक डेवलपर के रूप में, मुझे लगता है कि यह मेरे द्वारा किए गए सभी परिवर्तनों के साथ करने के लिए किसी अन्य डेवलपर के लिए यह
उल्लंघनकारी होगा

4
@ रायथल: दुकान को एक कोड मानक लागू करना चाहिए। कोड आम तौर पर पूरी टीम के स्वामित्व में है, इसलिए यदि आप नहीं चाहते कि लोग इसे बदल दें, तो आपको इसे पहले स्थान पर बनाना चाहिए।
रॉबर्ट हार्वे

1
@RobertHarvey एक मानक को लागू करना एक बात है, एक दुष्ट डेवलपर चुपचाप "सही" के अपने विचार को लागू करना एक अलग मामला है, और यह बाद का मामला लगता है।
रयथल

जवाबों:


52

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


4
बड़ा +1। कोड समीक्षाएं टीम के निर्माण में मदद करती हैं, जबकि "गोल करने" का वह वर्णन करता है कि ऐसा लगता है कि यह लोगों को गलत तरीके से रगड़ सकता है।
डग टी।

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

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

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

2
यहां तक ​​कि अगर आप कभी भी "वास्तविक" कोड समीक्षाओं के लिए संक्रमण नहीं करते हैं, तो बस दूसरे व्यक्ति से बात कर रहे हैं - यह पूछते हुए कि उन्होंने कुछ चीजें क्यों कीं, और उन्होंने ऐसा क्यों नहीं किया [कुछ और तरीका], उसी में से कई को पूरा करने का एक शानदार तरीका है लक्ष्य। +1
तेहरिस्क

14

फ्रैंक, IMHO होने के लिए, यह एक भयानक विचार है।

अगर यह पहले से ही नहीं है, तो मैं मनोबल को नाली में छोड़ने की उम्मीद करूंगा।

आपके लिए निष्पक्ष होना, आप इसे स्वीकार करते हैं।

सहकर्मी कोड की समीक्षा ठीक है, यह एक स्तर पर सभी पर देवताओं को डालता है, इसके बजाय यह "उन्हें बनाम हमारे" परिदृश्य है। (जहां वे प्रबंधन / नेतृत्व करते हैं)।

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

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


वह और प्रबंधक संभवतः कोड को बदतर बनाने की अधिक संभावना है।
एंडी

5

यदि मैं प्रबंधक होता, तो इस समस्या का समाधान करने के लिए:

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

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

यदि परियोजना के पास शुरू करने के लिए कोई मानक नहीं था, तो केवल एक स्विच को फ़्लिप करने के बजाय चरणों में नए मानक में आसानी करने का प्रयास करें।


3

बुरा जीजू।

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

सफाई कार्यों को केवल टीम द्वारा एक औपचारिक कोड समीक्षा के बाद निष्पादित किया जाना चाहिए, और केवल डेवलपर (ओं) द्वारा जिन्हें उन कार्यों को सौंपा गया है।

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

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