मैं अपने प्रोजेक्ट मैनेजर या लीड डेवलपर को कैसे बताऊं कि प्रोजेक्ट के कोडबेस को गंभीर काम की जरूरत है?

Question

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

परियोजना (मध्यम से बड़े आकार के ASP.NET WebForms व्यावसायिक अनुप्रयोग की आंतरिक रेखा है), एक अधिक वर्णनात्मक शब्द, एक आपदा की कमी के लिए है। कोडिंग मानकों के साथ तीन तुरंत ध्यान देने योग्य समस्याएं हैं:

1. मानक बहुत ढीला है। यह वर्णन करता है कि क्या नहीं करना है (हंगेरियन नोटेशन, आदि का उपयोग न करें) क्या करना है।
2. मानक का हमेशा पालन नहीं किया जाता है। हर जगह कोड स्वरूपण के साथ विसंगतियां हैं ।
3. मानक Microsoft की शैली दिशानिर्देशों का पालन नहीं करता है। मेरी राय में, दिशानिर्देश के विकास और भाषा विनिर्देश के सबसे बड़े योगदानकर्ता द्वारा निर्धारित दिशानिर्देशों से भटकने का कोई मूल्य नहीं है।

बिंदु 3 के लिए, शायद यह मुझे अधिक परेशान करता है क्योंकि मैंने अपने MCPD को वेब अनुप्रयोगों (विशेष रूप से, ASP.NET) पर ध्यान केंद्रित करने के लिए लिया है । मैं टीम में एकमात्र Microsoft प्रमाणित पेशेवर भी हूं। क्योंकि मैंने अपने सभी स्कूली शिक्षा, स्व-शिक्षण और ऑन-द-जॉब लर्निंग (प्रमाणन परीक्षाओं के लिए मेरी तैयारी सहित) में सीखा है, मैंने प्रोजेक्ट के कोड में कई उदाहरण भी देखे हैं जहाँ चीजें बस में नहीं होती हैं सर्वोत्तम मार्ग।

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

क्या मुझे (और यदि ऐसा है तो मैं कैसे) अपने प्रोजेक्ट मैनेजर और टीम लीड को प्रस्ताव दूं कि प्रोजेक्ट को प्रमुख रूप से पुनर्निर्मित किया जाना चाहिए?

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

Comments

आपके पास ASP.NET के साथ कितना अनुभव है? (अपने MCPD क्रेडेंशियल के अलावा)।

— मार्की

किसी भी सफल उत्पाद में आपका स्वागत है। 'विरासत' कोड हमेशा बकवास होता है।

— स्टीवन एवर्स

en.wikipedia.org/wiki/C'est_la_vie

— जॉब

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

— रेनो

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

— मिस्टर आईटी गुरु

Answer 1

आप अपना समय अपने मामले पर बहस करने में बिता सकते हैं; या आप अपना समय सफाई के साथ बिता सकते हैं।

उठाओ स्वच्छ कोड और फुर्तीली सॉफ्टवेयर विकास के सिद्धांतों, पैटर्न, और व्यवहार और तुम वहाँ क्या सीखना के रूप में आप सिस्टम पर काम लागू होते हैं। आखिरकार, लोग नोटिस करेंगे (बेहतर, या बदतर के लिए)।

संपादित करें यह भी देखें कि लिगेसी कोड के साथ प्रभावी ढंग से कार्य करना

Comments

हलवा का सबूत खाने में है। यदि आप जो देखते हैं वह वास्तव में मरम्मत की आवश्यकता है, तो इसे ठीक करें - और आपके आस-पास के लोग जल्द ही नोटिस करेंगे।

— ब्लूबेरीफील्ड्स

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

— एडम मारस

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

— माइकल ब्राउन

यदि यह गलत है, तो टेस्ट सूट में एक टेस्ट केस भी जोड़ दें जो कोड को वापस करने पर विफल हो जाता है।

— ब्लूबेरीफील्ड्स

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

— सॉ हैक

Answer 2

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

हो सकता है कि आपको उच्च मानकों का उपयोग करने की आवश्यकता हो? उस स्थिति में पूर्णता से कोई भी विचलन विफलता माना जा सकता है। यह एक ऐसा जाल है जिसमें गिरना आसान है जब आपकी मांग अधिक होती है, लेकिन चीजों पर परिप्रेक्ष्य रखना महत्वपूर्ण है।

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

Answer 3

निश्चित रूप से अपने MCSD को इधर-उधर लहराते हुए मत जाइए, लोग आपको बहुत खुलकर हंसाएंगे, एमएस सेरेमनी अच्छी लगती है, लेकिन वे किसी भी तरह से पेशेवर योग्यता नहीं रखते हैं!

एक नई टीम में शामिल होने के लिए हल्के से कदम उठाएं, जैसे ही आप जाते हैं, परिवर्तनों का सुझाव देने के अवसरों की तलाश करें।

एक टीम कोड बंद करने से पहले जमीन पर लेटने तक प्रतीक्षा करें।

Comments

मेरे MCPD प्रमाण पत्र का उल्लेख करने का कारण यह है कि सिद्ध-सर्वोत्तम प्रथाओं पर एक मजबूत जोर है। कभी-कभी, ASP.NET जैसे ढांचे में, वास्तव में एक सही तरीका है और चीजों को करने का एक गलत तरीका है।

