2010-09-01 7 views
9

हम वर्तमान में विजुअल स्टूडियो 2005 से विजुअल स्टूडियो 2010 (अप्रबंधित सी/सी ++ का उपयोग करके) में माइग्रेट कर रहे हैं। इसका मतलब है कि हमारे आधे डेवलपर्स पहले से ही विजुअल स्टूडियो 2010 का उपयोग कर रहे हैं, जबकि दूसरा आधा अभी भी विजुअल स्टूडियो 2005 का उपयोग कर रहा है। हाल ही में, मैं ऐसी परिस्थिति में आया जहां विजुअल स्टूडियो 2010 में एक साफ तरीके से एक निश्चित निर्माण लिखा जा सकता है, लेकिन विजुअल स्टूडियो 2005 में कम-स्वच्छ स्रोत कोड की आवश्यकता है नहीं सभी डेवलपर को अपना मशीन पर पहले से ही दृश्य स्टूडियो 2010 है, मैं इस तरह कोड लिखने के लिए है: द्वारा विजुअल स्टूडियो 2010 के लिए विस्थापित करेगाक्या स्रोत कोड होना संभव है जो 'टाइम आउट' (एक निश्चित पल के बाद अमान्य हो जाता है)?

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 

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

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

#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 
#if compilation_date is after 1 november 2010 
# error "Remove Visual Studio 2005 compatibility code from this file" 
#endif 

इस तरह, अगर हम इस बारे में भूल जाते हैं, तो हम स्वचालित रूप से इस के 1 नवंबर के बाद से सूचित किया जाता 2010

यह चाल शायद DATE के के उपयोग की आवश्यकता है, लेकिन इस की जरूरत के बाद से प्रीकंपेलर द्वारा संभाला जा सकता है, आप स्ट्रिंग-मैनिप्लेशंस नहीं कर सकते हैं या सी दिनांक/समय कार्यों का उपयोग नहीं कर सकते हैं।

मैंने खुद को देरी मेल भेजने का वैकल्पिक विचार भी माना, लेकिन मैं सोच रहा था कि कोई समाधान नहीं था जिसे स्रोत कोड में बनाया जा सकता था।

+1

ऐसा लगता है कि क्लीन-अप को आसानी से लिपि जा सकता है, इसलिए मैं अनावश्यक कोड को हटाने के लिए डेवलपर्स को याद दिलाने के लिए अतिरिक्त चेतावनियां डालने से परेशान नहीं हूं। –

उत्तर

6

व्यक्तिगत रूप से, मैं अविश्वास करना चुनता हूं कि हर कोई वास्तव में अपेक्षित तारीख से माइग्रेट करेगा। भले ही मुझे विश्वास है कि ऐसा होने जा रहा है, मैं किसी भी व्यक्ति के लिए अतिरिक्त काम नहीं करना चाहता हूं, या काम करने से रोकना चाहता हूं, अगर मैं गलत हूं।

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

तो, मैं यह कर चाहते हैं:

support2005.h 
------------- 

// empty file 

source file 
----------- 

#include "support2005.h" 
#if _MSC_VER >= 1600 
    // clean version of the source code 
#else 
    // less clean version 
    // of the source code 
    // requiring multiple lines of code 
    // and requiring some dirty static_casts 
#endif 

जब सभी लोग VS 2010 है, परिवर्तन support2005.h #error "Remove Visual Studio 2005 compatibility code from this file" को रोकने के लिए।

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

आप कहते हैं कि आप चिंतित हैं कि आप भूल सकते हैं, लेकिन यदि आप करते हैं, तो क्या? मृत कोड किसी को चोट नहीं पहुंचा रहा है। अगली बार जब आप किसी भी फाइल को देखते हैं, या अगली बार जब आप फ़ाइल सूची, हेडर निर्भरता ग्राफ इत्यादि में "support2005.h" देखते हैं, तो यह याद नहीं होगा "यह स्रोत कोड को पढ़ने योग्य नहीं है ", क्योंकि लंबे समय तक जो इसे देखता है उसे सिर्फ अनदेखा या हटा सकता है। यदि आपके पास कोई भी समस्या-ट्रैकिंग सॉफ़्टवेयर है, तो आप 2010-11-01 के बाद लक्षित पहला मील का पत्थर ढूंढ सकते हैं, और एक कार्य संलग्न कर सकते हैं, "वीएस 2005 समर्थन को हटाएं, और समर्थन 2005.h से छुटकारा पाएं", नोट के साथ कि वर्तमान में डेवलपर्स द्वारा अभी भी वीएस 2005 का उपयोग कर अवरुद्ध किया गया है।

