प्रबंधन कोड बताने का एक सही तरीका क्या है / क्या हमारा कोड बेकार है?


70

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

हाइलाइट्स में से कुछ:

  • हम अभी भी फ़्रेम का उपयोग करते हैं (एक क्लेरीस्ट्रिंग से कुछ पाने की कोशिश करें, लगभग असंभव)
  • VBScript
  • स्रोत सुरक्षित
  • हम '.NET' का उपयोग करते हैं - इसका मतलब है कि हमारे पास .net रैपर हैं जो COM DLL को कॉल करते हैं जिससे यह आसानी से डिबग करना लगभग असंभव है
  • सब कुछ मूल रूप से एक विशाल समारोह है
  • कोड मेंटेन नहीं है। हर पेज में कई फाइलें होती हैं जो हर बार एक नया पेज बनाया जाता है। HTML (रनरेट = "सर्वर को रेंडर करने के लिए मुख्य पृष्ठ मूल रूप से Response.Write () समय का एक गुच्छा है! कोई रास्ता नहीं)। उसके बाद क्लाइंट पक्ष (VBScript) पर बहुत सारे तर्क हो सकते हैं, और अंत में पेज खुद को प्रस्तुत करता है (अक्सर छिपे हुए क्षेत्रों में कई चीजों को संग्रहीत करते हुए) जहां यह तब एक प्रसंस्करण पृष्ठ पर पोस्ट करता है जो चीजों को बचा सकता है जैसे कि सहेजना डेटाबेस के लिए डेटा।
  • हमें मिलने वाले स्पेसिफिकेशन हंसी के पात्र हैं। कई बार वे "Y या फ़ील्ड Z के साथ या तो फ़ील्ड Y या फ़ील्ड Z 'चुनने के संकेत के साथ" ऑटो-पॉप्युलेट फ़ील्ड X जैसी चीज़ों के लिए कॉल करते हैं।

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

मैं क्या कर सकता हूँ? मैं इन मुद्दों को कैसे लाऊं? मेरी टीम के 75% लोग मुझसे सहमत हैं और अतीत में इन मुद्दों को उठा चुके हैं, फिर भी कुछ भी नहीं बदला है।


27
इस्की आद्त डाल लो। 90% राइटिंग कोड रीडिंग कोड है।

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

11
यह ऑफ टॉपिक है। लेकिन संक्षिप्त जवाब है: अर्थशास्त्र। कितने डेवलपर-महीनों को कोडबेस को साफ करने के लिए खर्च करना होगा, और कई डेवलपर-महीनों में एक साफ कोडबेस को सहेजना होगा?
ओलिवर चार्ल्सवर्थ

89
सबसे अच्छा तरीका एक निकास साक्षात्कार में है।
काइलबेन

32
इससे कोई फर्क नहीं पड़ता कि आप अंधे से रंग के बारे में कैसे बात करते हैं। वे आपको समझ नहीं पाएंगे।
थॉमसएक्स

जवाबों:


68

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

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

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

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

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

फिर से लिखना? लगभग हमेशा एक बुरा विचार।

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


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

2
उस अंतिम बिंदु पर जारी रखने के लिए, मैंने कई स्थानों को देखा है, जहां प्रबंधन व्यवसाय से बाहर जाने का जोखिम उठाएगा, जब घटिया प्रणाली वास्तव में स्वयं को ध्वस्त कर देती है और मुद्दों को संबोधित करती है, भले ही उन मुद्दों का मतलब हो। नई सुविधाओं पर।
वेन मोलिना

5
दुर्भाग्य से, री-फैक्टरिंग के लिए एक तरह के 'गुरिल्ला युद्ध' के दृष्टिकोण का उपयोग करने से कभी-कभी आप अपने आप को पैर में गोली मार सकते हैं। जब तक सिस्टम में इकाई / एकीकरण परीक्षणों का एक अच्छा सेट नहीं होता है, तब तक इसके खिलाफ लिखा जाता है (जो कि अगर यह बुरा है तो यह सबसे अधिक संभावना नहीं है) उन अनिवार्य रूप से बगों की शुरूआत का कारण बनेगा, जिनसे बचने के लिए क्यूए के माध्यम से पूरे सिस्टम परीक्षण की आवश्यकता होगी।
२०:१hole बजे ऐसिथेहोल २ '

1
@aceinthehole: बिल्कुल सही। यदि परीक्षण महंगा है, तो प्रबंधन किसी भी 'अनावश्यक' परिवर्तन को जोखिम में नहीं डालना चाहेगा, भले ही उनके बिना यह प्रणाली भविष्य के लिए अप्राप्य हो जाएगी।
केविन क्लाइन

2
@WayneM, और उन बेवकूफों को जो डब्ल्यूटीएफ को नहीं जानते थे कि वे परियोजना की शुरुआत में कर रहे थे अब वरिष्ठ प्रबंधक हैं। उस हिस्से को कभी मत भूलना!
HLGEM

58

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

"यह कोड बकवास है और पुनर्लेखन की आवश्यकता है" निश्चित रूप से आप पर वापस फेंकने जा रहे हैं, भले ही आप तकनीकी रूप से सही हों।

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

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

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


2
मजाकिया ... मुझे जोएल की साइट :-)
रॉबर्ट फ्रेंच

