Это плохая идея поместить ярлыки разработки в блоки # DEBUG?
В нескольких местах нашего кода мы используем блоки #if DEBUG для упрощения разработки. Такие вещи, как:
#if DEBUG
serverIP = localhost;
#else
serverIP = GetSetting()
#endif
или
private bool isLicensed()
#if DEBUG
return true;
#endif
return CheckSetting()
Есть также несколько мест, где мы делаем косметические изменения следующим образом:
#if DEBUG
background = humorousImage.jpg
#else
background = standardColor
#endif
Опасно ли зависеть от отладки #if, чтобы упростить разработку? Если это так, что является допустимым использованием #if debug?
Ответы
Ответ 1
Это действительно плохая идея. Если вы пытаетесь поймать производственную ошибку, ваши отладочные предложения наверняка будут вас трогать на определенном этапе. Вы хотите быть как можно ближе к коду, который работает в процессе производства. В вашем примере вы никогда не сможете найти ошибку в CheckSetting()
По внешности вещей ваш код слишком тесно связан. То, что вы хотите сделать, - сделать модули/классы менее зависимыми от друг друга и практиковать Test Driven Development. Также посмотрите на Inversion of Control (также известный как Injection Dependency).
Эффективная работа с устаревшим кодом содержит полезную информацию о том, как внедрить TDD. У этого также есть некоторые действительно хорошие указатели на том, как делать TDD в различных сценариях, где это может быть трудно проверить.
Ответ 2
Проблема с этим заключается в том, что у вас гораздо меньше шансов найти ошибки в #else
.
Как правило, ваши отладочные сборки должны быть как можно более похожими на ваши версии сборки.
Ответ 3
В идеале, я думаю, вы переместили эти настройки в файлы конфигурации и сохранили директивы #IF Debug для тестирования, ведения журнала и дополнительных задач "отладки". Кроме того, имейте в виду, что код клиента, который вам когда-либо понадобился для создания "отладочной" сборки, теперь будет совершенно иным. Мои два цента.
Ответ 4
Я не могу сказать, что это то, о чем я очень люблю, лично - я работаю в среде, где наше основное приложение (развернутое до 400 + пользователей) имеет более 60 модулей - и с 5 разработчиками, работающими над проектами и выпуская модули, вы просто знаете, что рано или поздно кто-то случайно выпустит модуль отладки.:)
Ответ 5
Вам следует попытаться сохранить как можно более живую среду и среду разработки, поэтому избегайте наличия двух версий кода.
Одно допустимое использование конструкции #if DEBUG
заключается в том, чтобы добавить дополнительные коды кода, которые не нужны в конечном продукте:
#if DEBUG
if (somehting that normally can't happen) throw new SomeException();
#endif
Ответ 6
Первое допустимое использование, которое у меня было для условного блока #if:
У нас есть новая система лицензирования/активации. Нам нужно, чтобы он был отключен для локальной отладки, но не хотел использовать параметр конфигурации, чтобы отключить его - тогда пользователь мог обойти систему, изменив конфигурационный файл!
Итак, мы используем блок условной компиляции:
#if !DISABLE_ACTIVATION
// activation code here
#endif
Надеюсь, что поможет немного нарисовать картинку.!
Ответ 7
Мой текущий стиль состоит в том, чтобы иметь файл с именем aadebug.h, который содержит кучу условных определений, каждому из которых может предшествовать//для деактивации. Файл начинается:
//#define DX_DEBUG
#ifdef DX_DEBUG
#define DX_SKIP_LOGIN
// #define DX_ALLOW_BULK_USER_CREATE
#define DX_CREATE_EXCESS_LOGS
// #define DX_RANDOM_PROBE_FAILURES
#define SHORT_KEY_TIMEOUT
// #define DX_OMIT_NET_VIEWER
...
#endif
Если DEBUG включен, в главном экране дисплея будет отображаться "НЕ ДЛЯ ПРОИЗВОДСТВЕННОГО ИСПОЛЬЗОВАНИЯ". Все параметры только для отладки могут быть отключены отключением DX_DEBUG, но большинство параметров обычно контролируются с использованием отдельных флагов. Если я решила, что вариант исчерпал свою полезность, я удалю его #ifdef из источника, а затем удаляю закомментированный #define из aadebug.h, но в остальном я использую закомментированный #define, чтобы отслеживать, какой # ifdef флаги все еще существуют.