मैं अपनी टीम को छोटी कक्षाओं / विधियों का उपयोग करने के लिए कैसे मनाऊँ?


27

अस्वीकरण: मैं एक नवागंतुक हूं (यह मेरे काम का तीसरा दिन है), और मेरे अधिकांश साथी मुझसे अधिक अनुभवी हैं।

जब मैं अपने कोड को देखता हूं, तो मुझे कुछ कोड गंध और खराब इंजीनियरिंग अभ्यास दिखाई देते हैं, जैसे निम्नलिखित:

  • कुछ असंगत नामकरण दिशानिर्देश
  • गुण संभव के रूप में आसानी से चिह्नित नहीं है
  • बड़ी कक्षाएं - मैंने एक उपयोगिता वर्ग पर ध्यान दिया जिसमें सैकड़ों विस्तार विधियां शामिल थीं (कई प्रकारों के लिए)। यह 2500 लाइनों से अधिक लंबी थी!
  • बड़े तरीके - मैं एक ऐसी विधि को फिर से शुरू करने की कोशिश कर रहा हूं जो 150 लाइनों लंबी है।

बाद के दो एक वास्तविक समस्या लगते हैं। मैं अपने साथियों को छोटी कक्षाओं और विधियों का उपयोग करने के लिए राजी करना चाहता हूं। लेकिन क्या मुझे ऐसा करना चाहिए? यदि हाँ, तो कैसे?

मेरी टीम को मुख्य टीम (हम एक उपग्रह टीम हैं) से एक संरक्षक मिला। क्या मुझे पहले उसके पास जाना चाहिए?


अद्यतन : चूंकि कुछ प्रतिक्रियाओं ने परियोजना के बारे में पूछा, कृपया जान लें कि यह एक काम कर रही परियोजना है। और IMHO, उस आकार के विशाल वर्ग / तरीके हमेशा खराब होते हैं।

वैसे भी, मैं कभी भी अपनी टीम को नाराज नहीं करना चाहता। इसलिए मैंने पूछा - क्या मुझे ऐसा करना चाहिए, और यदि हाँ, तो मैं इसे कैसे करूं?

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

धन्यवाद।


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

14
जब से आप केवल 3 दिनों के लिए काम पर आए हैं, तो आप लोगों को बस पेशाब करने की संभावना है। पहले टीम को जानें और कुछ सम्मान अर्जित करें। पानी को बाहर निकालने के लिए आकस्मिक बातचीत में चीजों को ऊपर लाएं। आपको सही विचार मिला है, लेकिन आप खेत के घोड़ों के एक स्थिर भाग में दौड़ के घोड़े हो सकते हैं।
kirk.burleson

4
वास्तविक दुनिया में आपका स्वागत है :)
fretje

छोटे कार्यों के साथ जेआईटी कंपाइलर अधिक खुश होगा और कोड तेजी से होगा। प्रभावी C # दूसरा संस्करण आइटम 11. my.safaribooksonline.com/book/programming/csharp/9780321659149/…
नौकरी

3
मैं मदद नहीं कर सकता, लेकिन चकली जब मैंने देखा कि एक उपयोगिता वर्ग 2,500 लाइनों की लंबी साक्षी पर आपको कितना डर ​​लगा था। मैंने अपने करियर में 25,000 से अधिक लाइन क्लास देखी हैं। मुझे गलत मत समझो, हालांकि, मुझे लगता है कि 500 ​​लाइनों के बाद एक वर्ग बहुत लंबा हो रहा है।
पीटरअलेनवेब

जवाबों:


19

आपको ताज़ा आँखों से कोड देखने का लाभ होगा। नोट करें कि आप बुरे व्यवहारों के बारे में क्या जानते हैं। फिर, जैसा कि आप टीम के साथ व्यवस्थित हो रहे हैं, अपने नोटों को एक उपयुक्त समय पर बाहर निकालें, जैसे कि जब यह रिफैक्टरिंग का समय है।


वास्तव में अच्छा विचार है। चीजें अभी लिख लें, बाद में कुछ बदलाव प्रस्तावित करें।
रोमन ग्रेजडान

