Прошло 15 лет с момента выхода Xdebug. Мы думаем, что это прекрасная возможность вновь представить его миру и объяснить, как и почему он делает то, что делает.
Xdebug — это расширение PHP (то есть его нужно скомпилировать и установить в установку PHP), которое предоставляет разработчику некоторые функции для отладки. К ним относятся:
- трассировки стека — подробный вывод пути, по которому приложение достигло определенной ошибки, включая параметры, переданные функциям, чтобы легко отследить ошибку.
- более симпатичный вывод
var_dumpкоторый выдает информацию с цветовой кодировкой и структурированные представления, аналогичные VarDumper , вместе с суперглобальным дампером - профилировщик для определения узких мест в вашем коде и возможность визуализировать эти графики производительности во внешних инструментах. В результате получается график, похожий на тот, который производит Blackfire .
- удаленный отладчик, который можно использовать для удаленного подключения Xdebug к исполняемому коду и конечному клиенту, такому как IDE или браузер, для перехода через точки останова в коде и построчно выполнять ваше приложение.
- покрытие кода, которое сообщает вам, сколько кода было выполнено во время запроса. Это почти исключительно предназначено, чтобы помочь с юнит-тестами и выяснить, сколько кода покрыто тестами
Как мне это использовать?
Xdebug поставляется с подробной страницей установки, которая обрабатывает большинство, если не все варианты использования, но если вы хотите поиграть с функциональностью, представленной ниже, мы рекомендуем использовать Homestead Improved, который поставляется с предварительно установленным и активированным расширением.
С современными IDE и Blackfire, есть ли необходимость в Xdebug?
Среды IDE обеспечивают хорошую функциональность поиска кода, поэтому полезность функциональности формата ссылок может показаться сомнительной. Также есть регистраторы всех видов, которые могут обрабатывать ошибки и исключения. Аналогично, трассировка функций и профилирование действительно хорошо выполняются в Blackfire. Тем не менее, форматы файловых ссылок являются лишь частью Xdebug, и использование Blackfire имеет свои собственные препятствия — установка расширения, настройка ключей, а затем оплата за ведение истории трассировки. Регистраторы также должны использоваться с большой предусмотрительностью, и их не очень легко добавить в приложение позже.
Однако в Xdebug есть нечто большее, чем просто это — он все еще необходим для правильного модульного тестирования (от него зависят среды тестирования для отчетов о покрытии кода), удаленную отладку с помощью других средств далеко не легко выполнить, и это инструмент старый и стабильный, он был сглажен почти до совершенства.
Если ваши текущие инструменты могут обрабатывать все, что он предлагает, или вам не нужны функции, которые он предлагает, то, конечно, в Xdebug нет необходимости, но я еще не запустил один проект, который мог бы быть выполнен так же эффективно без него.
Давайте попробуем это
Я предполагаю, что у вас есть работающая установка Xdebug на данный момент. Если нет, рассмотрите возможность использования Homestead Improved .
Давайте создадим новую папку проекта с простым файлом index.php и выведем несуществующую переменную, такую как $foo :
<?php echo $foo;
Вот что мы получаем:
Выключение Xdebug
Подобные экраны в наши дни настолько распространены и настолько распространены по умолчанию, что большинство людей даже не осознают, что это уже стиль Xdebug. Чтобы доказать это, давайте посмотрим, как это выглядит без Xdebug. Чтобы отключить Xdebug, мы редактируем файл /etc/php/7.1/fpm/conf.d/20-xdebug.ini в Homestead Improved и закомментируем первую строку:
;zend_extension=xdebug.so xdebug.remote_enable = 1 xdebug.remote_connect_back = 1 xdebug.remote_port = 9000 xdebug.max_nesting_level = 512
После этого нам нужно перезапустить PHP-FPM:
sudo service php7.1-fpm restart
Примечание: если вы используете другую среду разработки с другой установкой PHP, ваш ini-файл Xdebug может быть в другом месте. Обратитесь к документации вашей системы для точного местоположения, или спросите в комментариях ниже.
Выглядит довольно бесплодно, не так ли? Не хватает всего стека вызовов. Конечно, на данный момент эта информация не особенно полезна, поскольку мы имеем дело только с одной строкой в одном файле, но позже мы рассмотрим более интенсивное использование.
Снова активируйте Xdebug, удалив комментарий в ранее отредактированном файле, и давайте продолжим. Не забудьте перезапустить PHP!
File Clickthroughs
Если вы разработчик, который работает в среде IDE (как, например, я в PhpStorm), было бы полезно иметь возможность щелкать файлы в трассировке стека и переходить непосредственно к ним в среде IDE. Конечно, нетривиальное обновление скорости отладки. Я продемонстрирую реализацию этой функции для PhpStorm.
Сначала давайте 20-xdebug.ini файл 20-xdebug.ini который мы редактировали ранее, и добавим к нему следующее:
xdebug.file_link_format = phpstorm://open?%f:%l
Обратите внимание, что это будет работать в некоторых браузерах, а в других — нет. Например, у Opera есть проблемы с phpstorm:// и они с удовольствием phpstorm:// , в то время как Firefox и Chrome работают просто отлично.
Если мы обновим нашу недействительную страницу PHP сейчас, мы получим кликабельные ссылки, которые открывают IDE в точном месте ошибки:
Процесс аналогичен для других IDE и редакторов.
Xdebug с Vagrant и PhpStorm
Зачем на этом останавливаться? Многие люди сегодня разрабатывают на виртуальных машинах , следя за тем, чтобы ни одна часть среды выполнения PHP никогда не касалась их основной машины, сохраняя все быстро и гладко. Как Xdebug ведет себя в таких случаях? Кроме того, возможно ли вообще выполнять отладку в точке останова, когда вы шагаете по коду и просматриваете каждую строку отдельно при использовании таких сложных сред?
К счастью, Xdebug прекрасно поддерживает удаленные соединения с питанием от точки останова. Мы уже рассмотрели этот процесс, поэтому для полного учебника по настройке GIF, пожалуйста, следуйте этому руководству .
Использование профилировщика
В заключение, давайте посмотрим на одну из часто забываемых функций: профилировщик. Для этого нам понадобится тяжелое приложение, такое как Laravel.
composer create-project --prefer-dist laravel/laravel xdebug
Еще раз нам нужно отредактировать файл 20-xdebug.ini и добавить следующее:
xdebug.profiler_enable_trigger = 1 xdebug.profiler_output_dir = /home/vagrant/Code/
Обратите внимание, что мы не используем xdebug.profiler_enable = 1 потому что мы не хотим, чтобы он оставался в 100% случаев. Вместо этого мы будем использовать параметр запроса триггера «XDEBUG_PROFILE», чтобы выборочно активировать его. Мы также выводим профиль cachegrind в основную общую папку нашей ВМ, чтобы мы могли проверить его с помощью инструментов в операционной системе хоста.
После перезапуска PHP мы можем попробовать его, выполнив homestead.app/?XDEBUG_PROFILE (замените homestead.app на любой выбранный вами хост или IP-адрес виртуальной машины). Конечно же, файл там:
Каждая ОС будет иметь свой собственный инструмент инспектора cachegrind, а в OS X одним из них является qcachegrind, который легко устанавливается через Homebrew. Обратитесь к предпочитаемому визуализатору вашей ОС для получения инструкций по установке. После установки…
brew install qcachegrind --with-graphviz
… И открыв файл в средстве просмотра, мы можем увидеть красивую разбивку потока выполнения:
Профилировщик предлагает и неизмеримое множество данных, и действительно глубокое понимание того, как ваш код ведет себя, как Blackfire. Однако при локальном выводе профилировщика проще, чем когда-либо, автоматизировать непрерывное отслеживание производительности и сложности выполнения.
Заставить рендера Хдебуга на Ларавеле
По умолчанию в Laravel есть настраиваемые отчеты об ошибках и настройка рендеринга. Ошибка, подобная той, которую мы вызывали ранее с неопределенной переменной, в Laravel выглядела бы так:
<?php use Illuminate\Http\Request; Route::get('/', function(Request $request){ echo $foo; return view('welcome'); });
Несмотря на то, что экран ошибок Symfony (который используется здесь Laravel) настроен так, чтобы он также хорошо играл с переходом по Xdebug (попробуйте, теперь вы также можете щелкать по этим файлам и их строкам!), Я действительно пропускаю вывод памяти (Xdebug by default также выводит использование памяти в каждый момент времени в трассировке стека). Давайте вернемся к экрану Xdebug в режиме разработки, чтобы мы могли проверить этот атрибут.
<?php use Illuminate\Http\Request; Route::get('/', function(Request $request){ ini_set('display_errors', 1); restore_error_handler(); echo $foo; return view('welcome'); });
Вы можете видеть здесь, что мы обновили наш маршрут по умолчанию, чтобы он сначала активировал отображение ошибок (экран, который мы видели ранее, не является показанной ошибкой как таковой, а перехваченным исключением, трассировка стека которого была извлечена и обработана вручную), и затем мы возвращаем обработчику ошибок его значение по умолчанию, переопределяя Laravel.
После обновления, конечно же, наш старый экран вернулся — просто посмотрите на эту башню трассировки стека и потребление памяти!
Я призываю вас самим продолжить расследование — посмотрите в документации, поиграйте с опциями, посмотрите, что вы можете узнать о своих приложениях.
Вывод
Xdebug — это ценный инструмент для любого разработчика. Это мощное расширение, полностью соответствующее слову, расширяющее язык, с которым мы работаем ежедневно, чтобы быть более многословным, более удобным и менее загадочным при появлении ошибок.
За 15 лет Xdebug установил высокий стандарт для средств отладки. Я хотел бы поблагодарить Дерика за его разработку и поддержку все это время, и мне бы очень понравилось, если бы вы решили написать учебник или два о всестороннем использовании, предостережениях или секретных комбинациях функций, о которых раньше никто не думал. Давайте распространять слово и помочь ему процветать еще 15 лет.
С днем рождения, Xdebug!