ऑफ-किनारे बग फिक्सिंग

Question

यदि किसी भावी नियोक्ता ने आपको बताया कि वे "बग फिक्सिंग को आउटसोर्स करते हैं क्योंकि डेवलपर्स को फिक्सिंग बग से नफरत है", तो आप क्या सोचेंगे? आपकी चिंताएँ क्या हो सकती हैं?

Comments

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

— रोब

एक भयानक विचार की तरह लगता है।

— एंड्रेस एफ।

@AndresF। +1। यह एक ऐसा वातावरण तैयार करेगा जहां देवता सिर्फ दीवार पर बकवास फेंकते हैं और आशा करते हैं कि यह चिपक जाएगा। अगर यह नहीं है, तो उनकी समस्या नहीं है?

— MrFox

Answer 1

हमारे अपने कीड़े को ठीक करना वास्तव में हमें एक बेहतर डेवलपर बनाता है । और यह मेरे लिए बहुत सुखद क्षण है। खासकर जब वे अच्छी तरह से रिपोर्ट किए जाते हैं।

यदि वे बग को ठीक करना पसंद नहीं करते हैं, तो समस्या कहीं और है।

मुझे लगता है कि समस्या यह है कि बग कैसे प्रबंधन द्वारा खराब किए जाते हैं या खराब डिजाइन निर्णयों और / या (यूनिट) परीक्षण द्वारा खराब होते हैं, जिससे बग ठीक हो जाते हैं।

आउटसोर्सिंग बग फिक्सिंग शायद बात को बदतर बना देगा।

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

जब तक अपतटीय लोग तटवर्ती लोगों की जगह लेते हैं।

Comments

Lol आप लोगों से बाहर निकलने से डरना पसंद करते हैं Notcha

— Aditya P

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

— न्यूटोपियन

Answer 2

छोड़ो , भाग जाओ ... उपवास करो और कभी पीछे मुड़कर मत देखो ...

मैंने ऐसी कंपनी के लिए काम किया है, उन्हें लगा कि वे स्मार्ट हैं,

• अरे, हम सब उन्हें बग मिल गया है, लेकिन हमारे वरिष्ठ शिकायत करते हैं कि वे कीड़े को ठीक करने में बहुत समय बिताते हैं।

• चलो एक अपतटीय कार्यालय खोलें और दूसरों को इससे निपटने दें।

एक प्रबंधक के लिए जो वास्तव में एक अच्छी योजना की तरह लगता है और देवता आखिरकार अगली सबसे अच्छी चीज़ बनाने के अधिक दिलचस्प कार्य से निपटने के लिए मुक्त हो गए !!

हो ... लेकिन रुको ...

दो साल के बाद, वे अपने मुख्य कार्यालय में 5 देवों की एक टीम से गए, जिन्होंने इसे 2 की एक टीम को सौंप दिया जो नए सामान और 30 की एक टीम बनाते हैं जो बग्स को ढूंढते हैं और उन्हें ठीक करते हैं।

तुम्हें पता है कि ... बग फिक्सिंग टीम संघर्ष कर रही है, वे नहीं रख सकते।

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

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

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

यह पेपर बैग प्रबंधन पद्धति है।

एक रेलवे पर खड़े हो जाओ, एक ट्रेन के आने की प्रतीक्षा करो, जब आप इसे देखते हैं, तो अपने सिर पर एक पेपर बैग रखो और ... POOF .. ट्रेन चला गया !! जादू !

Answer 3

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

पर्याप्त रूप से मुआवजा नहीं दिया जा रहा है क्योंकि उन्हें अतिरिक्त डेवलपर्स को रखना होगा वांछनीय नहीं है।

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

मेरा एक हिस्सा ऐसा महसूस करता है कि समस्याएँ पैदा करने वाले उन्हें ठीक करने वाले होने चाहिए या पहली जगह पर बग पैदा करने से बचने के लिए कोई प्रोत्साहन नहीं होना चाहिए।

Answer 4

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

Answer 5

