"जब तक यह काम करता है" आदर्श है? [बन्द है]


23

मेरा और हालिया प्रश्न देखें: क्या प्रोग्रामिंग एक दौड़ के रूप में नीचे की ओर पेशा है?

मेरी पिछली दुकान में एक प्रक्रिया नहीं थी। एजाइल का अनिवार्य रूप से मतलब था कि उनके पास अपनी परियोजनाओं को विकसित करने या प्रबंधित करने के बारे में बिल्कुल भी योजना नहीं थी। इसका मतलब था "हे, यहाँ एक टन का काम है। इसे दो सप्ताह में कर। हम तेजी से उदास और फुर्तीले हैं।"

उन्होंने सामान जारी किया जिसमें उन्हें पता था कि समस्याएं थीं। उन्हें परवाह नहीं थी कि चीजें कैसे लिखी जाती हैं। कई डेवलपर्स होने के बावजूद कोई कोड समीक्षाएं नहीं थीं। उन्होंने सॉफ्टवेयर जारी किया जिसे वे छोटी गाड़ी के रूप में जानते थे।

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

इसलिए अनिवार्य रूप से, मेरी धारणा यह है: प्रोग्रामिंग निम्नलिखित को उबालता है:

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

मैंने हमेशा खुद से कहा है कि अगली नौकरी मैं एक बेहतर दुकान लेने जा रहा हूं। ऐसा कभी नहीं होता। अगर यह ऐसा है, तो मुझे अटका हुआ लगता है। प्रौद्योगिकियां हमेशा बदलती रहती हैं; यदि यहां एकमात्र पेशेवर विकास नवीनतम एमएस प्रेस प्रौद्योगिकी पुस्तक पढ़ रहा है, तो आपने 10 वर्षों में क्या बनाया है, लेकिन विभिन्न प्रौद्योगिकियों का सतही ज्ञान? मुझे चिंता है:

  1. पेशेवर मानकों के लिए सबसे अच्छा तरीका है
  2. इस स्थिति में सार्थक ज्ञान और अनुभव को कैसे विकसित किया जाए

3
यह कौन सा देश है?

3
अपरिहार्य दिलबर्ट
2007/

5
<quot> चंचल का अनिवार्य रूप से मतलब है कि उनके पास अपनी परियोजनाओं को विकसित करने या प्रबंधित करने के बारे में बिल्कुल भी योजना नहीं थी </ उद्धरण> यह चुस्त नहीं है। यह कुछ भी नहीं है।
मार्टिन यॉर्क

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

2
मुझे लगता है कि लोग सवाल का जवाब याद कर रहे हैं। मेरी बात यह है कि मैंने यहां जो डायनामिक वर्णन किया है वह वास्तव में कौशल की आवश्यकता नहीं है या डेवलपर्स के कौशल का नेतृत्व करने की आवश्यकता है। यह ज्ञान के सतही स्तर को विकसित करने के लिए नेतृत्व करता है जो सहन नहीं करता है। लेखाकार, वकील आदि अनुभव विकसित करते हैं जो उनके प्रशिक्षण को अधिक मूल्यवान बनाता है। मैंने यहाँ जो डायनामिक देखा है, उसे देखते हुए, हमारे लिए ऐसा नहीं है।
q303

जवाबों:


8

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

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

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


2
+1 विशेष रूप से, इसके लिए:remember why we're all doing this: to solve our customer's problems.
जॉर्ज मारियन

21

>> मेरी पिछली नौकरी में, जब तक यह काम करता है, लोगों का रवैया ठीक था।

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

  • प्रदर्शन की समस्याएं
  • सिस्टम के किसी भी अन्य हिस्सों की तुलना में अधिक बग पाए गए थे
  • जब वे इस हिस्से पर काम करते हैं तो डेवलपर्स अधिक समय बिताते हैं
  • आदि।

7
+1I strongly believe that to rewrite something there should be clear evidence why do we need this
जॉर्ज मारियन

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

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