— एडम मारस

कोई शक नहीं कि एक सही तरीका है! लेकिन एक प्रमाणित लहराते हुए आने वाले कुछ नए व्यक्ति इसके बारे में जाने का तरीका नहीं है। उद्धरण अनुभव, यह अधिक विश्वसनीय है!

— ozz

@ अदम: बस एक विचार है, लेकिन उदाहरण के विशाल बहुमत मैंने देखा है - विशेष रूप से ASP.Net और यहां तक ​​कि MVC के साथ moreso - चीजों को करने के लिए भयानक तरीके दिखाते हैं, जबकि वे दावा करते हैं कि वे "सर्वश्रेष्ठ" प्रथाएं हैं। उनके ViewModels के भीतर EF या L2S कक्षाओं का उपयोग करने वाले कितने उदाहरणों पर एक सरल नज़र है।

— क्वेंटिन-स्टारिन

Answer 4

आप सोच सकते हैं कि समस्या आप ही हैं। आपके द्वारा बताई गई तीन चीजों में से कोई भी एक आवेदन के पूर्ण पुनरावृत्ति के योग्य है। वे सिर्फ निपिक विवरण हैं।

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

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

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

Comments

इस! इतना तो। अगर यह बग पैदा कर रहा है, तो यह एक बात है, लेकिन अगर यह सिर्फ आप अपने ओसीडी नाइटपिक मुद्दों को हर किसी के गले में डालने की कोशिश कर रहा है, तो हर तरह से मेरी टीम से दूर हो जाओ!

— Glstunna

Answer 5

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

ऐसा लगता है कि आपने तीन (अपेक्षाकृत) मामूली चीजों को चुना है। ऐसी अन्य चीजें हैं जिनके बारे में मैं अधिक चिंता करूंगा:

• क्या कोड अच्छी तरह से प्रलेखित है?
• क्या कोड स्पेक्स / डिज़ाइन डॉक्स का पालन करता है?
• क्या कोड काम करता है?
• क्या यह समझना आसान है कि कोड क्या करता है?
• क्या आप इस कोडबेस के बड़े हिस्से को TheDailyWTF में जमा करने पर विचार कर रहे हैं?

Comments

1) नंबर 2) वास्तव में नहीं। 3) ज्यादातर समय? 4) कभी-कभी। 5) हाँ।

— एडम मारस २ Adam

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

• यहां आपके द्वारा किए गए परिवर्तनों के प्रकारों को बनाने से कितना व्यावसायिक मूल्य प्राप्त होता है?
• क्या आपने स्क्रैच से एप्लिकेशन को फिर से लिखना, मौजूदा कोड को संशोधित करना, इसे सूंघने के लिए, या बस समय के साथ थोड़ा बदलाव करना जैसे विकल्पों पर विचार किया है?
• क्या आप जानते हैं कि अब कौन सी सुविधाएँ और बग चाहते हैं जो आपको उन परिवर्तनों को करने से रोकेंगे जो आप चाहते हैं?

जबकि मैं खराब कोड बेस को ठीक करने की इच्छा कर सकता हूं, इसे तौला जाना चाहिए ताकि इसे करने के लिए व्यावसायिक दृष्टिकोण से समझ में आए।

Comments

मुझ पर भरोसा करो, मैं फिर से लिखना चाहूंगा। मैं लगभग घर जाने के लिए और ASP.NET MVC 3 में एक नया कोडबेस शुरू करने के लिए प्रलोभित हूं, केवल यह दिखाने के लिए कि यह कितना बेहतर है। मुझे नहीं लगता कि यह अच्छी तरह से प्राप्त होगा, क्योंकि मैं टीम में नया हूं।

— एडम मारस २ Adam

Answer 9

आप वर्तमान में खराब कोड को रोकने की स्थिति में नहीं हैं, इसलिए आपको यह पता लगाना होगा कि इसे कैसे शामिल किया जाए।

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

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

टीम के अन्य सदस्य प्रमाणित होना चाहते हैं और आप एक महान संसाधन होंगे। उम्मीद है कि वे कम से कम सुधार करना चाहते हैं और उन्हें रास्ता दिखाने के लिए आपकी ओर देखेंगे।

हंगेरियन नोटेशन के बारे में शिकायत करने से आपको कोई सहानुभूति नहीं मिलेगी और शायद प्राथमिकता सूची में अंतिम लड़ाई में से एक है।

Answer 10

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

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

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

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

Answer 11

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

Comments

+1: अधिकार - क्षमा मांगें, अनुमति नहीं।

— जिम जी।

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

— HLGEM

Answer 12

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

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

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

Comments

+1 गंभीर के लिए यह सब जानते हैं। मैं ट्विटर पर एक पूर्व-एमएस व्यक्ति का पालन करता हूं और वह एक नई भूमिका में सटीक काम कर रहा है और इसके बारे में ट्वीट कर रहा है, बड़ी गलती!

— ozz

Answer 13

इस 'समस्या' के साथ सीधे प्रबंधन में मत जाओ।

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

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

Answer 14

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

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

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