क्या ब्रांड के नए सॉफ्टवेयर का निर्माण आमतौर पर अधिकांश प्रोग्रामिंग नौकरियों का एक प्रमुख हिस्सा है? [बन्द है]


63

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

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

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

क्या मै गलत हु? क्या मैं अधिकांश प्रोग्रामिंग नौकरियों का सही वर्णन कर रहा हूं, या अधिकांश प्रोग्रामर ऐसा महसूस करते हैं कि वे अक्सर नई चीजें बना रहे हैं?


11
@JamieTaylor आपके रूपक शब्दों में अनुवादित है, सवाल यह है कि क्या यह हमेशा किसी और के लेगो मॉडल को ठीक करने और एक नया बनाने के लिए विशिष्ट है?
कालेब

22
@ जो, हा! तो आप उन सभी का उत्पादन करने वाले व्यक्ति हैं! * # @ * &% विरासत प्रणाली हम हमेशा के लिए बनाए रखने के लिए हैं! ; -पी
पेटर

14
@ जो, हाँ मैं करता हूँ, बहुत बहुत धन्यवाद। हो सकता है कि अगर आप सिर्फ एक और अधिक यूनिट परीक्षण लिख सकते हैं, तो मैं पूरी तरह से संतुष्ट हो
जाऊंगा

8
@ जो, पुरानी कहावत को ध्यान में रखता है, जिसे मैंने विशेष रूप से उपयुक्त नहीं पाया है - वह यह है कि अब तक: "हमेशा कोड के रूप में अगर आपके कोड को लेने वाला अगला आदमी एक खतरनाक मनोरोगी था जो जानता था कि आप कहाँ रहते हैं"; -)
Péter Török

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

जवाबों:


66

सॉफ्टवेयर काम का एक बड़ा हिस्सा रखरखाव है। कोई भी काम पर रखने वाला प्रबंधक वास्तव में आपको यह नहीं बताएगा, लेकिन निश्चित रूप से यह मामला है।


13
यह सच है, लेकिन रखरखाव अभी भी महत्वपूर्ण है, और कभी-कभी बौद्धिक रूप से चुनौतीपूर्ण भी हो सकता है :)
joshin4colours

3
रखरखाव में कुछ भी गलत नहीं है। लेकिन लोगों को यह कम ग्लैमरस लगता है, इसलिए नौकरी के विवरण इसे कम करते हैं।
स्कॉट सी विल्सन

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

3
@omouse - कभी-कभी हाँ, लेकिन कभी-कभी यह मूल विनिर्देश को पूरा करने के लिए कार्यान्वयन में केवल धुंधले कीड़े को ठीक कर रहा है। लेकिन आप सही हैं - "रखरखाव" के रूब्रिक के तहत कई तरह की गतिविधियाँ शामिल हैं।
स्कॉट सी विल्सन

@omouse, redesign और refactoring के अर्थ भी हैं और उन चीजों को कवर नहीं करते हैं जिन्हें हम आम तौर पर "mantainance" कहते हैं। यदि कुछ सॉफ़्टवेयर अब पदावनत समारोह, या एक बाहरी एपीआई परिवर्तन का उपयोग करता है, तो आप जिस चीज़ को करने जा रहे हैं, वह न तो रीडिज़ाइन है और न ही रिफ़ॉर्मिंग।
cbrandolino

59

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

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

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


15
+1 के लिए "कोई भी जो लगातार छोटे ग्रीनफील्ड प्रोजेक्ट्स पर काम कर रहा है, वास्तव में सक्षम होने का दावा कर सकता है"
मैट्नज़

1
"एक छोटा ग्रीनफील्ड प्रोजेक्ट" क्या है?
चावल का आटा कुकीज़

@RiceFlourCookies: ग्रीनफील्ड एक ऐसे कार्य के लिए एक शब्द है जो पूरी तरह से नया है। इस मामले में, एक परियोजना खरोंच से शुरू हुई।
स्टीवन एवर्स

