Отладка

Ошибку редко видно там, где она проявляется. Пустая корзина может оказаться следствием неверного кеша, сломанная вёрстка — результатом PHP-предупреждения, которое попало в HTML. Поэтому отладка начинается не с правки кода, а с вопроса «что именно происходит и при каких условиях». Сам термин закрепился в программировании в середине XX века: баг — дефект, отладка — его устранение.

Порядок поиска ошибки

1. Воспроизвести проблему: конкретный адрес, пользователь, данные, браузер. Без этого любое исправление — догадка.
2. Собрать факты: текст ошибки, записи в журналах сервера и приложения, ответы во вкладке «Сеть» браузера.
3. Сузить область: отключить половину плагинов, откатить последний коммит, подставить заведомо верные данные.
4. Сформулировать гипотезу и проверить её одним изменением, а не пятью сразу.
5. После исправления повторить исходный сценарий и соседние, чтобы не сломать что-то рядом.

Инструменты для PHP-сайта

Самый простой инструмент — журнал. В WordPress его включают константами в wp-config.php, и сообщения пишутся в файл wp-content/debug.log, а не на экран посетителям:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

error_log( print_r( $order_data, true ) );

В 1С-Битрикс для той же цели есть \Bitrix\Main\Diag\Debug::writeToFile(). Когда записей в лог-файл не хватает, подключают пошаговый отладчик — для PHP это обычно Xdebug в связке с IDE: можно остановить выполнение на нужной строке и посмотреть значения всех переменных.

Чего избегать

Не отлаживать на рабочем сайте с выводом ошибок посетителям: так наружу утекают пути к файлам и фрагменты запросов. Не «лечить» симптом — например, глушить предупреждение оператором @ вместо того, чтобы понять, откуда пришло пустое значение. И не забывать убирать отладочный вывод после работы. Когда сайт на WordPress после обновления вообще не открывается, полезен разбор критической ошибки WordPress.