यदि किसी भावी नियोक्ता ने आपको बताया कि वे "बग फिक्सिंग को आउटसोर्स करते हैं क्योंकि डेवलपर्स को फिक्सिंग बग से नफरत है", तो आप क्या सोचेंगे? आपकी चिंताएँ क्या हो सकती हैं?

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

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

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

एक दोष हमेशा एक बदलाव के कारण होता है, और आमतौर पर बग जो भी परिवर्तन की शुरुआत की जिम्मेदारी है। बग की प्रकृति और इसके संकल्प को समझने के लिए मूल से बेहतर कौन है?

यदि यह दुनिया भर में प्रत्यायोजित है, तो यह कैसे सुनिश्चित करें कि मूल लेखक ऑफशोर इंजीनियर के लिए उपलब्ध है?

क्या वह भी उपलब्ध हो जाएगा, ऑफशोर इंजीनियर को छोड़कर, जिसके पास बग्स और डेडलाइन का एक बैकलॉग के अलावा कुछ नहीं है, लेकिन मेट्रोपोल से कोई समर्थन नहीं है ? किस प्रकार का बग फिक्स एक व्यक्ति संभवतः प्रदर्शन की उम्मीद कर सकता है? कौन अपने कीड़े ठीक करता है? और क्या मेट्रोपोल के डेवलपर्स को बग फिक्सिंग पोस्टमार्टम के माध्यम से सीखने से रोकता है?

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

संक्षेप में, भाग जाओ।

Comments

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

— डैन रे

@ दान - हां, आपका कथन कहीं अधिक सही है। ऐसा कोई द्वंद्ववाद मौजूद नहीं है।

— luis.espinal

Answer 6

क्या वे वास्तव में ऑफ-शोर जूनियर डेवलपर्स के एक झुंड की उम्मीद करते हैं जो वरिष्ठ डेवलपर्स कोड का एक गुच्छा ठीक करने में सक्षम हो? यह एक नर्स की जाँच करने की तरह सभी neuroligists काम करते हैं और इसे फिर से करना जहां उसने गलतियाँ की हैं। बुरा विचार!

Answer 7

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

टूटा हुआ कोड फिक्स करना कोड लिखने की प्रक्रिया का हिस्सा है, इससे आपको 6 महीने पहले आपने क्या गलत किया, इसकी बेहतर समझ है, इसलिए आप एक ही गलती नहीं करते हैं, अगर कोई दूसरा डेवलपर आपकी गलतियों को ठीक करता है तो आप उसे कैसे रोक सकते हैं बग बार-बार होने से?

Answer 8

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

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

Comments

+1 अब तक का सबसे खराब काम है। ऐसा लगता है कि वे परियोजना में उस राजस्व का पर्याप्त उपयोग नहीं करते हैं।

— रामहुंड

"भावी नियोक्ता" बिट के अलावा <LOL

— ग्रेग बी

मैं "पिछले नियोक्ता" वाक्यांश को नोटिस करता हूं। बधाई हो।

— डेविड थोरले

@ रामहाउंड, डेविड, ग्रेग, यह एक बेहतर जगह थी जब मैंने शुरुआत की, मैंने दिसंबर के अंत में जगह छोड़ दी (मेरी 5 वीं वर्षगांठ के तुरंत बाद)। जब से मुझे काम पर रखा गया था तब से किसी को काम पर नहीं रखा गया था, और पिछले 2 वर्षों में, 6 डेवलपर्स ने नौकरी छोड़ दी है। प्रस्थान करने के लिए नवीनतम 11 साल हो गए थे।

— तंगुरेना

Answer 9

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

Comments

अच्छा बिंदु, किसी और ने उस कोण की परिकल्पना नहीं की है।

— ग्रेग बी

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

— रामहुंड

यदि बग फिक्स को स्रोत नियंत्रण में जांचा जाता है तो उन्हें आसानी से किसी अन्य टीम द्वारा किसी अन्य शाखा में meged किया जा सकता है। यह कोई बड़ी बात नहीं है।

— स्टीव

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

— न्यूटोपियन

Answer 10

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

Answer 11

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

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

Answer 12

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

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

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