3
यह सिद्धांत रूप में काम करता है, लेकिन व्यवहार में वे उससे बाहर बैग को हरा देंगे।
जॉब

15

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

आप पुस्तक की एक प्रति खरीद सकते हैं, और अपने साथियों को कुछ अध्ययन दिखा सकते हैं ... आँकड़े (हालांकि वे हर समय झूठ बोलते हैं) लोगों को समझाने के लिए करते हैं।


1
कोड पूरा करने के लिए +1। "तकनीकी ऋण" शब्द पर भी शोध करें। मुझे यह दूसरों को समझाने में बहुत उपयोगी लगता है कि क्यों कभी-कभी (लेकिन हमेशा नहीं) यह कोड को सरल बनाने में निवेश करने योग्य है। पहला नियम, हालांकि, परीक्षण बनाना है। यूनिट टेस्ट, सिस्टम टेस्ट, इंटीग्रेशन टेस्ट आदि, किसी भी रिफैक्टरिंग को करने से पहले, टेस्ट बनाएं। परीक्षण, परीक्षण, परीक्षण टेस्ट।
बेन हॉकिंग

@ कोई अनादर नहीं है, लेकिन मुझे लगता है कि "तकनीकी ऋण" शब्द का इस्तेमाल किया गया है। जैसे ही कोई व्यक्ति किसी निर्णय के पीछे उनके तर्क के रूप में उपयोग करना शुरू करता है, मैं सुनना बंद कर देता हूं। हो सकता है कि मेरी ओर से इसका दोष हो, लेकिन जब मैं सुनता हूं कि मेरे विचार "इस व्यक्ति को बहुत सारे ब्लॉग
पढ़ने को मिलते

3
@Gratzy: मुझे यकीन है कि यह आपके व्यक्तिगत अनुभव पर निर्भर करता है। मैं विवरण में नहीं जाना चाहता हूं, लेकिन जब आप "तकनीकी ऋण" में अपनी गर्दन तक प्रोजेक्ट देखते हैं, तो अभिव्यक्ति बहुत उपयुक्त हो जाती है। कॉडर्स अपने समय का 90% "ब्याज का भुगतान" ऋण पर खर्च कर सकते हैं। उन मामलों में, यह पता लगाना आश्चर्यजनक नहीं है कि टीम में किसी ने भी इस शब्द के बारे में नहीं सुना है।
बेन हॉकिंग

क्लीन कोड में इस बारे में बहुत सारी जानकारी है (हालांकि, कई आँकड़े नहीं हैं)।
स्टीवन एवर्स

यदि आप पृष्ठ १ at३ पर एक नज़र डालते हैं, तो मैककॉनेल नियमित आकार के पक्ष में कुछ सांख्यिकीय साक्ष्य प्रस्तुत करता है जो संभवतः सबसे चुस्त वकालत करते हैं। वह ओके (लेकिन आदर्श नहीं) कॉलम में 150 स्पष्ट रूप से स्पष्ट रूप से डालता है, लेकिन पिछले 200 से अधिक के खिलाफ एक मजबूत व्यक्तिगत सिफारिश देता है।
दान मोनेगो

13

अस्वीकरण: मैं एक नया कामरेड हूं (यह मेरे काम का तीसरा दिन है), और मेरी टीम के अधिकांश लोग मुझसे ज्यादा अनुभवी हैं।

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

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

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

कैसा गया? "एक बार माप दो बार काटो .." कुछ इस तरह।


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

12

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

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

मैं TDD की एक बड़ी प्रशंसक नहीं हूँ, लेकिन मैं है तथ्य यह है कि यह डेवलपर्स के लिए मजबूर करने पर विचार करने कि वे किस तरह परीक्षण लिखते हैं प्यार करता हूँ। और कि अक्सर क्यों कोड, बेहतर है वास्तव में के बारे में नहीं कुछ जादू है होने परीक्षण। (हालांकि बाद में बदलाव करने पर यह सुनिश्चित हो जाता है।)

शुभकामनाएँ।


++ के लिए "मध्यम अपने उत्साह"। IMHO, जिस सिद्धांत के साथ इन सिद्धांतों का प्रचार किया गया है, वह उनके औचित्य के विपरीत है। (धर्म ऐसे ही होते हैं।)
माइक डनलैवी

