उत्पादन से पहले हटाए जाने वाले कुछ कोड को कैसे चिह्नित किया जाए?

Question

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

सरल "//TODO:" वास्तव में काम नहीं करता है, क्योंकि यह ofter भूल और अन्य सब की टन के साथ मिलाया जाता है। क्या कुछ मजबूत है?

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

हम ग्रहण/चींटी (और जावा + वसंत) का उपयोग कर रहे हैं।

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

Answer 1

आप केवल मजबूत कार्य टिप्पणी मार्करों को परिभाषित कर सकते हैं: FIXME (उच्च प्राथमिकता) और XXX (सामान्य प्राथमिकता) ग्रहण में मानक हैं, और आप अधिक कार्य टैग परिभाषित कर सकते हैं (ग्रहण गुण -> जावा -> कंपाइलर -> कार्य टैग)

आप अपने निर्माण विफल करना चाहते हैं, तो आप चींटी (1.7) contains फ़ाइल चयनकर्ता निर्दिष्ट पाठ फ़ाइल के लिए देखने के लिए इस्तेमाल कर सकते हैं:

<target name="fixmeCheck"> 
    <fail message="Fixmes found"> 
    <condition> 
     <not> 
     <resourcecount count="0"> 
      <fileset dir="${pom.build.sourceDirectory}" 
        includes="**/*.java"> 
      <contains text="FIXME" casesensitive="yes"/> 
      </fileset> 
     </resourcecount> 
     </not> 
    </condition> 
    </fail> 
</target> 

<target name="compile" depends="fixmeCheck"> 

जाहिर

, अपने स्रोत निर्देशिका के लिए ${pom.build.sourceDirectory} बदलने के लिए, और FIXME उस टिप्पणी के लिए जिसे आप खोजना चाहते हैं।

क्या किसी को भी फाइल फ़ाइल में इस फाइलसेट में मिली फ़ाइलों को मुद्रित करने का एक अच्छा तरीका पता है (केवल ग्रहण में देखने के अलावा)?

Answer 2

शायद यदि आप उन कक्षाओं/विधियों को वंचित के रूप में चिह्नित करते हैं, तो उन्हें संकलन समय के दौरान ध्वजांकित किया जाएगा?

Answer 3

एक इकाई परीक्षण जोड़ें जो ब्लॉक मौजूद होने पर विफल रहता है। हो सकता है कि ब्लॉक वैश्विक वैरिएबल CODE_BLOCK_IS_NOT_DELETED = true; सेट करता है कि यूनिट टेस्ट जांचता है।

हालांकि, अपने बड़े समस्या यह है कि आप परीक्षण/कोड है कि आप की जरूरत है या उत्पादन में उपयोग नहीं करते हैं के साथ विकसित है। यह सही नहीं लगता है।

Answer 4

एक किसी भी तरह गंदा सुझाव एक स्थिर विधि के साथ एक वर्ग की सुविधा देता है कहते हैं कि

class Prod { 
    public static void uction(){ 
    } 
} 

बनाने के लिए किया जाएगा और उसके बाद

Prod.uction(); 

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

Answer 5

हमारे उत्पादन वातावरण के लिए, हम एक बहुत ही कल्पना का उपयोग कर वर्गों बाहर अलग करना के लिए सरल सी उपकरणों की एक जोड़ी आयन टिप्पणियां /*#BEGIN_SKIP*/ और /*#END_SKIP*/। मानक सी रन-टाइम पर चिपकाएं, और आप किसी भी पर्यावरण पर संकलित कर सकते हैं।

आप स्रोत कोड को दोहराने बदलने के लिए अपने पूरे निर्माण चक्र बदलने के लिए, और यह संकलन कर सकते हैं।

Answer 6

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

तो फिर तुम स्पष्ट रूप से परीक्षण के लिए किया जा रहा है, कि आप अपने निर्माण से बाहर छोड़ सकते हैं के रूप में नामित एक फ़ाइल है,।

Answer 7

मैं इसे यथासंभव से बचने की कोशिश करूंगा। - परीक्षण के लिए विभिन्न कार्यान्वयन को इंजेक्ट करने के लिए निर्भरता इंजेक्शन का उपयोग करने का एक वैकल्पिक दृष्टिकोण होगा।

या ...

ऑब्जेक्ट्स में एक इनटेस्ट बूलियन फ़ील्ड जोड़ें और वैकल्पिक कथन को वैकल्पिक कथन में लपेटें।

if(inTest) { 
testMethod(); 
} 

आप निर्भरता इंजेक्शन के साथ इस vboolean सेट या एक प्रणाली संपत्ति (-DinTest = true)

आशा इस मदद करता है में पारित से पढ़ सकते हैं।

Answer 8

आप जावा प्रीप्रोसेसर का उपयोग कर सकते हैं। J2me अनुप्रयोगों के लिए मैं एंटीना प्रीप्रोसेसर का उपयोग करता हूं। कोड इस

public void someMethod() { 
    //#ifdef DEBUG 
    doDebugStuff(); 
    //#endif  
} 

Answer 9