6
@ रॉबर्ट फ्रेंच: आपका प्रबंधक आपके पदों को पढ़ रहा है ...
डेव मार्कल

8
मजाक नहीं। यह मजाक करने की कोशिश नहीं है "क्या मेरे पास सब कुछ फिर से लिखने के लिए डेवलपर के 6 महीने का समय हो सकता है? अंतिम परिणाम ठीक वही होगा जो आज हमारे पास है, लेकिन शायद कुछ नए बग के साथ। ओह, और हम कई का उपयोग करने जा रहे हैं। वही डेवलपर्स जिन्होंने फिर से लिखने के लिए बकवास के वर्तमान स्टीमिंग ढेर को बनाया क्योंकि वे अब बेहतर जानते हैं। "
JohnFx

3
@ joshin4colours: <उद्धरण> हाँ, मुझे पता है, यह एक खिड़की को प्रदर्शित करने के लिए सिर्फ एक सरल कार्य है, लेकिन यह उस पर बहुत कम बाल और सामान उगाया है और कोई नहीं जानता कि क्यों। ठीक है, मैं आपको बताता हूँ कि क्यों: वे बग फिक्स हैं । ... इनमें से प्रत्येक कीड़े को मिलने से पहले वास्तविक-विश्व उपयोग के सप्ताह लग गए। ... जब आप कोड को फेंक देते हैं और खरोंच से शुरू करते हैं, तो आप उस सारे ज्ञान को दूर फेंक रहे हैं। </ उद्धरण>
मार्टिन

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

14

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

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

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

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

सबसे खराब दृष्टिकोण जो मैंने देखा है, वह विरासत प्रणाली से एक नवीनतम और सबसे बड़ी, सीधे एक महान छलांग बनाने की कोशिश करना है, उदाहरण के लिए, एक कामकाजी लेकिन एक VVC / क्लासिक ASP / COM + सिस्टम से MVC / Entity फ्रेमवर्क सिस्टम पर कूदना।


3
"सबसे पहले, आप एक प्रोग्रामर के रूप में काम करते हैं जब तक आप स्टार्ट-अप पर काम नहीं करते हैं, तब तक आपको नासमझ विरासत सामान मिल जाएगा और आप वह हैं जो मूल नासमझ विरासत कोड बनाता है।" मैं अपने स्टार्टअप में पहला प्रोग्रामर था। आठ बाद मैं अक्सर खुद को यह कहते हुए पाता हूं कि 'यह नासमझ कोड किसने लिखा है?', केवल यह जांचने और खोजने के लिए कि मैं दोषी पार्टी हूं।
जिम में टेक्सास

पुनरावृत्ति की गति पुनरावृत्ति की गुणवत्ता को धड़कती है। दूसरे शब्दों में, बहुत सारे छोटे-छोटे बदलाव करें, अक्सर, और अंत में आपको वही मिलेगा जहाँ आप होना चाहते हैं।
जसकॉन

11

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

(सवाल पर अज़कर की टिप्पणी से आंशिक रूप से विरोधाभास)


10
सिद्धांत रूप में, यह बहुत अच्छा होगा। व्यवहार में, इसका जवाब "नहीं, सीईओ Another Big Projectएक्स महीनों में किया जाना चाहिए" की तर्ज पर कुछ होगा । या "हमारे पास वाई नई सुविधाएँ हैं जिन्हें तुरंत करने की आवश्यकता है, हमारे पास पहले से ही काम करने वाले समय को ठीक करने का समय नहीं है"
वेन मोलिना

2
शायद ही कभी (अगर कभी) काम करता है। खासकर यदि आपके पास एक प्रबंधक है जो थोड़ी देर के लिए आस-पास है, क्योंकि उसने इस लाइन को केवल पहले देखा होगा ताकि इसे उड़ाया जा सके।
तायोनोर्क

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

मेरे अनुभव में, यह दृष्टिकोण अक्सर खारिज हो जाएगा। एक वैकल्पिक दृष्टिकोण कई बिग प्रोजेक्ट अनुमानों से 1.5 है और समय के 1 / 3rd को कोड को साफ करने में खर्च करते हैं।
JBRWilkinson