11

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

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

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

और हाँ सभी माध्यमों से कोड कंप्लीट से सभी को सामान दिखाएं।


3
+1 के लिए "इसके बजाय, आगे बढ़ो और कॉम्पैक्ट और स्वच्छ कोड खुद लिखें"। उदाहरण द्वारा नेतृत्व करना अक्सर सर्वोत्तम होता है। और एक स्थापित कोड आधार की सफाई एक स्प्रिंट की तुलना में मैराथन की तरह अधिक है; यह धैर्य और दृढ़ता लेता है।
जेरेमीडविल

8

यहाँ कुछ चाल है:

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

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

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

  • भविष्य की रोकथाम के तंत्रों का सुझाव दें - उदाहरण के लिए, टीम एक लक्ष्य के लिए सहमत हो सकती है कि वह कभी भी शीर्ष कुछ सबसे बड़ी कक्षाओं में शामिल नहीं होगी, लेकिन जब उन्हें और आगे बढ़ने की आवश्यकता होगी, तो रिफ्लेक्टर करेंगे।

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

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

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


6

मैं अपनी टीम को छोटी कक्षाओं / विधियों का उपयोग करने के लिए कैसे मनाऊँ?

मत करो।

अपने आप को एक Resharper लाइसेंस खरीदें और उदाहरण के लिए नेतृत्व करें। [' एक्स्ट्रेक्ट मेथड ' रीफैक्टरिंग पर भारी पड़े।]

समय के साथ, दूसरों को आपके अधिक पठनीय कोड की सराहना करनी चाहिए और इसी तरह करने के लिए राजी होना चाहिए। *


  • हां - एक मौका है कि वे राजी नहीं होंगे; लेकिन यह अभी भी तुम्हारा सबसे अच्छा दांव है।

IMO - यह आपके सिलेबल्स के लायक नहीं है कि आप अपने साथियों को बेहतर प्रोग्रामर बनने के लिए मनाने की कोशिश करें, ' कोड कम्प्लीट ' पढ़ें , @Uncle Bob को फॉलो करें। यदि वे पहले से ही राजी नहीं हैं, तो ठोस सिद्धांत, और बेहतर प्रोग्रामर बनें।

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


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

4

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

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


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

4

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

विज़ुअल स्टूडियो में "कोड विश्लेषण" है जो नामकरण सम्मेलनों के साथ मदद कर सकता है।

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

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

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


3

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

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

लेकिन जैसा कि यह खड़ा है, व्यापार वास्तव में देखता है कि यह पैसा है। मुझे उनके लिए एक मामला बनाना होगा जो उन्हें रिफैक्ट करने के लिए उन्हें पर्याप्त लाभ प्रदान करे ताकि मेरी टीम को समय और संसाधन मिल सके। बस जिस तरह से कोड लग रहा है वह पर्याप्त नहीं है।

इसलिए, अगर यह काम करता है, जितना आप इसे नफरत कर सकते हैं, तो आपको इसे अकेला छोड़ना पड़ सकता है।

अब नया कोड, वह अलग है। यह अच्छा कोड होना चाहिए।


2

वे विधियाँ जो 150 रेखाएँ हैं ... मैंने कोड की 10.000 पंक्तियों के साथ विधियाँ देखी हैं।

आपकी दो समस्याओं को बाहरी उपकरणों से हल किया जा सकता है :

  • कुछ असंगत नामकरण दिशानिर्देश
  • गुण संभव के रूप में आसानी से चिह्नित नहीं हैं

C # Resharper में दोनों मुद्दों की जाँच कर सकते हैं। आपके दिशानिर्देशों का पालन नहीं करने वाले नामों को त्रुटियों के रूप में चिह्नित किया जाता है। गुण के रूप में चिह्नित नहीं त्रुटियों के रूप में आसानी से दिखा। FxCop भी एक मदद हो सकती है।

ये उपकरण अपने रीफैक्टरिंग की बदौलत विशाल तरीकों को कई छोटे लोगों में विभाजित करने में मदद कर सकते हैं।


2

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


1

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


1

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

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


1

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


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