आवश्यकता से बचें। यदि आप उस वर्ग में कोड डाल रहे हैं जो उत्पादन में नहीं होना चाहिए, तो इसे अलग तरीके से कैसे करें। एक हुक प्रदान करें, कहें, ताकि परीक्षण कोड वह कर सके जो उसे चाहिए, लेकिन कक्षा के बाहर परीक्षण कोड छोड़ दें। या परीक्षण के लिए उपclass, या निर्भरता इंजेक्शन, या किसी भी अन्य तकनीक का उपयोग करें जो आपके कोड को उत्पादन के लिए वैध और सुरक्षित छोड़ देता है, जबकि अभी भी टेस्टेबल है। ऐसी कई तकनीकें माइकल फेदर्स की शानदार पुस्तक, Working Effectively with Legacy Code में अच्छी तरह से प्रलेखित हैं।

Answer 10

एक्लिप्स बस // TODO की तुलना में अन्य मार्करों की अनुमति देता है, उदाहरण के लिए, // TOBEREMOVED जोड़ सकते हैं और इसे उच्च प्राथमिकता देते हैं, इसलिए यह अन्य सभी TODO मार्करों से पहले दिखाई देता है।

Answer 11

यह हल करने का स्पष्ट तरीका एक यूनिट परीक्षण है जो केवल निर्माण के लिए फाइलों का निर्माण करने के उद्देश्य से निर्माण पर चलता है (या जांच करता है कि वर्तमान निर्माण उत्पादन के लिए लक्षित है और यदि यह है तो परीक्षण चलाता है) और अगर परीक्षण विफल रहता है तो निर्माण में विफल रहता है।

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

Answer 12

बस कुछ // TODO जोड़ें: - फिर एक सी # स्क्रिप्ट (cs-script.net) बनाएं जो आपके कोड में // TODO को देखता है और उन्हें प्रदर्शित करता है। फिर आप इस स्क्रिप्ट को अपने स्वचालित बिल्डों में जोड़ सकते हैं (यदि आप ऐसा कर रहे हैं), इसलिए प्रत्येक बार जब आप कोई बिल्ड करते हैं, तो आप देख सकते हैं कि क्या करना है। तैनाती से पहले अपने कोड की todo सूची की समीक्षा करें।

अपनी खुद की स्क्रिप्ट लिखने के लिए वैकल्पिक रूप से, कैसे कुछ उपकरण है जो अपनी कार्य करने लाइनों बताते हैं और साथ ही साथ vstudio एकीकृत करने के लिए पर कुछ निर्देश है: http://predicatet.blogspot.com/2006/12/show-all-tasks-in-visual-studion-2005-c.html

हालांकि, मुझे लगता है, की स्थापना है कि उपकरण के अधिक है रेगेक्स के साथ एक साधारण सी # स्क्रिप्ट लिखने से दर्द।

Answer 13

परियोजनाओं में मैंने काम किया है, मेरे पास विकास के दौरान आसान परीक्षण सक्षम करने के लिए कोड के विभिन्न टिड्बिट हैं। मैं इन्हें एक ब्लॉक में लपेटता हूं जो अंतिम बूलियन की जांच करता है। जब बूलियन सत्य होता है, तो कोड को एक्सेस किया जा सकता है। जब बूलियन झूठा होता है, तो मैं परिणामी .class फ़ाइलों से कोड को ऑप्टिमाइज़ेशन के रूप में हटाकर संकलक पर निर्भर करता हूं। उदाहरण के लिए:

public class Test { 
    public static void main(String[] args) { 
     final boolean TESTABLE = true; 

     if (TESTABLE) { 
      // do something 
     } 
    } 
} 

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

Answer 14

मैं // FIXME कीवर्ड का उपयोग करता हूं जो कार्य दृश्य में // TODO के साथ प्रदर्शित करता है, आप इसे देखने के लिए फ़िल्टर कर सकते हैं)। यदि आपके पास कुछ // FIXME है तो आपको उत्पादन में बाहर नहीं जाना चाहिए :)

Answer 15

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

Answer 16

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

ग्रहण में ये अलग-अलग परियोजनाएं (या परियोजनाओं के समूह) हैं।

Mercurial इस प्रकार के काम के लिए एक अच्छा वीसीएस है लेकिन सीवीएस और सबवर्सन भी अच्छे हैं।

Answer 17

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

यदि विकास के निर्माण में कुछ गलत हो जाता है: तो क्या।

उत्पादन निर्माण में कुछ भी गलत हो रहा है और अधिक नुकसान पहुंचाएगा।

Answer 18

[संपादित करें:] सी के लिए काम करता है ++ ... :-)

इन पूर्वप्रक्रमक defintions प्रयोग करें और अपनी सभी समस्याओं को हल किया जाएगा:

#ifdef _DEBUG 
#define COMMENT (code) /* code */ 
#else 
#define COMMENT (code) #error "Commented out code in release!" 
#endif 

सुनिश्चित नहीं हैं कि अगर वाक्य रचना पूरी तरह से सही है, लेकिन तुम्हें नया तरीका मिल गया है।

Answer 19

हमने \\NOCOMMIT: को अवरुद्ध करने के लिए एक ट्रिगर जोड़ा जो आपके पास \\NODEPLOY: टैग हो सकता है जो आपकी बिल्ड स्क्रिप्ट निर्माण की अनुमति देने से पहले देखेगी।