अप्रचलित कोड को चरणबद्ध करने के लिए सर्वोत्तम अभ्यास क्या हैं?


9

मुझे एक अप्रचलित विधि को चरणबद्ध करने की आवश्यकता है। मैं [Obsolete]विशेषता से अवगत हूं । क्या Microsoft के पास ऐसा करने के लिए अनुशंसित सर्वोत्तम अभ्यास मार्गदर्शिका है?

यहाँ मेरी वर्तमान योजना है:

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

B. पुरानी पद्धति को अप्रचलित चिह्नित करें।

C. क्योंकि कार्यान्वयन बदल रहा है (विधि हस्ताक्षर नहीं), मुझे अधिभार बनाने के बजाय विधि का नाम बदलने की आवश्यकता है। इसलिए, उपयोगकर्ताओं को उचित तरीके से अवगत कराने के लिए मैं एक संदेश को [Obsolete]विशेषता में जोड़ने की योजना बनाता हूं । यह हिस्सा मुझे परेशान करता है, क्योंकि मैं जो एकमात्र बदलाव कर रहा हूं, वह कनेक्शन स्ट्रिंग से विधि को डिकूपिंग कर रहा है। लेकिन, क्योंकि मैं एक नई असेंबली नहीं जोड़ रहा हूं, इसलिए मुझे इसके आसपास कोई रास्ता नजर नहीं आ रहा है।

परिणाम:

[Obsolete("Please don't use this anymore because it does not implement IMyDbProvider.  Use XXX instead.")];
        /// <summary>
        /// 
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        public static Dictionary<string, Setting> ReadSettings(string settingName)
        {
            return ReadSettings(settingName, SomeGeneralClass.ConnectionString);
        }

        public Dictionary<string, Setting> ReadSettings2(string settingName)
        {
            return ReadSettings(settingName);// IMyDbProvider.ConnectionString private member added to class.  Probably have to make this an instance method.
        }

जवाबों:


5

Microsoft डेवलपर्स को यह बताने के लिए [अप्रचलित] विशेषता का उपयोग करता है कि विधि, संपत्ति या वर्ग को पदावनत किया जाता है, और भविष्य के रिलीज में इसे बदला जा सकता है (या बिल्कुल समर्थित नहीं)।

यह आपके एपीआई के उपयोगकर्ताओं को सूचित करने के लिए आपको कम से कम एक रिलीज चक्र देता है कि उनकी सुविधा "दूर जा रही है" और भविष्य में उनके सॉफ़्टवेयर के रिलीज में इसके संदर्भ को दूर करने के लिए है।

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

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


Microsoft की प्रथा आम तौर पर अगले प्रमुख रिलीज में एक हटा दी गई चीज को हटाने के लिए है। इसके विपरीत, जावा कभी भी हटाए गए चीजों को नहीं हटाता है - इसलिए यह आपके ऊपर है।
स्कॉट सी विलसन

हम असेंबलियों को एप्लिकेशन स्तर से परे नहीं करते हैं (कई समाधानों के साथ 1 विशाल अनुप्रयोग)। इसे इस तथ्य के साथ जोड़िए कि किसी भी विधानसभा पर निर्भर समाधानों के # अपरिभाषित हैं। मैं एक ऐसे एप्लिकेशन का परीक्षण नहीं कर सकता जिसके बारे में मुझे जानकारी नहीं है। लेकिन, अगर मैं एक ऐसा बदलाव करता हूं जिसके कारण एक ऐसा अनुप्रयोग टूट जाता है जिसके बारे में मुझे जानकारी नहीं है ... तो यह मेरी गलती है। यही कारण है कि मैंने विधि का नाम बदला। इसलिए, अब तक मैंने जो भी पढ़ा है, उसके बारे में इससे बेहतर कोई तरीका नहीं है।
पी। ब्रायन। मैके

4

क्योंकि कार्यान्वयन बदल रहा है (विधि हस्ताक्षर नहीं), मुझे अधिभार बनाने के बजाय विधि का नाम बदलने की आवश्यकता है।

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

यदि आप अनिश्चित हैं तो इस पद्धति के अंतर्निहित कार्यान्वयन को बदलने से काम चलेगा, कार्यान्वयन को बदलने से पहले और बाद में इकाई परीक्षणों के साथ व्यवहार को सत्यापित करें।


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

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

मैं खुद को आग में फेंक रहा हूँ। मैं बल्कि उस मूल कोड के साथ रहना चाहूँगा जिसे मैंने पोस्ट किया था। इस तरह कोई भी मुझे 3:00 पर नहीं बुलाता है कि उत्पादन कोड क्यों टूट गया। फिर, कोड अप्रचलन को हल करने के लिए डेवलपर्स पर निर्भर रहें क्योंकि वे अपने चेतावनी झंडे की मरम्मत करते हैं। यदि वे उस बिंदु पर इसे ठीक नहीं करते हैं, तो जब कनेक्शन स्ट्रिंग्स उन पर अपनी विफलता को विफल करना शुरू करते हैं, तो उनके चेतावनी झंडे की मरम्मत नहीं करने के लिए ... मेरा।
पी। ब्रायन.मैकी

जब भी आप नया कोड लिखते हैं तो आप समस्याओं को पेश करने का जोखिम उठाते हैं। टेस्ट आपको इतना भयभीत किए बिना रिफ्लेक्टर देगा। डर मन का कह्ननी हे। इसके अलावा आप सिर्फ अपरिहार्य देरी कर रहे हैं; वे अपने फोन पर अब से एक जोड़े को पुन: जोड़ने के लिए "2" जोड़ेंगे और यदि यह काम नहीं करता है तो आपको एक ही फोन कॉल मिलेगा।
ब्रायन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.