यदि आप वास्तव में 2010-11-01 को कठिन समय सीमा चाहते हैं, जिसके बाद कोड टूट जाता है, तो बस हेलोवीन पर आधी रात तक रहें, और चेक इन करें तब तोड़ना परिवर्तन। जैसा कि आपने अनुरोध किया है, यह वास्तव में कोड को तोड़ नहीं देता है, लेकिन यह स्रोत नियंत्रण से ताज़ा होने वाले किसी भी व्यक्ति को तोड़ देता है, और इसलिए संभवतः यह निर्माण को तोड़ देता है। सबसे महत्वपूर्ण बात यह है कि यह बहुत आसानी से उलटा हो सकता है, या स्थानीय स्तर पर दबाया जा सकता है, अगर यह काम करने से रोकने के लिए बाहर निकलता है।

+0

अच्छा तर्क। आपके पास निश्चित रूप से "निर्माण को पुनरुत्पादित किया जाना चाहिए" के बारे में एक बिंदु है। मैं "मृत कोड किसी को चोट नहीं पहुंचा रहा है" दृष्टिकोण से सहमत नहीं हूं। मृत कोड डेवलपर्स को भ्रमित/कर देगा। हाल ही में हमें किसी व्यक्ति को आंतरिक डेटा संरचना में बदलाव के साथ काम करने के लिए मृत कोड को मॉडिफ़िंग करने में कोई समस्या थी। तो मुझे लगता है कि मृत कोड को हटा दिया जाना चाहिए (हालांकि 1 नवंबर शायद एक अच्छा पल नहीं है)। "Support2005.h" विचार एक बेहतर विचार उठाता है: _SUPPORT2005 प्रतीक को परिभाषित करने के लिए/D_SUPPORT2005 का उपयोग क्यों न करें, और अगर यह प्रतीक यहां नहीं है तो संकलन विफल हो जाए, लेकिन पुराना कोड अभी भी है। – Patrick

+0

पर्याप्त मेला, मैं मान रहा था कि यह आपके संगठन में व्यापक रूप से ज्ञात होगा कि यह अस्थायी 2005 समर्थन आवश्यक था। यदि ऐसा है, तो एक बार इसकी आवश्यकता नहीं होने के बाद, * किसी को भ्रमित नहीं करना चाहिए या अनावश्यक काम नहीं करना चाहिए, क्योंकि कोई भी इसे संशोधित करने के बारे में सोचने के बजाय इसे हटा सकता है। मैं मानता हूं कि आपके द्वारा बताए गए कारणों के लिए सामान्य मृत कोड को हटा दिया जाना चाहिए। –

+0

क्या होगा अगर कोई पुराना कोड हटा देता है लेकिन हेडर को नहीं हटाता है। अगली बार जब वे त्रुटि देखते हैं, तो उन्हें पता नहीं होगा कि क्या करने की आवश्यकता है, क्योंकि सभी पुराने कोड पहले से ही चले गए हैं! – Lazer

2

मैं केवल #ifdef WARN_OLD_COMPAT जैसे प्रीप्रोसेसर परिभाषित करता हूं। देरी मेल के साथ आपको याद रखना होगा कि आप इसे परिभाषित करेंगे।

यह जांचना कि संकलन दिनांक < एक्स > से बाद में अन्य तरीकों से संभव नहीं है।

1

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

+1

मैं रन टाइम के बजाए संकलन समय पर चीजों की जांच करना पसंद करता हूं। – Patrick

+0

जैसा मैं करता हूं, लेकिन इस मामले में, रनटाइम पर जांच करने में कोई हानि नहीं है। –

15

जीएनयू make के मामले में मैं इसे इस तरह करना चाहते हैं:

CFLAGS + = -DCURDATE = $ (खोल तिथि +% Y% m% d)

यह एक मैक्रो CURDATE में जोड़ देगा कंपाइलर झंडे, जिसमें YYYYMMDD प्रारूप में वर्तमान समय शामिल है।

तो स्रोत में आप कुछ इस तरह कर सकता है:

#if CURDATE > 20101101 
#error "Do whatever you have to do" 
#endif 

आप वी.एस. में कुछ इस तरह कर सकता हूँ?

+0

अच्छा विचार, धन्यवाद। – Patrick

+0

+1, बहुत चालाक। –

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