2008-11-20 18 views
5

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

+0

क्या आप एक अनुभवी व्यक्ति के रूप में मुझे समझा सकते हैं कि यह समुदाय विकी पोस्ट क्यों नहीं है? – badbadboy

+0

क्योंकि यह एक वैध सवाल है? सामुदायिक विकी सबकुछ पर लागू नहीं है, और मुझे इसमें शामिल नहीं होने के लिए कोगस में कोई दोष नहीं है। –

उत्तर

10

जबकि आपने डेवलपर के दृष्टिकोण से यह पूछा, मुझे लगता है कि यह आपके द्वारा विकसित सॉफ्टवेयर के संदर्भ में एक और दिलचस्प सवाल होगा। तो मैं इसके बजाय उस सवाल का जवाब देने जा रहा हूं। :)

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

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

एक दिलचस्प बात यह है कि इंटेल के संक्रमण के साथ क्लासिक पर्यावरण गायब हो गया, लेकिन कोई भी वास्तव में परवाह नहीं करता क्योंकि उनके पास मैक ओएस 9 से संक्रमण के लिए पिछले 5 साल थे। इसलिए अंततः विरासत प्रणाली के लिए समर्थन छोड़ना संभव है जब तक आपके पास नई प्रणाली में माइग्रेट करने का आसान तरीका हो और आपके उपयोगकर्ताओं को ऐसा करने के लिए पर्याप्त समय दें।

0

"महत्वपूर्ण परिवर्तन" को परिभाषित करें। अगर मैं व्यापक रूप से तैयार होते हैं, तो भी बदलावों के साथ बदलाव किया जा सकता है, "बदलाव & प्रतिस्थापित करें" के साथ परिवर्तन किया जा सकता है।

हालांकि, I ऐसा करेगा। किसी भी कंपनी के लिए मैंने काम किया है मौजूदा कोड में किसी भी बदलाव पर झटका होगा।

1

यह इस बात पर निर्भर करता है कि आपको किस वातावरण का समर्थन करने की आवश्यकता है और तीसरे पक्ष के औजारों का उपयोग किस प्रकार किया जा सकता है जो संगत हो सकता है या नहीं।

उदाहरण के लिए, जहां मैं काम करता हूं, हमने वीएस2005 से वीएस200008 में सभी को अपग्रेड किया है, हमारे बीआई समूह को छोड़कर SQL सर्वर BI उपकरण VS2008 के साथ संगत नहीं थे। एक बार अपडेट होने के बाद, वे वीएस -2008 में अपग्रेड हो गए।

वीएस specficially को देखते समय, ध्यान रखें कि VS2008 .NET 2.0, .NET 3.0, और .NET 3.5 को लक्षित कर सकता है। चाल यह जानना है कि यह वास्तव में .NET 2.0 SP1 और .NET 3.0 SP1 को लक्षित करता है। इस प्रकार, आईडीई को अपग्रेड करने के लिए आपको अपने कोड में बदलाव करने की आवश्यकता नहीं है।

1

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

मुझे लगता है कि अगर हम एक बेहतर दुनिया की उम्मीद कर रहे हैं, तो हमें लगातार बदलाव के लिए खुला होना चाहिए जब तक यह उद्योग सुपर परिपक्व न हो जाए। (हालांकि हमारे जीवन समय में नहीं हो सकता है :))

1

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

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

2

घर परियोजनाओं के लिए, पीछे की संगतता वास्तव में महत्वपूर्ण नहीं है। कार्यालय/उद्यम के लिए, यह बिल्कुल महत्वपूर्ण है।

3

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

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

+3

मुझे संदेह है कि आप वास्तव में इसका मतलब नहीं है कि जैसे ही आप इसे डालते हैं। उदाहरण के लिए, सी # 2 सी # 1 के साथ 100% पिछड़ा संगत नहीं है। यह करीब है, लेकिन यह 100% नहीं है। आपके तर्क से कोई भी VS2005 या VS2008 के साथ नहीं जाना चाहिए था। –

+0

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

संबंधित मुद्दे