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

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

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

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

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

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

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

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

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

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

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

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

Или ...

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

if(inTest) {
testMethod();
}

Вы могли бы установите этот vboolean с помощью внедрения зависимостей или прочтите его из переданного в системном свойстве (-DinTest = true)

Надеюсь, это поможет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все, что не так в производственной сборке, повредит гораздо больше.

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

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

и затем отметьте нужные места с помощью

Prod.uction();

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

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

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

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

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