2
एक बहुत ही लगातार प्रतिक्रिया है "आपकी तनख्वाह को यह करने के लिए कौन निधि देगा?" यदि आपके पास कार्य का प्रत्यक्ष प्रायोजन नहीं है, तो आपको कंपनी को दीर्घकालिक निवेश करने की आवश्यकता होगी। या ऐसा करते हुए आप मुफ्त में काम करेंगे?

7

सॉफ्टवेयर पर जोएल पढ़ना शुरू करें (स्टैक एक्सचेंज के जोएल स्पोलस्की / संस्थापक) ...

सबसे पहली बात मैं जोएल टेस्ट करूंगा ।

यह आपको इसे प्रस्तुत करने की अनुमति देगा "जबकि मैं एक डेवलपर के रूप में सुधार करने के तरीकों की तलाश कर रहा था ... मैंने विकास के वातावरण के बारे में इस 12 प्रश्न परीक्षण पर ठोकर खाई, इसलिए मज़े के लिए मैंने उन्हें जवाब दिया कि मैं कहाँ काम करता हूं।" ... यह बदले में यह एक 3 पार्टी को रेखांकित करता है जो आपके कोड के साथ गलत है और आप व्यक्तिगत रूप से नहीं।

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

उम्मीद है की वो मदद करदे! प्रोग्रामिंग में आपका स्वागत है (कल कोड आमतौर पर बेकार है) ;-)


4
मुझे नहीं लगता कि यह पता है कि उन्हें प्रबंधन से कैसे संपर्क करना चाहिए।
पबबी

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

1
हां ... मैं इसे प्रस्तुत करते समय तीसरे पक्ष के दृष्टिकोण का उपयोग करने का सुझाव दे रहा था। मुझे नहीं लगता था कि वह विशेष रूप से अपने बॉस से बात करने के लिए कह रहा था।
रॉबर्ट फ्रांसीसी

4
यह जवाब शायद ही इतने नीचे वोटों का हकदार हो। पहला वाक्य +10 का हकदार है। प्रबंधन के पास आने वाली समस्या यह समझ रही है कि उनके लिए क्या महत्वपूर्ण है, जोएल, और यह जवाब, इस तरह की समस्या को इस कारण से देखते हैं कि क्यों और क्यों नहीं, व्यावसायिक दृष्टिकोण से, कोड को फिर से लिखा जाना चाहिए।
मटनज

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

7

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

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


निश्चित रूप से एक अच्छा विचार है और यह भी सच है
sdm350

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

यदि आप इसे बदलने के तरीकों का प्रस्ताव करते हैं तो आपको अधिक परिवर्तन और सम्मान मिलता है जिसमें इसके लिए दिखाने के लिए व्यापार (या नरम) व्यापार मूल्य के साथ बड़ी मात्रा में समर्पित समय शामिल नहीं होता है।


