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

Самый простой метод

define("DEBUG", true);


if (DEBUG) {
    echo "Debug Method";
}

Для js аналогично.

Человеческую ошибку трудно предотвратить

Https://meta.stackexchange.com/questions/71780/lol-debugging-are-we-so-homepage-alerts-false

Один из методов - с переменной среды. В конфигурации вашего сервера вы можете задать переменную среды, чтобы указать отлаживать или нет. Производственные серверы будут настроены на значение false, а разработка - на значение true. Таким образом, все, что вы делаете в коде, - это проверяете переменную среды:

В PHP:

if (getenv('DEBUG_MODE')) {
    var_dump($foo);
}

Таким образом, забыть невозможно, так как он автоматически отключится. Но если вам ДЕЙСТВИТЕЛЬНО нужно включить его в производстве, просто переверните переключатель...

• Документы для Apache
• Документы для Lighttpd
• Документы для NginX

Существует несколько способов скрыть отладочный код в рабочей среде, но мало способов удалить его (когда компилятор не может автоматически удалить его).

Я скрываю код отладки с помощью:

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

Я удаляю его, выполняя поиск специальных комментариев перед развертыванием:

• alert("false") //TODO:REMOVE DEBUG CODE

Мои коллеги также предлагается:

• Переопределение alert для проверки наличия отладочной переменной. (Побочные эффекты?)
• Написание метода alertDebug для проверки наличия отладочной переменной. (Кто-нибудь это запомнит?)

• Проверка, не запущен ли firebug

  if(window.console && window.console.firebug) { alert("you are using firebug"); }

Поскольку самый простой ответ имеет недостаток в безопасности, позвольте мне включить менее рискованную версию из php.net.

define ('DEBUG', 1);

if (DEBUG == 1) {
   // echo some sensitive data.
}

Основы те же, но этот не будет выполнять отладочный код, если константа DEBUG не объявлена.

Проблема с if (DEBUG) заключается в том, что если константа не определена, она будет принимать строку "DEBUG", которая оценивается как true.

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

Здесь у нас есть несколько этапов тестирования, прежде чем код когда-либо попадет в производство. Разные группы тестировщиков на каждом этапе с разными целями. Похоже, до сих пор это работает (у нас никогда не было такого кода отладки, как этот, выходящего в производство).

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

Как правило, это происходит реже, если вы используете языковые функции, предназначенные для целей отладки:

 assert( is_string($param1) );

Не повредит производственному коду.

То, что я делаю, написано на php

define ("DEBUG", true);


function op (){
    if ( !DEBUG ) return true;

    $args = func_get_args();

    foreach ( $args as $var ){
        if ( is_object ( $var ) or is_array ( $var ) ){
            print "<br /><pre>";
            print_r ( $var );
            print "</pre>";

        }
        else{
            print "<br />" . $var;
        }
    }

        return true;
}

// On places to check 
op ($array, $var);

В js я также сделаю то же самое, что и

function calert(message){
    if (!debug) return;
    alert (message);
}

Вы работаете непосредственно на производственном сервере? Вы когда-нибудь слышали о промежуточном сервере или тестовом сервере? Вы можете использовать свой собственный компьютер в качестве сервера сцены - используйте microsoft web matrix! Сделайте свой код чистым и идеально работающим там, а затем переходите к производству.

Нет другого хорошего способа убедиться, что отладочный код появится на рабочем сервере - контроль качества перед производством

Я следую трем правилам для кода отладки

Сделайте исходный код ужасным, by...

 not indenting it from the left margin

 egregiously violating the coding standard

 putting in extra whitespace above and below

Настройте глобальный переключатель отладки и

 have it alter an obvious output if it is ON, and

 make the debug code compilation depend on that switch being ON (i.e., so the code won't compile if the global switch is OFF)

Саботируйте очевидный результат, например:

 delete something really important

 put up 99/99/99, for the date

 comment out the "File Load" function

 delaying the splash-screen

 etc.

Эти три правила хорошо сработали для меня.

Я собираюсь упомянуть об этом только потому, что никто туда не ходил.

Если вы не напишете никакого отладочного кода, то отладочный код не попадет в рабочую среду.

Если вы пишете "отладочный код", это говорит о том, что вы на самом деле плохо понимаете свой код. Может быть, это слишком сложно.

Сначала напишите свои модульные тесты. Эта практика приведет к улучшению дизайна. Убедитесь, что у вас есть полное покрытие кода. Проверьте случаи, которые трудно осуществить - не удается получить сокет подключение, база данных недоступна и т.д. Напишите регрессионные тесты. Не развертывайте ничего, что не может пройти мимо них. Любое сообщение об ошибке должно быть превращено в регрессионный тест до изменения кода. Регрессионный тест должен завершиться неудачей - и быть единственным тестом, который завершится неудачей. Исправьте ошибку.

Автоматизируйте компиляцию и тестирование. Если вы действительно пишете отладочный код, его следует удалить сразу же после успешного тестирования. Когда ваша организация станет действительно зрелой, возможно, вы даже автоматизируете развертывание.

Мой рекомендуемый способ отладки PHP-кода даже в рабочем режиме.

1. Зарегистрируйтесь бесплатно и создайте приложение по адресу http://todell.com/debug

2. Отладьте свой php-код следующим образом

   Определите ("DEBUG_LVL", 1); /*поместите это в любое удобное для редактирования место или в один файл, который был включен во все ваше веб-приложение. */

   Если(DEBUG_LVL >0) file_get_contents("http://todell.com/w/y///".urlencode(json_encode($object))."/".LINE."/".urlencode(FILE)."/".$_SERVER["REMOTE_ADDR"]);

Где $объект - это объект, который вы хотите отправить в свое приложение для отладки. это может быть что угодно, начиная от исключения, вызванного вашим кодом, или данных сравнительного анализа. Ограничение на размер объекта в $ составляет 64 КБ Это не ограничивается только языком PHP.

Усердие разработчиков и хорошие тестировщики - это все, что действительно стоит на пути. Нет ни одного инструмента или процесса, который мог бы предотвратить подобные вещи.

Во всяком случае, это яркий пример того, почему так важно иметь безболезненный процесс сборки/развертывания. Плохие вещи попадут в производство. Гарантированный. Настоящий вопрос не в том, как это предотвратить, а в том, как на это реагировать.