2008-10-20 13 views
6

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

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

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

+0

एक तरफ, यहां "एकल निकास बिंदु" सिद्धांत पर एक चर्चा है: http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement#36839 –

उत्तर

9

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

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

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

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

3

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

6

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

0

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

2

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

  1. जोखिम को कम करने के लिए - "अरे, यह कुछ है जो कुछ तोड़ने पर उत्तरदायी है।"
  2. कोड की समीक्षा करना जल्द से जल्द होगा क्योंकि यह समीक्षाकर्ताओं को केवल उस कोड पर ध्यान केंद्रित करने की अनुमति देता है जिसे वास्तव में जोड़ा/बदला जा रहा है।
1

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

तब मैं उन्हें क्यूए के साथ बैठूंगा और उन्हें समझाऊंगा कि उन्होंने उससे कहीं अधिक कार्यक्षमता कैसे बदल दी। थोड़ी देर के लिए उसे मारने के बाद।फिर उसे प्रोजेक्ट मैनेजर में ले जाएं और उस व्यक्ति को समझाएं कि वह शेड्यूल को कैसे प्रभावित कर रहा है।

यदि यह काम नहीं करता है, तो उसे रोने तक उसे हराएं।

0

मैं थोड़ा उलझन में हूं। क्या इसका मतलब है कि वह हर विधि में सभी कोड के चारों ओर try {} catch (...){} (या आपकी भाषा के बराबर) रखता है? यदि नहीं, तो अपवाद विधि के वैकल्पिक पथ के रूप में गिना जाएगा।

और स्पष्ट रूप से, यह है कि वे डिज़ाइन किए गए हैं। अन्यथा, एक साधारण निकास कोड एक ही उद्देश्य की सेवा करेगा।

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

0

के अन्य कोड

यदि आप समुदाय कोड स्वामित्व में विश्वास करते हैं, ऐसी कोई बात नहीं है।

ग्रे कोड शैली

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


मेरे व्यक्तिगत नियम में दो लागतें हैं।

"मेरा समय"

मैं कुछ अन्य प्रोग्रामिंग काम पर प्रगति कर किया जा सकता है। अगर मेरे पास कोई अन्य प्रोग्रामिंग कार्य नहीं है, तो मेरा समय मुफ्त था और यह सिर्फ अच्छा काम है।

"कोड आधार दोलन"

दूसरों को मेरी refactorings पुनर्रचना रहे हैं, तो फिर वहाँ एक समुदाय नियम कोडिंग के लिए एक स्पष्ट की जरूरत है। नियम उतना सरल हो सकता है: दोनों तरीकों को स्वीकार किया जाता है - इस परिदृश्य को दोबारा न करें। यह कथन स्पष्ट रूप से किया जाना चाहिए, या यह लागू नहीं होगा।


इस कोड कि पहले से ही परीक्षण किया गया है (लेकिन हमेशा नहीं स्वचालित परीक्षण के साथ) है।

आहा, एक प्रोग्रामिंग कार्य। यह असाइन किया जाना चाहिए।

0

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

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

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

आशा है कि मदद करता है!

0

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

2

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

निश्चित रूप से एक 'लोगों' मुद्दा यह है कि कैसे चीजें काम उसे बताकर उसे तुरंत हल हो सकता है। बुराई, सिर्फ ईमानदार होने की जरूरत नहीं है।

इसके अलावा, जो अन्य लोगों के कोड के साथ गड़बड़ करने के लिए समय मिल गया है? वह स्पष्ट रूप से पूरी तरह से काम नहीं किया जा रहा है। :)

1

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

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

3

मैं इस तरह की स्थितियों में दो बार पहले रहा हूं।

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

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

आपके मामले में, यह काम है कि वह तो आप

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

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

यदि इस प्रोग्रामर के पास सब कुछ रिफैक्टर करने का समय है तो स्पष्ट रूप से उसे असाइन किए गए अधिक काम की आवश्यकता है।

संबंधित मुद्दे