समय सीमा समाप्त होने के बाद संकलित कोड को रोकना [बंद]

Question

मेरी टीम में हम एक बड़ी अखंड परियोजना (पूरे वर्गों, विधियों, आदि) में बहुत सारे पुराने सामानों की सफाई कर रहे हैं।

उस सफाई कार्य के दौरान मैं सोच रहा था कि क्या एक तरह का उद्घोषणा है या सामान्य से अधिक पुस्तकालय के प्रशंसक @Deprecated। यह @FancyDeprecatedसफल यदि आप पुराने अप्रयुक्त कोड साफ नहीं है के बाद एक विशेष तिथि बीत चुकी है से परियोजना के निर्माण को रोकने चाहिए।

मैं इंटरनेट पर खोज कर रहा हूं और नीचे वर्णित क्षमताओं के साथ कुछ भी नहीं मिला:

• किसी विशेष तिथि से पहले हटाए जाने वाले कोड में रखने के लिए एक एनोटेशन, या कुछ समान होना चाहिए
• उस तिथि से पहले कोड संकलित हो जाएगा और सब कुछ सामान्य रूप से काम करेगा
• उस तारीख के बाद कोड संकलित नहीं होगा और यह आपको एक संदेश देगा जो आपको समस्या के बारे में चेतावनी देगा

मुझे लगता है कि मैं एक गेंडा की खोज कर रहा हूं ... क्या किसी भी प्रोग्राम भाषा के लिए कोई समान तकनीक है?

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

Comments

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

— isanae

प्लान बी ठोस लगता है। जोड़े गए फायदों के साथ आप यूनिट टेस्ट में टिप्पणी कर सकते हैं कि क्यों यह पदावनत है। स्रोत कोड में टिप्पणी जोड़ने से बड़े मोनोलिथ में पठनीयता में मदद नहीं मिलेगी

— dwana

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

— शमौन बी

इसे @ Deprecated_RemoveMe_2018_06_01 करें और फिर 2018-06-01 को एनोटेशन को हटा दें। वोइला, एनोटेशन का उपयोग करने वाले आपके सभी कोड अब संकलित नहीं होंगे! (क्योंकि एनोटेशन नहीं पाया जाता है)

— immibis

भविष्य में, एक नए काम पर रखने वाले डेवलपर पूछेंगे: बिल्ड सर्वर पर जनवरी 2016 तक का समय क्यों है? और जो आदमी 10y के लिए वहां है वह उसे बताएगा कि यह आवश्यक है या यादृच्छिक स्थानों में निर्माण टूट जाता है। आह।

— विल्बर्ट

Answer 1

मुझे नहीं लगता कि यह एक उपयोगी विशेषता होगी जब यह वास्तव में संकलन को प्रतिबंधित करता है। जब 01/06/2018 को कोड के बड़े हिस्से को संकलित नहीं किया जाएगा, जो कि एक दिन पहले संकलित किया गया था, तो आपकी टीम उस एनोटेशन को फिर से हटा देगी, कोड साफ हो गया या नहीं।

हालाँकि, आप कोड की तरह कुछ कस्टम एनोटेशन जोड़ सकते हैं

@Deprecated_after_2018_07_31

और उन एनोटेशन के लिए स्कैन करने के लिए एक छोटा उपकरण बनाएं। (Grep में एक साधारण एक लाइनर यह कर देगा, यदि आप प्रतिबिंब का उपयोग नहीं करना चाहते हैं)। जावा की तुलना में अन्य भाषाओं में, "ग्रीपिंग" के लिए उपयुक्त एक मानकीकृत टिप्पणी, या एक प्रीप्रोसेसर परिभाषा का उपयोग किया जा सकता है।

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

Comments

@ बर्गी: हे, यह सिर्फ एक उदाहरण है, ओपी संस्करणों या दिनांक टैग का उपयोग कर सकता है, जो भी वे अपने नियंत्रण में पसंद करते हैं।

— Doc Brown

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

— jpmc26

