सॉफ़्टवेयर का जीवनकाल: आप कितनी बार स्क्रैच से शुरू करने की अपेक्षा करते हैं?

Question

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

आखिरकार, मेरे कुछ ग्राहकों के पास लकड़ी के मुख्य फ्रेम हैं जो लगभग 20 वर्षों तक रहे हैं, और वे इतने व्यस्त हैं कि वे हमेशा के लिए जी सकते हैं।

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

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

शायद वे परियोजनाएं हैं जो 3 साल तक जीवित रहती हैं। या कम।

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

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

यहां आपके अनुभव क्या हैं?

Answer 1

जिस टीम पर मैं काम कर रहा हूं वह 6 साल तक एक ही वेब एप्लिकेशन विकसित कर रहा है, और दृष्टि में कोई अंत नहीं है। उस समय, यह क्लासिक एएसपी से एएसपी.NET 1.1 से एएसपी.नेट 2.0 तक चला गया है, इसलिए विभिन्न मॉड्यूल में वृद्धिशील रीराइट्स आया है, लेकिन कभी-कभी स्क्रैच रीराइट की तरह कुछ भी नहीं है। हर बार कोई कहता है कि अगर हम शुरू कर सकते हैं तो यह कितना अच्छा होगा, लेकिन हमारे पास 60,000+ उपयोगकर्ता हैं: कोई भी तरीका नहीं है कि वे 12 से 18 महीने का इंतजार कर रहे हैं, जबकि उनकी अपडेट की गई कार्यक्षमता या सुविधाएं एक पर बैठेगी शेल्फ।

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

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

Answer 2

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

3 साल वास्तव में कम लगता है।

Answer 3

बेशक यह प्रौद्योगिकी डोमेन पर निर्भर करता है, लेकिन तीन साल थोड़ा कम लगता है। कुछ लोग कहते हैं कि परिपक्व होने के लिए अच्छे सॉफ्टवेयर के लिए ten years तक लगते हैं।

मैंने कुछ परियोजनाएं देखी हैं जहां हितधारकों का कहना है कि "हम छह महीने में [बड़े सिस्टम] को फिर से लिख सकते हैं/प्रतिस्थापित कर सकते हैं" और वे अभी भी कई सालों बाद कोशिश कर रहे हैं।

Answer 4

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

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

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

Answer 5

कम अक्सर बेहतर।

लेकिन ईमानदारी से, 3 साल बहुत कम है। विशेष रूप से औसत के लिए।

वास्तविकता यह है कि आप आम तौर पर केवल से शुरू जब आप पूरी तरह विकसित नहीं कर सकते हैं, जब आप कर रहे हैं तकनीकी ऋण इतनी अधिक है कि यह तकनीकी रूप से दिवालिया हो जाना बेहतर है। और फिर भी आप अक्सर अपने कर्ज को फिर से कर सकते हैं।

लंबी अवधि की सफलता की कुंजी आपके technical debt को हर समय कम से कम रखने की कोशिश करना है।

Answer 6

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

Answer 7

मैं कभी नहीं कहूंगा।

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

आपके पास डेटा भी है जो आपको पोर्ट करना होगा।

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

Answer 8

मुझे लगता है कि 3 साल शायद सही है।

1. एक नई प्रमुख प्रणाली (ईआरपी, सीआरएम, इत्यादि।) लागू किया गया है और पुराने ऐप को बदलने के लिए इसमें "एकीकृत" मॉड्यूल है।

2. एक ही है, लेकिन कोई एकीकृत एप्लिकेशन - लेकिन मौजूदा एप्लिकेशन अनुकूलनीय (। लोगों को, छोड़ दिया प्रौद्योगिकी बदल गया है, वर्तमान आईटी नीतियों को बदल दिया है, उन मौजूदा एप्लिकेशन पसंद नहीं है) नहीं है

3. आपकी जरूरतों के लिए इसे अनुकूलित करने के लिए आपने मूल ऐप प्राप्त किया है, कंपनी गायब हो गई है।

4. या आप उनके साथ अब भी अच्छी तरह से नहीं मिलते हैं।

5. मौजूदा अनुप्रयोग के लिए प्रौद्योगिकी

6. (ढांचा विक्रेता/माइक्रोसॉफ्ट/सलाहकार/उद्योग विशेषज्ञ/नए आईटी प्रबंधक है, जो प्रबंधन के कान है। के अनुसार) "हम समाप्त कर रहे हैं" अप्रचलित "है (विंडोज 95/विंडोज 98/विंडोज 2000/विंडोज एक्सपी/एनटी) और हमें अपने ऐप्स में मिलान तकनीक की आवश्यकता है "।

7. "हमने (ऐप संस्करण एन) से बहुत कुछ सीखा है और हम दूसरे/तीसरे/चौथे/एन + 1 वें समय में बहुत बेहतर प्रदर्शन करेंगे।"

8. डेवलपर्स/आईटी मैनेजर/डिवीजन वीपी/परामर्श कंपनी के लिए नौकरी औचित्य।

9. उपयोगकर्ता इसे नफरत करते हैं।

10. हमने प्रतिद्वंद्वी द्वारा अधिग्रहित/अधिग्रहित एक प्रतिद्वंद्वी/अधिग्रहण किया है और उनका बेहतर है।

यह सिर्फ एक शुरुआत है।

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

Answer 9

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

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

मैंने जिन अनुप्रयोगों को लिखा है या योगदान दिया है, वे अभी भी 5, 10, 15 और 20 साल बाद मजबूत हैं। अपवाद के बिना ऐसा इसलिए है क्योंकि हितधारकों/उपयोगकर्ता इस प्रक्रिया में भारी शामिल थे, हमने भविष्य में भविष्य में बदलावों की उम्मीद की, हमने सही समय पर ऐसा करने का समय लिया, और हमने यह सुनिश्चित किया कि रखरखाव टीम ने वही किया है।

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

Answer 10

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

बेशक

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

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

Answer 11

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

Answer 12

मुझे अभी भी उत्पादन में 1 9 वर्ष का कोड मिला है, हालांकि सड़क के नीचे भारी संशोधन के साथ।

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

Answer 13

ऐसा लगता है कि यहां बातचीत बातचीत के बीच औसत समय के आसपास केंद्रित है। लेकिन कई प्रणालियां व्यावसायिक कारणों से असफल हो जाती हैं या अप्रचलित हो जाती हैं और कभी भी लिखी नहीं जाती हैं। कई वेबसाइटों को हर 2-3 साल में फिर से डिजाइन किया जाता है। मोबाइल ऐप्स में केवल 6 महीने का आधा जीवन होने की सूचना दी गई है।

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