कोई / हाँ / हाँ। भाषा और औजारों की पसंद शायद ही कभी तकनीकी कारणों से की गई पसंद हो। (देखें: parashift.com/c++-faq-lite/big-picture.html#faq-6.5 ) वे ऐसे उपकरण हैं, जिन्हें कंपनी ने शुरू से ही इधर-उधर किया है। उत्पादकता में गिरावट के कारण किसी कंपनी या किसी टीम को पुन: टूलींग करने की संभावना नहीं है।
मार्टिन यॉर्क

1
योजना के लिए +1 और वृद्धिशील रूप से लागू करना। सब कुछ फिर से लिखना विफलता के लिए पूछ रहा है। समय के साथ छोटी जीत आत्मविश्वास पैदा करती है। चश्मा के लिए ... अधिकांश चश्मा आपको एक प्रोग्रामर के रूप में मिलता है, उन्हें परिष्कृत करने के लिए हमारी नौकरी की कमी होगी। हर बार एक समय में आप किसी ऐसे व्यक्ति द्वारा खराब हो जाते हैं जो अच्छा चश्मा लिखता है। जहां तक ​​प्रोग्रामर की बात है, आमतौर पर जल्दी से आगे बढ़ / पदोन्नत / एक बेहतर काम पाते हैं।
सोयलेंटग्रे

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

4

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

एक उदाहरण "कोड संधारणीय नहीं है" के लिए हो सकता है:

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

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

सौभाग्य। आपको इसकी आवश्यकता होगी।


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

3

"मैंने कॉलेज से नए सिरे से शुरुआत की" - आपके प्रश्न का उत्तर देना चाहिए।

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

प्रबंधन यह भी जानता है कि यह आपकी कंपनी की "काम" की परिभाषा का उपयोग करके काम करता है (रिपोर्ट नहीं करता है, जो भी दुर्घटनाग्रस्त हो जाता है, बेचता है, बेचता है)।

वे चाहते हैं कि आप कम से कम लागत पर कोड "काम" कर सकें। वे सब कुछ फिर से लिखने के लिए एक महंगी परियोजना का प्रस्ताव नहीं चाहते हैं।


आपकी पहली पंक्ति पूरी तरह से जूनियर्स के खिलाफ पक्षपातपूर्ण है। एक के लिए, आपको उसका अनुभव नहीं पता है इसलिए आप उसके सवाल का जवाब नहीं दे सकते। और इस तरह से सामान्यीकरण करना जूनियर्स के खिलाफ बेहद पक्षपाती है! मैं इस बारे में 20 साल से हूं और मैं गारंटी दे सकता हूं कि मैंने 'वरिष्ठ अज्ञानियों' की तुलना में अधिक जानकार 'newbies' देखे हैं।
जेच

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

2

व्यवसाय का मामला बनाना लगभग असंभव है क्योंकि आपका डिलिवरेबल काम करने वाला सॉफ्टवेयर है (जो उनके पास पहले से है) सुरुचिपूर्ण कोड नहीं।

इस तथ्य में जोड़ें कि सॉफ्टवेयर में पहले सुविधाओं के साथ बाजार में आने से बड़ा अवसर लागत है। यदि आप वास्तव में इसके बारे में सोचते हैं, तो निवेश पर दीर्घकालिक अदायगी की गारंटी नहीं है।

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


2

जैसे ही आप कर सकते हैं वैसे ही छोड़ दें (हो सकता है कि जितनी जल्दी आप नौकरी हॉपर की तरह दिखना न चाहें) छोड़ दें। तथ्य यह है कि वे कोड एक गड़बड़ है और लोग वहां रह रहे हैं इसका मतलब है कि आप गरीब डेवलपर्स के साथ काम कर रहे हैं। कोई भी सभ्य डेवलपर जो अपने काम के बारे में परवाह करता है वह इस तरह के बकवास पर लंबे समय तक काम नहीं करेगा।

जब तक आप बहुत स्पष्ट रूप से यह स्पष्ट रूप से प्रदर्शित नहीं कर सकते हैं तब तक एक पुनर्लेखन की संभावना तब होती है जब तक कि यह $ $ $ $ निवेश के लायक न हो।


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

1

प्रबंधन को कोड की परवाह नहीं है। वे बेचने के लिए एक उत्पाद होने के बारे में परवाह है।

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

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


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

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

"बिना अनुमति के कोड को साफ करें" - ऐसा कुछ तय करने की तरह लगता है जो टूट नहीं गया है।
जेम्स एंडरसन

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

0

एप्रोच प्रबंधन को इस तरह से आप दिखाते हैं कि आप कोड में बड़े बदलाव करने के बजट प्रभावों और परिवर्तनों को न करने के बजट प्रभावों को समझते हैं। मुझे एमिलियो का शब्दांकन पसंद आया।

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


0

यह मत करो।

स्क्रैच से एक बड़ी परियोजना को फिर से लिखना एक बड़ी गलती है।


बड़े रिश्तेदार हैं।
लुका

1
मेरी परिभाषा है: यदि आप इसे 5 दिनों में स्वयं नहीं लिख सकते हैं तो यह बड़ा है।
बजे सीज़र कैनसा

-1

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

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

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


-3

दो प्रकार के प्रबंधक होते हैं: जो आप समझते हैं कि आप क्या करते हैं और जो नहीं करते हैं। सॉफ्टवेयर को समझने का दिखावा करने वाले आपसे दुश्मनी करेंगे। जो केवल आप से नाराज नहीं हैं।

किसी भी मामले में, प्रबंधक सभी झूठे हैं, इसलिए उनके पास हर किसी को मानने के लिए एक मजबूत स्वभाव है।

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


+1 पर "प्रबंधक सभी झूठे हैं इसलिए उनके पास हर किसी को मानने के लिए एक मजबूत स्वभाव है"
ZJR

उसी पर -1; असत्य और अशुभ दोनों
जाप

@ जाप कई अध्ययन हैं जो शक्ति और सामाजिक वर्ग को बेईमानी से सहसंबंधित करते हैं। इसका मतलब है कि आप अपने -1 को वापस ले लेंगे? उदाहरण: msnbc.msn.com/id/35836844 blogs.discovermagazine.com/notrocketscience/2010/04/27/… news.sciencemag.org/sciencenow/2012/02/shame-on-the-rich.html
Joe

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

1
@ जो: आपके लिंक नहीं (शुरू) आपके दावे को साबित करते हैं कि "प्रबंधक सभी झूठे हैं"।
जाप
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.