4
@ मिचेल: रिफैक्टरिंग बेहद जरूरी है। और इसलिए यह है कि कोड काम करता है। और ऐसा है कि यह जल्दी से हो जाता है, क्योंकि आपके प्रतियोगी जीतेंगे। यह सीमित संसाधनों के साथ किया जाना भी बेहद महत्वपूर्ण है क्योंकि ऐसा करने के लिए बहुत कम पैसा और बहुत सी अन्य चीजें हैं। वहाँ कुछ चीजें हैं जो बेहद महत्वपूर्ण हैं, और व्यापार उन सभी के बीच संतुलन बनाने के बारे में है। एक आसान काम नहीं है, लेकिन सफल लोगों, जैसे कि Google, हमेशा " जल्दी से कुछ पाने , बाद में पॉलिश करें" रवैया की ओर झुकाव करने लगते हैं ।
जूनस पुलकका

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

14

फुर्तीली सॉफ्टवेयर जारी करने के लिए किसी भी मानव निर्णय के लिए एजाइल जिम्मेदार नहीं है; मनुष्य हैं।

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

समस्या यह है कि है पूर्णतावाद पर ले जाया जाता विलंब करने के लिए और विलंब होता है सामान्यता

यही कारण है कि व्यापार बाजार की तरह सामानों में प्राथमिकता देगा और मूल्य को शीघ्रता से और पूर्वानुमेय गति से वितरित करने के लिए फुर्तीली का उपयोग करेगा ।

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

उनके उद्देश्यों और योजनाओं (वे उन्हें प्राप्त करने में आपकी सहायता करने के लिए उन्होंने आपको काम पर रखा ) पर गठबंधन करके , आप यह समझने की बेहतर स्थिति में होंगे कि आप अपने और व्यक्तिगत उद्देश्यों पर ध्यान केंद्रित करने के बजाय उनके लिए कैसे योगदान दे सकते हैं।

मुझे यकीन है कि understandउनके मूल्य के लिए प्रयास करने से , आप अपना हिस्सा बना पाएंगे, और यह एक उपयोगी सहयोग की शुरुआत होगी।

और अगर आपको पता है कि वे नहीं जानते कि वे क्या कर रहे हैं, तो आपका एकमात्र विकल्प छोड़ना होगा


2
मैं विशेष रूप से इस पंक्ति को पसंद करता हूं:The problem is that perfectionism leads to procrastination and procrastination leads to mediocrity.
जॉर्ज मैरियन

1
पियरे इस साइट के योदा की तरह है!
ओज

3

यह सब इस बात पर निर्भर करता है कि आप क्या निर्माण कर रहे हैं। यदि आप एक माइक्रोसाइट का निर्माण कर रहे हैं जो केवल एक महीने के लिए ऑनलाइन होगी, और आपके पास इसे बनाने के लिए नौ दिन हैं: तो हाँ, जब तक यह काम करेगा पर्याप्त होगा।

यदि आप FA-18 प्रणाली के लिए फ्लाई-बाय-वायर एल्गोरिदम लिख रहे हैं, तो बेहतर होगा कि इसे यथासंभव पूरी तरह से बनाया जाए।

तो जैसा कि अधिकांश प्रौद्योगिकी जवाबों के साथ होता है ... यह निर्भर करता है।


2

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

मुझे लगता है कि 80/20 नियम यहां लागू होता है। मूल रूप से, आपको भद्दे 80% के साथ डालने और 20% में अपना रास्ता बनाने की आवश्यकता है। हालांकि, यह महसूस करें कि यहां तक ​​कि उन्हें व्यापार बंद करना होगा। व्यवसाय में, यह आमतौर पर मायने नहीं रखता है कि आपके पास यह बिल्कुल सही है। यह मायने रखता है कि आपके पास अभी है।


2

यदि यहां एकमात्र पेशेवर विकास नवीनतम एमएस प्रेस प्रौद्योगिकी पुस्तक पढ़ रहा है, तो आपने 10 वर्षों में क्या बनाया है, लेकिन विभिन्न प्रौद्योगिकियों का सतही ज्ञान?

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

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


2