@jpaugh मैं उन कार्यों को करने के लिए नए टूल बनाने में घंटों (नोट, समय = पैसा) नहीं डूबने की सिफारिश कर रहा हूं जो आप पहले से ही मौजूदा टूल के साथ कुशलता से कर सकते हैं, जो भी उपकरण हो सकते हैं।

— jpmc26

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

— डॉक्टर ब्राउन

यदि आप अपने उदाहरण में तारीख के लिए सिर्फ YYYY-MM-DD आदेश का उपयोग करेंगे, तो मैं +1 करूंगा, क्योंकि मैंने केवल अस्पष्ट देखा है ?? - ?? - YYYY आदेश दर्द और गलतफहमी का कारण बनता है।

— mtraceur

Answer 2

यह एक टाइम बम के रूप में जाना जाने वाला एक फीचर होगा । यह समय बम बनाने के लिए नहीं है।

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

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

Comments

+1 यह आपको काटेगा। महीनों बाद। शुक्रवार को जैसे ही आप एक आपातकालीन तैनाती करने की कोशिश कर रहे हैं। और यह एक लंबा सप्ताहांत है, इसलिए इसके बारे में कुछ भी जानने वाले सभी लोग कार्यालय से बाहर हैं। यह मत करो।

— रोजर लिप्सकॉम्ब

