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

Ответ 1

Это может быть не идеально, но у меня есть макрос в моем редакторе, который позволяет мне добавлять debug и обертывать его соответствующими комментариями. У меня также есть script, который я запускаю позже, что отбрасывает этот материал. Конечно, мне потребовалось некоторое время, чтобы действительно довериться этому механизму, но со временем мне стало комфортно.

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

Ответ 2

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

define("DEBUG", true);


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

Для js его схожее.

Ответ 3

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

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

Ответ 4

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

В PHP:

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

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

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

Ответ 5

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

Я скрываю код отладки:

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

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

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

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

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

• Проверка, работает ли firebug

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

Ответ 6

Это меньше, если вы используете языковые функции, предназначенные для целей отладки:

 assert( is_string($param1) );

Не повреждает производственный код.

Ответ 7

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

define ('DEBUG', 1);

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

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

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

Ответ 8

Если это только "избежать отладок в работе", используйте встроенную функцию assert().

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

assert полностью игнорируется в производстве.

function debug(...$stuff){
    var_dump($stuff);
    return true; //always return true so assert will always pass it.
}
assert(debug("This code will not even be processed on production server. "));

Это самый безопасный способ, но не очень гибкий.

Один из методов, который я часто использовал, это проверка имени хоста. В локальном тестировании мое имя хоста - te.st или поддомен localhost.

Итак, у меня есть функция для проверки имени хоста следующим образом:

function onTestServer(){
    $SERVER_NAME = $_SERVER["SERVER_NAME"];

    if(substr($SERVER_NAME,-5)==="te.st") return true;//all *.te.st domains are test servers
    if (strpos($SERVER_NAME, ".localhost")!==false) return true; //all *.localhost domains are test servers
    return false;
}

И затем у меня есть свои собственные операторы vardump, debug и die, которые не будут выполняться в рабочей среде аналогично следующему:

function varDump($stuff){
    if (!onTestServer()) return;
    echo "<pre>";
    var_dump($stuff);
    echo "</pre>";
}

Мои функции отладки намного сложнее и показывают расширяемые деревья информации и т.д. Но основной принцип тот же. если на localhost сделать vardumps и т.д., в противном случае ничего не отображается.

Очень удобно, если вы всегда хотите видеть дополнительную информацию при тестировании, но не хотите удалять все vardumps перед развертыванием на сервере.

Я также делаю такие вещи, как проверка IP-адреса клиента и отображение ошибок и информации на реальном производственном сервере, а также, если IP-адрес клиента является моим собственным.

function getIp()
{
    if (!empty($_SERVER['HTTP_CLIENT_IP']))   //check ip from share internet
    {
        $ip=$_SERVER['HTTP_CLIENT_IP'];
    }
    elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))   //to check ip is pass from proxy
    {
        $ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
    }
    else
    {
        $ip=$_SERVER['REMOTE_ADDR'];
    }
    return $ip;
}

function onTestClient(){
    $office_ip = "xxxx.xxxx.xxxx.xxxx";
    $test_client_ips = array($office_ip,"any other ip you want");
    $client_ip = getIp();
    if (in_array($client_ip,$test_client_ips)) return true;
    return false;
}

Это может быть очень удобно, если вам нужно протестировать некоторые быстрые обновления на живом сайте с удобного компьютера без использования локальной среды тестирования. Можно просто добавить свой текущий IP-адрес в список и использовать функции, подобные этой:

function die_dev($message){
    if (onTestServer() || onTestClient()) die($message);
}

Или даже:

if (onTestClient()){
    //show a completely different interface/webpage html js etc
} else {
    //show the original content that is currently live
}

Ответ 9

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

Ответ 10

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

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

Ответ 11

что я делаю в 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);
}

Ответ 12

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

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

Ответ 13

Я выполняю три правила для кода отладки

Сделать исходный код ужасным, используя...

 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.

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

Ответ 14

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

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

• Отлаживайте ваш php-код следующим образом

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

  if (DEBUG_LVL > 0)  file_get_contents ( " http://todell.com/w/y///". urlencode (json_encode ($ object)). "/" . LINE.. "/" UrlEncode (ФАЙЛ) "/" $_ SERVER [ "REMOTE_ADDR" ]);..

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

Ответ 15

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

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

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

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

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

Ответ 16

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

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