Как пометить некоторый код, который необходимо удалить перед производством?

избежать необходимости. Если вы размещаете код в классе, которого не должно быть в производстве, выясните, как это сделать по-другому. Обеспечьте, скажем, крюк, чтобы тестовый код мог делать то, что ему нужно, но оставьте тестовый код вне класса. Или подкласс для тестирования, или использование инъекции зависимостей, или любой другой метод, который оставляет ваш код действительным и безопасным для производства, в то же время проверяемым. Многие из таких методов хорошо документированы в фантастической книге Майкла пера, эффективная работа с устаревшим кодом.

добавьте модульный тест, который завершается неудачей, если блок присутствует. Возможно, блок устанавливает глобальную переменную CODE_BLOCK_IS_NOT_DELETED = true; который проверяет модульный тест.

однако ваша большая проблема заключается в том, что вы тестируете/разрабатываете код, который вам не нужен или не используется в производстве. Это звучит неправильно.

одним из грязных предложений было бы создать класс со статическим методом, скажем

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

и затем отметьте места, которые вы хотите с

Prod.uction();

затем перед производством просто удалите класс, и вы получите ошибки компилятора, где это необходимо: D

однако вы технически решаете это, я бы рекомендовал сделать это наоборот: do не сделайте что-то особенное для производственной сборки, но структурируйте свой код и среду сборки таким образом, чтобы магия происходила во время сборки разработки. Производственная сборка должна быть максимально надежной (или Мерфи-доказательство).

Если что-то пойдет не так в развитии сборки: так что.

что-нибудь не так, в сборку будет больно намного больше.

[edit:] работает для C++... :-)

использовать эти определения препроцессора и все ваши проблемы будут решены:

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

Не уверен, что синтаксис полностью правильный, но вы получаете идею.

мы добавили триггер для subversion, который блокирует \NOCOMMIT: вы могли бы \NODEPLOY: тег, который будет искать ваш скрипт сборки, прежде чем разрешить сборку.

TDD и концепции инверсии зависимостей могут помочь вам здесь. Помещая изменяющийся код в класс, реализующий интерфейс, вы можете контролировать, когда выполняется тестовая версия этого кода и когда выполняется версия prod.

тогда у вас есть файл, явно названный для тестирования, который вы можете оставить из своей сборки.

в проектах, над которыми я работал, у меня были различные лакомые кусочки кода, которые позволяют легко тестировать во время разработки. Я заворачиваю их в блок if, который проверяет окончательное логическое. Если логическое значение равно true, доступ к коду возможен. Когда логическое значение false, я зависел от компилятора, удаляющего код из результирующего .класс файлов как оптимизация. Например:

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

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

обычно я управляю этими переменными самостоятельно, используя их во время разработки и настройки Проверяемый на ложь, когда я закончу. Команда разработчиков может легко согласиться с соглашением для имен переменных, таких как TESTABLE, и производственная цель файла сборки может проверять и терпеть неудачу, если какие-либо исходные файлы имеют тестируемую переменную = true.

в дополнение ко всем вышеперечисленным предложениям (что со всем ручным дерьмом и добавлением cruft в код? автоматизируйте вещи людей...), Я заметил, что вы используете Eclipse, Spring и ANT. Eclipse поддерживает несколько исходных папок-разделите код на папку" источник "и" тестирование", поместите что-нибудь для производства в исходную папку и поместите что-нибудь" не производство " в папку тестирования. Spring позволяет иметь несколько конфигураций, ссылающихся на различные реализации - таким образом, вы можете иметь производственную конфигурацию, которая ссылается на классы только в производстве, и конфигурацию(ы) тестирования для запуска с кодом тестирования. Попросите скрипт ANT создать производственную и тестовую версии вашего приложения - для тестирования добавьте папку "тестирование"в путь компиляции, для производства оставьте ее. Если класс ссылается на класс тестирования из производства, вы получите ошибку компиляции - если конфигурация рабочей пружины ссылается на класс из тестирования в производстве, это приведет к сбою как как только он попытается загрузить его.

может быть, если вы пометите эти классы / методы как depricated, то они будут помечены во время компиляции?

для наших производственных сред, мы имеем пару простых инструментов К для обнажать вне разделы используя очень особенные комментарии. /*#BEGIN_SKIP*/ и /*#END_SKIP*/. Придерживайтесь стандартного времени выполнения C, и вы можете компилировать в любой среде.

вы можете изменить весь цикл сборки, чтобы реплицировать исходный код, преобразовать его и скомпилировать.

Я бы постарался избежать этого, насколько это возможно. - Альтернативным подходом было бы использование инъекции зависимостей для внедрения различных реализаций для тестирования.

или...

добавьте логическое поле inTest к объектам и оберните необязательный код в Оператор if.

if(inTest) {
testMethod();
}

вы можете установить этот vboolean с инъекцией зависимостей или прочитать его из переданного в системном свойстве (- DinTest=true)

надеюсь, что это помогает.

вы можете использовать препроцессор java. Для приложений j2me я использую препроцессор антенны. Код выглядит следующим образом

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

Eclipse допускает другие маркеры, чем просто / / TODO, вы можете добавить, например, //TOBEREMOVED и дать ему высокий приоритет, поэтому он появляется перед всеми другими маркерами TODO.

просто добавьте / / TODO: -- затем создайте скрипт c# (cs-script.net) который ищет / / TODO в вашем коде и отображает их. Затем вы можете добавить этот скрипт в свои автоматические сборки (если вы это делаете), поэтому каждый раз, когда вы делаете сборку, вы можете видеть, что нужно делать. Просмотрите список задач кода перед развертыванием.

кроме того, чтобы написать свой собственный сценарий, есть некоторые инструкции о том, как интегрировать vstudio с некоторым инструментом, который указывает ваши строки todo, а также: http://predicatet.blogspot.com/2006/12/show-all-tasks-in-visual-studion-2005-c.html

однако, мне кажется, настройка этого инструмента больше боли, чем написание простого скрипта C# с регулярным выражением.

Я использую ключевое слово //FIXME, которое eclipse отображает вместе с / / TODO в представлении задач (вы можете отфильтровать то, что нужно увидеть на нем). Вы не должны выходить на производство, если есть некоторые //FIXME вокруг:)

мое решение-работать над двумя отдельными ветвями кода. Одна производственная ветвь, которая получает только чистый код без отладочного кода, а другая (иногда у меня даже есть несколько из них) для тестирования, отладки, попытки нового struff и т. д.

в eclipse это отдельные проекты (или группы проектов).

Mercurial-хороший VCS для этого типа работы, но CVS и subversion тоже хороши.

очевидный способ решить эту проблему-иметь модульный тест, который выполняется только в сборке, предназначенной для сборки файлов для производства (или проверяет, предназначена ли текущая сборка для производства и запускает тест, если это так), и завершает сборку, если тест завершается неудачей.

вы никогда не забудете. С точки зрения того, какой тест, в идеале, он будет фактически проверять все, что делает код. Если это невозможно, то глобальная статика, как предположил Терри Лорбер, будет намного лучше, чем то, что у тебя есть сейчас.