मैंने कुछ समय के लिए एक दुकान पर इस तरह से काम किया, जहां यह उन्हें पकड़ रहा था। ज्ञात बग के साथ दो या तीन साल पुराने अनुप्रयोग थे जो वे सचमुच हल नहीं कर सकते थे। लेआउट चौड़ाई और ऊंचाइयों के लिए चल रही गणना के साथ 4,000 लाइन लंबी लूप के बारे में सोचें। एक उदाहरण में किसी समस्या को ठीक करने के लिए कोड का एक टुकड़ा तय करने से बीस मुद्दे कहीं और हो जाएंगे क्योंकि पूर्व डेवलपर्स के पास मैजिक नंबरों के साथ गणना परिणामों को मनमाने ढंग से समायोजित करके इसी तरह के मुद्दे थे। कोड को विषाक्त के अलावा और कुछ भी नहीं बताया जा सकता है।

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

मैंने सोचा था कि यह मेरे प्रबंधक के लिए एक महत्वपूर्ण मोड़ होगा लेकिन मुझे जो कुछ भी मिला वह पीठ पर एक थप्पड़ था और उन्होंने अनिवार्य रूप से मुझसे कहा कि "आपका तरीका मुझे भी लगता है।"

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


2
सहमत ... आपके द्वारा काम किए जाने वाले स्थान पर किसी के दिमाग को बदलने की कोशिश करने का कोई मतलब नहीं है जब तक कि आपको एक वरिष्ठ / लीड डेवलपर के रूप में नहीं लाया जाता है जहां वे आपसे यह उम्मीद कर रहे हैं। मुझे लगता है कि मैं उस जगह पर काम कर रहा हूं जिसका आपने वर्णन किया है कि आपने पहले काम किया था और मैं जहाज से कूदने के लिए तैयार हूं उम्मीद है कि हरियाली चराई के लिए
programmx10

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

1

मुझे अभी भी उम्मीद है, कि अर्थव्यवस्था में एक तरह की विकासवादी प्रक्रिया है, जो जल्दी या बाद में ऐसी कंपनियों को व्यापार से बाहर कर देती है। लेकिन शायद तकनीकी प्रगति की उच्च गति बहुत सारे नए निशानों का उत्पादन करती है, इसलिए कमजोर प्रतियोगी अभी भी पर्याप्त "भोजन" पा सकते हैं।

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


1

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

अपने आलोचकों को उनका जवाब था: "मुझे पता है कि मेरा काम करता है।"


1

एक बहुत अच्छा मानदंड पेरेटो सिद्धांत है

मुझे 80-20 नियम वाली एक परियोजना का अनुभव है और इसने बहुत अच्छा काम किया है। मुझे लगता है कि इस सवाल का जवाब "आप अपनी पूर्णतावाद के लिए रेखा कहां खींचते हैं" भी सहायक हो सकता है।

"पेरेटो सिद्धांत" शब्द भी पेरेटो दक्षता को संदर्भित कर सकता है। पेरेटो सिद्धांत (80-20 नियम के रूप में भी जाना जाता है, महत्वपूर्ण कुछ का कानून, और कारक स्पार्सिटी का सिद्धांत) बताता है कि, कई घटनाओं के लिए, लगभग 80% प्रभाव 20% कारणों से आते हैं। व्यवसाय प्रबंधन के विचारक जोसेफ एम। जुरान ने सिद्धांत का सुझाव दिया और इसका नाम इतालवी अर्थशास्त्री विलफ्रेडो पेरेटो के नाम पर रखा, जिन्होंने 1906 में देखा कि इटली में 80% भूमि पर 20% आबादी का स्वामित्व था; उन्होंने इस सिद्धांत को विकसित किया कि उनके बगीचे में 20% मटर की फली में 80% मटर था। यह व्यापार में अंगूठे का एक सामान्य नियम है; उदाहरण के लिए, "आपकी बिक्री का 80% आपके ग्राहकों के 20% से आता है"। गणितीय रूप से, जहां प्रतिभागियों के पर्याप्त बड़े सेट के बीच कुछ साझा किया जाता है, वहाँ 50 और 100 के बीच एक नंबर k होना चाहिए जैसे कि "k% प्रतिभागियों द्वारा (100 - k)% लिया जाता है"। संख्या k 50 से भिन्न हो सकती है (समान वितरण के मामले में, यानी 100% आबादी के पास समान शेयर हैं) लगभग 100 (जब प्रतिभागियों की एक छोटी संख्या लगभग सभी संसाधन के लिए होती है)।गणितीय रूप से संख्या 80% के बारे में कुछ खास नहीं है, लेकिन कई वास्तविक प्रणालियों के वितरण में मध्यवर्ती असंतुलन के इस क्षेत्र के आसपास कहीं है। पेरेटो सिद्धांत केवल पारेटो दक्षता से संबंधित है, जिसे उसी अर्थशास्त्री ने भी पेश किया था। Pareto ने जनसंख्या के बीच आय और धन के वितरण के संदर्भ में दोनों अवधारणाओं को विकसित किया।