@RiceFlourCookies और छोटे होते हुए भी , एक व्यक्ति द्वारा किए जा सकने वाले प्रोजेक्ट्स को यथोचित रूप से छोटा माना जा सकता है।
स्कॉट सी विल्सन

23

विरासत प्रणाली सफल हैं। वे प्रारंभिक विकास प्रक्रिया से बच गए, जहां 50% परियोजनाएं विफल हो जाती हैं (सफलता के बाद भी नए सिरे से परिभाषित किया गया है!)। वे बदलते कारोबारी माहौल से बचे। वे शायद युवा भोले प्रोग्रामर द्वारा दस प्रस्तावों के बारे में बच गए जो कि जावा में पूरी चीज को फिर से लिखना या उस समय जो कुछ भी फैशनेबल था। वे बहुत भाग्यशाली थे कि जो भी विभाग, कंपनी या एजेंसी है जो सॉफ्टवेयर की सेवा कर रहा था वह विभिन्न बजट कटौती, पुनर्गठन, विलय आदि से बच गया।

शायद कम है तो लिखे गए 5% सॉफ्टवेयर अभी भी दस साल बाद चलेंगे।

तो इसके बारे में विलाप करने के बजाय इसे ऐसे डार्विनियन सफलता की कहानी पर काम करने का सौभाग्य और वास्तविक दुनिया में क्या और क्यों काम करता है, सीखने का अवसर के रूप में देखें।


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

@marek यह वास्तव में दोनों हो सकता है।
निकोलस

8
तथ्य यह है कि कुछ जीवित रहता है इसका मतलब यह नहीं है कि यह इष्टतम या अच्छा है। इसका मतलब केवल यह है कि यह "अच्छा पर्याप्त" है कि किसी ने अभी तक इसे अपने दुख से बाहर नहीं रखा है। प्रकृति में प्रमुख चयनात्मक बल प्रतियोगिता है; जब थोड़ी प्रतिस्पर्धा होती है, तो आप कुछ बहुत ही डरावने जीव पा सकते हैं। प्रतियोगिता सॉफ्टवेयर में भी काम करती है, लेकिन आंतरिक प्रणालियों में आमतौर पर ज्यादा प्रतिस्पर्धा नहीं होती है। नतीजा यह है कि आंतरिक सिस्टम अक्सर अधिकतम तक खराब होते हैं।
कालेब

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

14

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

सफल सॉफ्टवेयर प्रोजेक्ट आम तौर पर नए प्रोजेक्ट के रूप में बनाए जाने की तुलना में बहुत अधिक समय बिताते हैं, इसलिए यह बिल्कुल आश्चर्य की बात नहीं है कि आपको पूरी तरह से "नया" सामान करने के लिए नहीं मिलता है।

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


7
"किसी और के असफल प्रयास" - विरासत प्रणाली डार्विन की सफलता की कहानियां हैं, विफल परियोजनाओं को बनाए रखा नहीं जाता है!
जेम्स एंडरसन

2
@JamesAnderson प्वाइंट लिया गया, लेकिन तकनीकी सफलता सॉफ़्टवेयर पारिस्थितिकी में एकमात्र चुनिंदा बल नहीं है। किसी प्रोजेक्ट के आधे-अधूरे कुत्ते को किसने नहीं देखा है जो प्रबंधकों के लिए महत्वपूर्ण है लेकिन शुरू करने के लिए बहुत दूर माना जाता है?
कालेब

6

यह इस बात पर निर्भर करता है कि आप किस काम की तलाश में हैं।

मैंने केवल एक बार एक शुद्ध सॉफ्टवेयर उत्पाद कंपनी के लिए काम किया है, जहां मैंने एक छोटे से स्टार्ट-अप टीम में उनके एकल सोना चढ़ाया हुआ आवेदन पर काम किया है।

