Интернет, компьютеры, софт и прочий Hi-Tech

Подписаться через RSS2Email.ru

6 подсказок по отладке для каждого PHP-кодера

Известный факт: программисты тратят на отладку больше времени, чем на написание кода. Помню, когда я был новичком, я тратил уйму времени на ковыряние кода в надежде, что баги исчезнут сами собой магическим образом. Не делайте этого! Представьте, сколько времени я потерял!

В этой статье я покажу вам пару трюков, которые позволяют работать эффективнее, но ключевая тема статьи — это отладка кода.

Вот краткий список подсказок, которые я хочу дать:

Если вам известны другие подсказки, которые могут помочь программистам отлаживать свой PHP-код, не стесняйтесь сообщить об этом в комментах! :)

Подсказка №1: Непосредственный доступ к своему коду!

Это само собой разумеется для профессиональных разработчиков, но для новичков это не так очевидно. Допустим, вы изменили код своих PHP-файлов на своем компьютере, затем зашли на сервер по FTP, залили скрипт, обновили страницу в браузере, чтобы посмотреть, как это работает… и… не удивляйтесь, если вам придется вернуть все как было.

Этот способ отладки кода неэффективен. И вообще, — это ущербный способ разработки для Веба.

Проблема такой «техники» заключается не только в неэффективности отладки. В действительности, — это очень порочная практика программирования. Просто не делайте так. Если у вас нет тестовой среды, потратьте час на установку PHP в вашей системе.

Это не является темой данной статьи, но в Google вы можете легко найти, например, «как установить PHP в Windows». Другим хорошим способом работы является использование виртуальной машины. Воспользуйтесь PuPHPet с Vagrant и Virtual Box. Это вовсе несложно. К тому же, вы получите Linux под Windows! И нет проблем!

Если же вы располагаете удаленным сервером для своих опытов, уточните у своего хостера, можете ли вы получить доступ к удаленному рабочему столу или непосредственный доступ к командной строке. Это гораздо менее эффективно, чем установка PHP на своей локальной машине, но это в 100 раз лучше работы по FTP.

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

Подсказка №2: Найдите сообщения об ошибках!

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

Простейший способ проверить, выводятся ли сообщения об ошибках, — это сгенерировать ошибку вроде следующей:

<?php bug(); ?>;

Вы должны увидеть ошибку вроде следующей:

Fatal error: Call to undefined function bug() in ../apache-2.2/htdocs/test.php on line 2

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

Если вы не видите ошибок, вы можете изменить настройки их вывода в своем файле php.ini. Найдите соответствующие строки и измените их:

error_reporting = -1
display_errors = On
display_startup_errors = On
log_errors = On
Замечание. Чтобы эти изменения заработали, вам нужно перезапустить Apache или php-fpm, если используете Nginx.

Опять таки, это настройки для вашей тестовой среды. Не используйте их на живых веб-сайтах!

Далее. Если после изменения настроек вы все еще не видите ошибок в своем браузере, не огорчайтесь, все нормально. Во-первых, они могут быть скрыты в коде HTML. Иногда случается, что ошибки ломают HTML на странице. Просто откройте исходный HTML-код вашей страницы (CTRL+U или CMD+U в большинстве браузеров) и поищите там «Fatal».

Нашли что нибудь? Если все еще нет, существует трюк, который вы можете использовать прямо в коде (в частности, если вы, по каким-то причинам, не имеете доступа к своему файлу php.ini):

<?php 
ini_set('display_errors', '1'); 
error_reporting(E_ALL | E_STRICT); 
... здесь ваш код ... 
?>

Это «перезапишет» значения в конфигурационном файле PHP и все другие значения, которые, возможно, устанавливались перед вашим кодом.

В PHP 5.3 доступна константа E_STRICT. Вам следует знать, что она не включается в E_ALL, так что я сам ее добавляю. Она будет предупреждать вас, когда в коде используются нерекомендованные конструкции, которые могут не поддерживаться в будущем.

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

  • младше, чем 5.3: используйте E_ALL или -1
  • 5.3: используйте E_ALL | E_STRICT или -1
  • старше, чем 5.3: используйте E_ALL или -1

При использовании E_ALL вы будете видеть также и такие «замечания», как «неопределенная переменная». Хорошая мысль — почистить эти предупреждения, чтобы избежать более неприятных багов в дальнейшем.

Чтобы посмотреть актуальное значение «display_errors», вы можете воспользоваться следующей строчкой кода:

echo ini_get('display_errors');

Если вы видите 0 (ноль) или «Off», значит никакие ошибки не будут отображаться непосредственно на ваших веб-страницах.

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

Если ваш PHP запускается под Apache, эти логи обычно находятся в директории, куда установлен этот Apache, в подпапке «logs». Очевидно, что вам понадобится непосредственный доступ к компьютеру, на котором установлен этот Apache.

В случае Nginx-а с php-fpm, следует смотреть лог ошибок php-fpm, если он активирован.

Для чтения этих файлов вам понадобится аналог утилиты tile. Идите в Google и ищите там, например, «утилиту tile для Windows». Такие программы мгновенно показывают изменения в логе ошибок. Я использую BareTail для Windows.

При всем этом я предпочитаю видеть ошибки непосредственно в HTML-коде страницы. Иногда это помогает определить, где произошла ошибка. Например, если вы видите, какая часть страницы была сформирована (поскольку веб-страница показывает результат), то вы знаете, что ошибка произошла после соответствующего куска кода.

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

Продолжение этой статьи: «6 подсказок по отладке для каждого PHP-кодера. Часть 2».

Автор: mogosselin, 23.02.2014
Перевод с английского: Дмитрий Скоробогатов, специально для xBB.uz, 09.04.2014
Оригинальный текст может быть найден по адресу http://www.mogosselin.com/6-debugging-tips-php-coders-should-know/


Предыдущие публикации:

Биржа долевых инвестиций SIMEX.

Последнее редактирование: 2014-04-09 05:42:29

Метки материала: код, отладка, php, практика программирования, кодер, программисты, баги, отладка кода, разработчики, программирование, разработка

Оставьте, пожалуйста, свой комментарий к публикации

Представиться как     Антибот:
   

Просьба не постить мусор. Если вы хотите потестить xBB, воспользуйтесь кнопкой предварительного просмотра на панели инструментов xBBEditor-а.


© 2007-2017, Дмитрий Скоробогатов.
Разрешается воспроизводить, распространять и/или изменять материалы сайта
в соответствии с условиями GNU Free Documentation License,
версии 1.2 или любой более поздней версии, опубликованной FSF,
если только иное не указано в самих материалах.