स्रोत से लिंक करें


यह बहुत अच्छा है लेकिन यह प्रश्न से कैसे संबंधित है? क्या आप कह रहे हैं कि 20% कार्यस्थल 80% खराब सॉफ़्टवेयर उत्पन्न करते हैं?
कर्क ब्रॉडहर्स्ट

नहीं, अगर सॉफ्टवेयर 80% काम करता है तो यह ठीक है। स्वीकृत त्रुटि दर 20% है।
अमीर रज़ाई

0

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

कोई अपराध नहीं है, लेकिन एक प्रबंधक के रूप में मैंने उस कथन को कहीं की तर्ज पर पढ़ा:

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

यदि यह आपका अपना कोड है जिसके बारे में आप शिकायत कर रहे हैं - आपके पास खड़े होने के लिए बहुत कुछ नहीं है।

अद्यतन करें

मैं समझता हूं कि यह पीओवी अलोकप्रिय है। लेकिन, मुझे नहीं लगता कि यह एक पेशेवर डेवलपर की जिम्मेदारियों और दृष्टिकोणों के साथ असंगत है।

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

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

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

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

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


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

8
मैं इस जवाब को नीचा दिखाना चाहता हूं ताकि बहुत दर्द हो। लेकिन मैं नहीं कर सकता ... यह वास्तव में है कि प्रबंधक कैसे सोचते हैं। यह विकास टीम पर निर्भर है कि वह किन शर्तों को स्वीकार कर सकती है। यह कहते हुए कि "फिर से लिखना" भले ही काम करता है, हर बार मार्क की प्रतिक्रिया को ट्रिगर करने वाला है। शायद "जमना" या "स्थिर करना" या "खत्म करना" कहना कम झंझट होगा। प्रबंधकों को यह महसूस करना होगा कि वे अपूर्ण कोड के साथ उत्पादन में चले गए हैं, और यह उनके ऊपर है कि क्या वे नौकरी खत्म करना चाहते हैं; ऐसा नहीं करने की लागतों के बारे में उन्हें समझाने के लिए डेवलपर्स पर निर्भर है।
जेफ स्नेहाट

1
@ जफ - मौके पर! एक बुद्धिमान सहकर्मी ने एक बार मुझसे कहा था "उन्हें यह कहने का अवसर मत दो, यह सब इस बात पर निर्भर करता है कि आप प्रश्न को कैसे वाक्यांश देते हैं"।
ozz

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

0

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

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

निचले स्तर की प्रोग्रामिंग के लिए, यदि आप अपने काम से संतुष्टि प्राप्त नहीं कर सकते हैं, तो शायद एक ओपन सोर्स प्रोजेक्ट देखने का समय है?


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

0

q303, मैं आपके सवाल का रोचक लगा और आप इस मिल सकती है महसूस किया प्रोग्रामर्स प्रश्न पढ़ने, कैसे प्रबंधकों को समझाने के लिए डेवलपर्स तकनीकी कर्ज को संबोधित जाने के लिए के बारे में लायक।

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

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