अन्यथा मैंने प्रौद्योगिकी कंपनियों के लिए काम किया है जिन्हें अपने आंतरिक आरएंडडी या बाहर के उत्पादों का समर्थन करने के लिए सॉफ्टवेयर की आवश्यकता होती है।

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

नकारात्मक पक्ष यह है कि आप लागत का हिस्सा हैं, उत्पाद का हिस्सा नहीं हैं। इसलिए मेरे पास प्रोजेक्ट्स डिब्बाबंद हैं क्योंकि 'हम सॉफ्टवेयर नहीं कर रहे हैं "/" सॉफ्टवेयर कोर बिजनेस नहीं है "= यह आश्चर्यजनक है कि कंपनियों को लगता है कि वे इसे संचालित करने के लिए कोई सॉफ्टवेयर के साथ $ 100 K मशीन टूल बेच सकते हैं!


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

@SpencerRathbun मुझे इससे भी अधिक आश्चर्यचकित करता है कि जब आप उन्हें कस्टम सॉफ्टवेयर बनाने का अनुमान देते हैं तो वे तुरंत आपसे सवाल करना शुरू करते हैं और पूछते हैं, "क्या उनका मुफ्त खुला स्रोत सॉफ्टवेयर नहीं है जो हमें मुफ्त में कस्टम एक्स सुविधा दे सकता है?"
maple_shaft

7
@maple_shaft और भी मजेदार है जब वे कहते हैं "हम $ 10K के लिए एक्स खरीद सकते हैं और यह सामान्य उद्देश्य समाधान हमारी कस्टम समस्या को पूरी तरह से बिना किसी सेट के फिट करेगा! BTW आप इसे प्राप्त करने और चलाने और सभी समस्याओं / के प्रभारी होंगे ! हमारे द्वारा खरीदे गए सॉफ़्टवेयर में बग आपकी गलती हैं। "
स्पेंसर रथबुन

3
@SpencerRathbun आप जीतते हैं, यह सबसे खराब स्थिति है।
मेपल_शफ्ट

5

विरासत कोड को किसी और की गंदगी को लगातार साफ करने के बजाय, इसे कई नई परियोजनाओं पर काम करने के अवसर के रूप में देखें।

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

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

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

यह आश्चर्यजनक है कि थोड़ा मानसिक कैलेस्थेनिक्स पूरी तरह से दैनिक कार्य के प्रति आपकी धारणा और आनंद को बदल सकता है। ;-)


4

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

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

में अधिक दफ्तर में बीटा वहाँ कैसे गूगल के 20% निजी परियोजना प्रणाली काम करता है के बारे में एक सवाल है

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

20% परियोजनाएं होने से मैं अनुमान लगाता हूं कि Google डेवलपर Google की परियोजनाओं को बेहतर बनाने के लिए रहने का मन नहीं करेगा क्योंकि वह अभी भी कुछ नया करने की शुरुआत में वहां होने का मजा ले सकता है।


2

आप अपना समय नई कार्यक्षमता बनाने और मौजूदा कोड की कार्यक्षमता को बदलने के लिए खर्च करेंगे ताकि नए विनिर्देशन के अनुरूप हो।

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


2

मैं कहूंगा कि यह उस कंपनी पर निर्भर करता है जिस पर आप काम करते हैं।

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

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