इस बात से सहमत। अप्रचलन एक संगठनात्मक मुद्दा है, न कि एक कोडिंग मुद्दा। मैं अभी भी एक Apple में प्लग कर सकता हूं] [और लिखता हूं, BASIC, मुझे कुछ भी नहीं रोक रहा है। लेकिन, क्या मैं करना चाहूंगा ?

सही समाधान, आपके "संगठित और जागरूक" दिशा के साथ जा रहा है, अपने बग ट्रैकिंग सिस्टम में एक बग को बढ़ाने के लिए है, "टिप्पणी में ऐसे सुझाए गए समय" के साथ "ऐसे <और ऐसे> निकालें"। और फिर 6 महीनों में जब बग रिव्यू के आसपास यह पता लगाने के लिए कि बग्स को अगली रिलीज में क्या तय करना चाहिए, अगर वह समय सीमा आसन्न है, तो आप कहते हैं "यह ऐसा करने का समय है"। यह बुनियादी परियोजना प्रबंधन है।

— ऑर्बिट

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

— ऑर्बिट

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

— Stevoisiak

Answer 3

C # में आप ObsoleteAttributeनिम्नलिखित तरीके से उपयोग करेंगे :

• संस्करण 1 में, आप सुविधा को शिप करते हैं। एक विधि, वर्ग, जो भी हो।
• संस्करण 2 में, आप मूल सुविधा को बदलने के इरादे से एक बेहतर सुविधा शिप करते हैं। आप इस सुविधा पर एक अप्रचलित विशेषता डालते हैं, इसे "चेतावनी" पर सेट करते हैं, और इसे एक संदेश देते हैं जो कहता है कि "यह सुविधा संक्षिप्त है। इसके बजाय बेहतर सुविधा का उपयोग करें। इस लाइब्रेरी के संस्करण 3 में, जो इस तरह के और पर जारी किया जाएगा। एक तारीख, इस सुविधा का उपयोग एक त्रुटि होगी। " अब सुविधा के उपयोगकर्ता अभी भी इसका उपयोग कर सकते हैं, लेकिन नई सुविधा का उपयोग करने के लिए अपने कोड को अपडेट करने का समय है।
• संस्करण 3 में, आप एक चेतावनी के बजाय एक त्रुटि होने के लिए विशेषता को अपडेट करते हैं, और संदेश को अपडेट करने के लिए कहते हैं "यह सुविधा संक्षिप्त है। इसके बजाय बेहतर सुविधा का उपयोग करें। इस लाइब्रेरी के संस्करण 4 में, जो इस तरह के और इस तरह से जारी किया जाएगा। एक तारीख, यह सुविधा फेंक देगी। " जो उपयोगकर्ता आपकी पिछली चेतावनी पर ध्यान केंद्रित करने में विफल रहे, उन्हें अभी भी एक उपयोगी संदेश मिलता है जो उन्हें बताता है कि समस्या को कैसे ठीक किया जाए, और उन्हें इसे ठीक करना होगा, क्योंकि अब उनका कोड संकलन नहीं करता है।
• संस्करण 4 में, आप इस सुविधा को बदलते हैं ताकि यह कुछ घातक अपवाद फेंके, और संदेश को यह कहने के लिए बदल दें कि यह सुविधा पूरी तरह से अगले संस्करण में हटा दी जाएगी।
• संस्करण 5 में, आप पूरी तरह से सुविधा को हटा देते हैं, और अगर उपयोगकर्ता शिकायत करते हैं, तो ठीक है, आपने उन्हें निष्पक्ष चेतावनी के तीन रिलीज चक्र दिए, और वे हमेशा संस्करण 2 का उपयोग कर सकते हैं यदि वे इसके बारे में दृढ़ता से महसूस करते हैं।

यहां विचार यह है कि प्रभावित उपयोगकर्ताओं के लिए जितना संभव हो सके एक ब्रेकिंग परिवर्तन किया जाए, और यह सुनिश्चित करने के लिए कि वे लाइब्रेरी के कम से कम एक संस्करण के लिए सुविधा का उपयोग करना जारी रख सकते हैं।

Comments

मेरा मानना ​​है कि यह सही तरीका है, लेकिन मैं एक चीज बदल दूंगा ... जो कि उपयोगकर्ताओं द्वारा शिकायत किए जाने पर "यदि उपयोगकर्ता शिकायत करते हैं" तो स्वैपिंग होगी

— Liath

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

— केविन कैथार्ट

@ केविनकार्ट: यह एक अच्छा बिंदु है; शायद वहाँ एक और चरण वारंटेड है! मैं टेक्स्ट अपडेट करूंगा।

— एरिक लिपर्ट

वास्तव में, यदि आप सेम वीयर कर रहे हैं, तो आप X +0 में पूरी तरह से हटाए जाने के लिए सीधे वर्जन XY0 (किसी भी डेप्रिसिएशन को मामूली रिलीज होना चाहिए) से हटा सकते हैं। मैं कहूंगा कि इसे थोड़ा और पकड़ना अच्छा है, (X + 2.0.0?), लेकिन यह पांच-चरण की प्रक्रिया शायद लिली को आकर्षित कर रही है। "चेतावनी" के बाद अगला चरण "घातक त्रुटि" होना चाहिए (क्योंकि हटाए गए सुविधा को त्रुटि-जनरेट कोड के साथ बदल दिया गया है)। के बाद से libfoo.so.2और libfoo.so.3एक-दूसरे को ठीक से रह सकते हैं, अपने नीचे की ओर जब तक वे इस पर गए हो पुराने पुस्तकालय का उपयोग कर रख सकते हैं।

— मोंटी हार्डर

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

— एरिक लिपर्ट

Answer 4

आपने गलत समझा है कि "पदावनत" का अर्थ क्या है। पदावनत का अर्थ है:

प्रयोग करने योग्य लेकिन अप्रचलित माना जाता है और सबसे अच्छा परहेज किया जाता है, आमतौर पर क्योंकि इसे उलट दिया गया है।

_{ऑक्सफोर्ड डिक्शनरी}

परिभाषा के अनुसार, एक चित्रित सुविधा अभी भी संकलित होगी।

आप किसी विशिष्ट दिनांक पर सुविधा को निकालना चाहते हैं। कोई बात नहीं। जिस तरह से आप करते हैं कि आप उस तारीख को हटा रहे हैं ।

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

Comments

रुचि है कि क्या downvoter से असहमत है।

— jpmc26

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

— मैथ्यू पढ़ें

और यह भी सुनिश्चित करें कि दस्तावेज में क्लास / लिब बना हुआ है जैसा कि मूल्यह्रास और / या संस्करण Xx में हटा दिया गया है

— फिल एम

Answer 5

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

इसके अलावा, यह संकलन से पहले एक या दो साल पहले मेरी मशीन की घड़ी को सेट करने के लिए एक तुच्छ वर्कअराउंड की तरह लगता है।

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

संपादित करें: मैं देखता हूं कि आप अपने प्रश्न में "पुराने अप्रयुक्त कोड" देखें। यदि कोड वास्तव में अप्रयुक्त है , तो इसे अपदस्थ करने का कोई मतलब नहीं है। बस इसे हटा दें।

Comments

अब तक का सर्वश्रेष्ठ उत्तर, हो सकता है कि तनाव को दूर करते हुए कोड को अपने उत्तर में हल करने का सबसे अच्छा तरीका हो। पाठ उत्तरों की पिछली दीवार को स्क्रॉल करना आसान हो सकता है

— क्लिंट

Answer 6

मैंने पहले कभी इस तरह की सुविधा नहीं देखी है - एक एनोटेशन जो किसी विशेष तिथि के बाद प्रभावी होना शुरू करता है।

@Deprecatedपर्याप्त हो सकता है, लेकिन। सीआई में चेतावनियों को पकड़ें, और यदि कोई मौजूद हो तो निर्माण को स्वीकार करने से इनकार कर दें। यह कंपाइलर से आपके बिल्ड पाइपलाइन तक जिम्मेदारी को शिफ्ट करता है, लेकिन इसका फायदा यह है कि आप (सेमी) आसानी से कई चरणों में बिल्ड पाइपलाइन को बदल सकते हैं।

ध्यान दें कि यह उत्तर आपकी समस्या को पूरी तरह से हल नहीं करता है (उदाहरण के लिए डेवलपर्स की मशीनों पर स्थानीय बिल्ड अभी भी सफल होगा, हालांकि चेतावनियों के साथ) और यह मानता है कि आपके पास एक सीआई पाइपलाइन स्थापित और चल रही है।

Answer 7

आप कैलेंडर या टूडू सूचियों की तलाश कर रहे हैं ।

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

अनुस्मारक कि कोड को ठीक करने की आवश्यकता है, अच्छे और आवश्यक हैं। कभी-कभी इन अनुस्मारक में वास्तविक दुनिया की समय सीमा होती है, इसलिए उन्हें टाइमर पर रखना आवश्यक हो सकता है।

लक्ष्य लोगों को लगातार याद दिलाना है कि यह मुद्दा मौजूद है और किसी दिए गए समय सीमा को तय करने की आवश्यकता है - एक विशेषता जो एक विशिष्ट समय में निर्माण को तोड़ती है, वह न केवल ऐसा करती है, बल्कि यह सुविधा स्वयं एक ऐसा मुद्दा है जिसकी आवश्यकता है एक निश्चित समय सीमा तय करने के साथ।

Comments

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

Answer 8

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

जैसा कि दूसरों ने बताया है, यदि आपने इस तंत्र का उपयोग करके "समय सीमा" बनाई है, तो यह एक अलग समय में खिलाने और उस "समय सीमा" को तोड़ने के लिए तुच्छ है। वही अधिक विस्तृत तंत्र के लिए जाता है जैसे NTP सर्वर ("सुरक्षित" कनेक्शन पर भी, क्योंकि हम अपने स्वयं के प्रमाणपत्र, प्रमाणपत्र प्राधिकारी या क्रिप्टो लाइब्रेरीज़ को पैच कर सकते हैं)। पहले तो यह प्रतीत हो सकता है कि ऐसे व्यक्ति आपके तंत्र के आसपास काम करने के लिए गलती कर रहे हैं, लेकिन ऐसा हो सकता है कि यह स्वचालित रूप से और अच्छे कारणों के लिए किया गया हो । उदाहरण के लिए, यह एक अच्छा विचार है कि प्रतिलिपि प्रस्तुत करने योग्य बनाता है , और इस तरह के गैर-निर्धारक प्रणाली कॉल को स्वचालित रूप से रीसेट / अवरोधन करने में मदद करने के लिए उपकरण। libfaketime वास्तव में यही करता है,सभी फ़ाइल के टाइमस्टैम्प्स को सेट करता है 1970-01-01 00:00:01, Qemu का रिकॉर्ड / रिप्ले फीचर फेक सभी हार्डवेयर इंटरैक्शन, आदि।

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

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

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

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

"पुल" दृष्टिकोण के साथ एक महत्वपूर्ण सवाल यह है कि क्या निर्भरता संस्करण "इकाई" ( कार्यक्षमता की ) के रूप में गिना जाता है , और इसलिए परीक्षण के योग्य है; या क्या यह सिर्फ एक "निजी" कार्यान्वयन विवरण है, जिसे केवल वास्तविक इकाई ( कार्यक्षमता ) परीक्षणों के हिस्से के रूप में प्रयोग किया जाना चाहिए । मैं कहता हूं: यदि निर्भरता के संस्करणों के बीच अंतर वास्तव में आपके आवेदन की एक विशेषता के रूप में गिना जाता है, तो परीक्षण करें (उदाहरण के लिए, जाँच कर रहा है कि पायथन संस्करण है> = = 3.x)। यदि नहीं, तो नहींपरीक्षण जोड़ें (चूंकि यह भंगुर, असंक्रामक और अत्यधिक प्रतिबंधात्मक होगा); यदि आप लाइब्रेरी को नियंत्रित करते हैं तो "पुश" रूट पर जाएं। यदि आप लाइब्रेरी को नियंत्रित नहीं करते हैं, तो बस जो भी संस्करण प्रदान किया गया है उसका उपयोग करें: यदि आपके परीक्षण पास हो जाते हैं तो यह स्वयं को प्रतिबंधित करने के लायक नहीं है; अगर वे पास नहीं होते हैं, तो यह आपकी "समय सीमा" है!

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

इनमें से प्रत्येक अलग-अलग परिस्थितियों में लागू होगा।

Answer 9

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

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

Comments

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

— पीटर ए। श्नाइडर

Answer 10

एक आवश्यकता बिल्ड में समय की धारणा शुरू करना है। C, C ++, या अन्य भाषाओं / बिल्ड सिस्टमों में, जो C-C प्रीप्रोसेसर ^{1 का} उपयोग करते हैं , किसी को बिल्ड समय में प्रीप्रोसेसर के लिए परिभाषित के माध्यम से एक टाइम स्टैम्प पेश कर सकता है CPPFLAGS=-DTIMESTAMP()=$(date '+%s'):। यह संभवतः एक मेकफाइल में होगा।

कोड में एक उस टोकन की तुलना करता है और यदि समय लगता है तो त्रुटि का कारण बनता है। ध्यान दें कि एक फ़ंक्शन मैक्रो का उपयोग उस मामले को पकड़ता है जो किसी ने परिभाषित नहीं किया था TIMESTAMP।

#if TIMESTAMP() == 0 || TIMESTAMP() > 1520616626
#   error "The time for this feature has run out, sorry"
#endif

वैकल्पिक रूप से, कोई समय आने पर प्रश्न में कोड को "परिभाषित" कर सकता है। यह कार्यक्रम को संकलित करने की अनुमति देगा, बशर्ते कोई इसका उपयोग न करे। कहो, हमारे पास एक api, "api.h" को परिभाषित करने वाला हेडर है, और हम old()एक निश्चित समय के बाद कॉल करने की अनुमति नहीं देते हैं :

//...
void new1();
void new2();
#if TIMESTAMP() < 1520616626
   void old();
#endif
//...

इसी तरह का निर्माण संभवतः old()कुछ स्रोत फ़ाइल से फ़ंक्शन बॉडी को समाप्त कर देगा ।

बेशक यह मूर्खतापूर्ण सबूत नहीं है; एक बस TIMESTAMPशुक्रवार की रात आपातकालीन निर्माण के मामले में एक पुराने कहीं और परिभाषित कर सकते हैं। लेकिन यह है कि मुझे लगता है, बल्कि लाभप्रद है।

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

---

¹ सी # केवल प्रीप्रोसेसर प्रतीकों की सरल परिभाषा का समर्थन करता है, कोई संख्यात्मक मान नहीं, जो इस रणनीति को व्यवहार्य नहीं बनाता है।

Comments

यह भी ध्यान देने योग्य है कि यह प्रीप्रोसेसर परिभाषित सभी कोड को बाध्य करेगा जो TIMESTAMPहर बिल्ड पर पुन: उपयोग किए जाने का उपयोग करता है। यह भी जैसे उपकरणों को अक्षम करेगा ccache। इसका अर्थ है कि वृद्धिशील बिल्ड के लिए विशिष्ट संकलन समय इस आधार पर कोडित सुविधाओं से कितना प्रभावित होता है, इस पर निर्भर करता है।

— मन की बात

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

— पीटर ए। श्नाइडर

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

— मन की बात

Answer 11

विज़ुअल स्टूडियो में, आप एक पूर्व-निर्मित स्क्रिप्ट सेट कर सकते हैं जो एक निश्चित तिथि के बाद एक त्रुटि फेंकता है। यह संकलन को रोक देगा। यहाँ एक स्क्रिप्ट है जो 12 मार्च 2018 को या उसके बाद एक त्रुटि फेंकता है ( यहाँ से लिया गया है ):

@ECHO OFF

SET CutOffDate=2018-03-12

REM These indexes assume %DATE% is in format:
REM   Abr MM/DD/YYYY - ex. Sun 01/25/2015
SET TodayYear=%DATE:~10,4%
SET TodayMonth=%DATE:~4,2%
SET TodayDay=%DATE:~7,2%

REM Construct today's date to be in the same format as the CutOffDate.
REM Since the format is a comparable string, it will evaluate date orders.
IF %TodayYear%-%TodayMonth%-%TodayDay% GTR %CutOffDate% (
    ECHO Today is after the cut-off date.
    REM throw an error to prevent compilation
    EXIT /B 2
) ELSE (
    ECHO Today is on or before the cut-off date.
)

इस स्क्रिप्ट का उपयोग करने से पहले इस पृष्ठ पर अन्य उत्तरों को पढ़ना सुनिश्चित करें।

Answer 12

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

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

SCM आधारित समाधान के लिए, मैं मान लूंगा कि आप git और git-flow का उपयोग कर रहे हैं। (यदि नहीं, तो तर्क आसानी से अन्य VCS के अनुकूल है)। एक नई शाखा बनाएँ postDeprecated। उस शाखा में सभी हटाए गए कोड को हटा दें, और किसी भी संदर्भ को हटाने तक काम करना शुरू कर दें। masterशाखा में कोई भी सामान्य परिवर्तन जारी है । एकीकरण चुनौतियों को कम करने के लिए masterबैक में किसी भी गैर-हटाए गए संबंधित कोड परिवर्तन को मर्ज करते रहें postDeprecated।

पदावनति की तिथि समाप्त होने के बाद, से एक नई preDeprecatedशाखा बनाएँ master। फिर postDeprecatedवापस मर्ज करें master। मान लें कि आपकी रिहाई masterशाखा से चली गई है , तो आपको अब तारीख के बाद पदावनत शाखा का उपयोग करना चाहिए। यदि कोई आपात स्थिति है, या आप समय में परिणाम नहीं दे सकते हैं, तो आप हमेशा preDeprecatedउस शाखा पर रोलबैक कर सकते हैं और कोई आवश्यक परिवर्तन कर सकते हैं ।

Comments

यह दृष्टिकोण एक तार्किक दुःस्वप्न की तरह लगता है। यदि आप निकट-समानांतर समानांतर शाखाओं को बनाए रखना शुरू करते हैं, तो आप ऐसा करने में अपना सारा समय खर्च करेंगे। कुल अपशिष्ट।

— ऑर्बिट

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

— लाइट

क्योंकि रिलीज़ ब्रांच को बनाए रखने का एक अच्छा कारण है (महत्वपूर्ण पैच का बैकअप लेना)। "भविष्य में मैं कुछ कर सकता हूं" शाखा को बनाए रखने का कोई अच्छा कारण नहीं है। बिना किसी लाभ के, यह ओवरहेड है। इतना ही आसान।

— ऑर्बिट

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

— कक्षा

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

— user79126