मेरी वर्तमान नौकरी घर में वापस विकास के लिए है, एक सुरक्षा कंपनी के लिए जो अलार्म सिग्नल सत्यापन और अन्य "वर्चुअल गार्ड" सेवाएं प्रदान करने के लिए वीडियो निगरानी और ऑडियो फीडबैक का उपयोग करती है। यह क्षेत्र तेज़ी से बढ़ रहा है और अभी भी विकसित हो रहा है; नए उपकरण हर समय बाजार में प्रवेश करते हैं, नए ग्राहकों को साइन अप किया जाता है जो चाहते हैं कि हम नई चीजें करें, और मौजूदा उत्पाद अब उल और सरकार के शासनों को पूरा करने के लिए नहीं मिलते हैं। इस नौकरी का 99% "एकीकरण" है; नया सॉफ्टवेयर लिखना जो पहले कभी मौजूद नहीं था, एक नए लेकिन पहले से मौजूद उपकरण या सॉफ्टवेयर के साथ काम करने के लिए एक और पुराने या पहले से मौजूद पुराने उपकरण या सॉफ्टवेयर के साथ काम करना, ताकि हम दोनों के साथ नई चीजें कर सकें।


1

मैं कहूंगा कि यह आपकी भूमिका की प्रकृति पर बहुत निर्भर करता है।

मैं एक छोटी टीम का हिस्सा हूं और इस तरह, मुझे जो कुछ भी बनाना है, उसे बनाए रखना और समर्थन करना है।

5 साल पहले मैंने जो कुछ किया था, वह "नया" था - अब मैं कहूंगा कि मौजूदा कोड का रखरखाव मेरा कम से कम आधा समय लेगा, जिसमें मौजूदा सिस्टम का 25% "नया" संस्करण होगा।

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


1
  1. यह निर्भर करता है कि आपकी नौकरी की स्थिति कितनी खतरनाक है; ;-)

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

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

  2. नए सॉफ्टवेयर का निर्माण हमेशा बहुत लुभावना होता है । सच्चाई यह है कि इसे सही तरीके से करना कठिन है । अनुरक्षण कोड करना कोई तुच्छ कार्य नहीं है।

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

बहुत से लोग इसे सही नहीं कर रहे हैं, इसलिए हमें उनका कोड बनाए रखना चाहिए और इसे उचित स्थिति में लाना चाहिए। ;-)

अच्छी खबर यह है कि यदि आप कंपनी में लंबे समय से हैं, तो आप एक प्रभाव डाल सकते हैं कि नया कोड कैसे लिखा जाता है :-)


1

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

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


1

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

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

क्या मैं एक सुझाव दे सकता हूं कि आप वापस धक्का दें और कुछ नए विकास कार्य के लिए कहें? और अगर आपका नियोक्ता केवल रखरखाव करता है तो शायद आपको आगे बढ़ने की आवश्यकता है?


0

मैं कहूंगा कि यह बहुत सारे कारकों पर निर्भर करता है। आप कहां काम करते हैं, आप किस तरह के उत्पाद बनाते हैं, आपकी टीम कैसी है, आदि।

मैंने अपनी कंपनी में जो चार साल काम किया है, मैं कहूंगा कि मेरा 70-80% समय कुछ नया बनाने में व्यतीत होता है। संभवतः इसका 50-60% बड़ी परियोजनाओं पर खर्च किया जाता है जो पूरी तरह से नया कोड है, जबकि उस समय के शेष को मौजूदा कार्यक्षमता में वृद्धि पर खर्च किया जाता है।

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


0

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

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

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


रखरखाव मोड बहुत समय पहले हुआ था ... आपको बस अब आपकी सहायता के लिए उपकरणों की आवश्यकता है।

मुझे खुशी है कि मेरे पास भावनाएं नहीं हैं क्योंकि वे इस बिंदु पर केवल नकारात्मक उत्तर होने से आहत हो सकते हैं :(
एरॉन एनोडाइड

खैर, आप पूछे गए सवाल का जवाब नहीं देते।

0

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

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

इस प्रकार की चीज़ के लिए 5-7 साल के प्रतिस्थापन चक्र की अपेक्षा करें। उदाहरण के लिए, 2020 तक, मुझे उम्मीद है कि WPF (क्लाइंट) / जावा (सर्वर) सॉफ्टवेयर मैं अब लिख रहा हूँ पुराने तकनीक और कुछ नए द्वारा प्रतिस्थापित किया जाएगा।

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