debugging - подключения - отладка php phpstorm




Почему отладка лучше в среде IDE? (20)

В дополнение к большей части того, что говорили другие плакаты, мне очень нравится переходить через одну линию одновременно с компьютером, поскольку это заставляет меня думать об одной строке за раз. Часто я поймаю ошибку, даже не рассматривая переменные значения просто потому, что я вынужден смотреть на нее, когда я нажимаю кнопку «следующая строка». Однако, я не думаю, что мой ответ поможет вам, Билл, потому что у вас, вероятно, уже есть этот навык.

Что касается учебных ресурсов, я не использовал их - я просто изучаю все меню и варианты.

Я занимаюсь разработкой программного обеспечения более двадцати лет, программируя на C, Perl, SQL, Java, PHP, JavaScript и недавно Python. У меня никогда не было проблемы, которую я не мог отлаживать, используя некоторые продуманные мысли и хорошо отлаженные отладочные операторы print .

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

Более того, я никогда не читал учебник или книгу, в которых показано, как эффективно отлаживать работу с помощью среды IDE, за исключением того, как устанавливать точки останова и отображать содержимое переменных.

Что мне не хватает? Что делает инструменты отладки IDE намного эффективнее, чем вдумчивое использование диагностических отчетов для print ?

Можете ли вы предложить ресурсы (учебники, книги, скринкасты), которые показывают более тонкие методы отладки IDE?

Сладкие ответы! Большое спасибо всем за то, что нашли время. Очень освещается. Я проголосовал за многих и не проголосовал.

Некоторые заметные моменты:

  • Отладчики могут помочь мне провести специальную проверку или изменение переменных, кода или любого другого аспекта среды выполнения, тогда как для ручной отладки требуется остановить, отредактировать и повторно выполнить приложение (возможно, требуя перекомпиляции).
  • Отладчики могут присоединяться к запущенному процессу или использовать аварийный дамп, тогда как при ручной отладке необходимы «шаги для воспроизведения» дефекта.
  • Отладчики могут легко отображать сложные структуры данных, многопоточные среды или полные стеки во время выполнения.
  • Отладчики предлагают множество способов сократить время и повторяющуюся работу, чтобы выполнять практически любые задачи отладки.
  • Визуальные отладчики и консольные отладчики полезны и имеют множество общих черт.
  • Визуальный отладчик, интегрированный в среду IDE, также обеспечивает удобный доступ к интеллектуальному редактированию и всем другим функциям среды IDE в единой интегрированной среде разработки (отсюда и название).

В качестве альтернативы отладке в среде IDE вы можете попробовать отличную консоль PHP для Google Chrome с помощью php-библиотеки, которая позволяет:

  • См. Ошибки и исключения в консоли Chrome JavaScript и всплывающих окнах уведомлений.
  • Дамп переменной любого типа.
  • Выполнить PHP-код удаленно.
  • Защитите доступ по паролю.
  • Журналы групповой консоли по запросу.
  • Перейти к файлу ошибки: строка в текстовом редакторе.
  • Копировать ошибки / отладочные данные в буфер обмена (для тестеров).

Вот одна вещь, которую вы определенно не можете отлаживать с помощью инструкции «print», когда клиент приносит вам дамп памяти и говорит: «Ваша программа разбилась, можете ли вы сказать мне, почему?»


Как сказал кто-то выше: Debugger! = IDE.

gdb и (обратно в день) TurboDebugger (автономный) отлично подходит для языков, которые они поддерживают [ed], спасибо. (или еще более старая технология: отладчик Clipper, связанный с исполняемым файлом xBase) - ни одна из них не требовала IDE

Кроме того, хотя кодирование C / ++ встречается реже, заявления printf иногда маскируют ту самую ошибку, которую вы пытаетесь найти! (например, проблемы инициализации в auto vars в стеке или распределение / выравнивание памяти)

Наконец, как утверждают другие, вы можете использовать оба варианта. Некоторые проблемы в реальном времени почти требуют печати или, по крайней мере, разумного «* video_dbg = (is_good? '+': '-'); где-то в видеопамяти. Мой возраст показывает, это было под DOS :-)

TMTOWTDI


Ну, еще одна вещь: если вы присоединитесь к новому старому проекту, и никто не знает, как код делает то, что он делает, тогда вы не можете отлаживать, повторяя переменные / объекты / ... b / c, вы не представляете, какой код выполненных вообще.

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

С наилучшими пожеланиями

Раффаэль


Одна вещь, которую я удивляюсь, я не видел в другом ответе, что два метода отладки не являются взаимоисключающими .

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

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


Отладка в среде IDE неоценима в среде, где журналы ошибок и доступ к оболочке недоступны, например общий хост. В этом случае IDE с удаленным отладчиком - единственный инструмент, который позволяет вам выполнять простые вещи, такие как просмотр stderr или stdout .


По моему опыту, простые распечатки имеют одно огромное преимущество, о котором никто не упоминает.

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

В отличие от этого, выбранная серия распечаток / протоколирования дает вам «пространственную проекцию временных событий». Это дает вам полную информацию о том, что произошло, и вы можете вернуться назад и четверть несколько раз очень просто, просто прокручивая вверх и вниз. Это позволяет легко ответить на такие вопросы, как «произошло ли А до того, как Б». Это может заставить вас увидеть шаблоны, которые вы даже искали.

Так что, по моему опыту. IDE и отладчики - это фантастические инструменты для решения простых задач, когда что-то в одном стеке вызовов ошибочно и изучает текущее состояние машины при определенном сбое.

Однако, когда мы приближаемся к более сложным проблемам, когда речь идет о постепенном изменении состояния. Где, например, один алгоритм исказил структуру данных, что, в свою очередь, вызвало отказ алгоритма анотер. Или, если мы хотим ответить на такие вопросы, как «как часто это происходит», «делать что-то в порядке и в том, как я себе представляю, что это произойдет». и т. д. Тогда «старая сфабрикованная» техника регистрации / распечатки имеет явное преимущество.

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

Существуют также гибридные подходы. Например, когда вы выполняете console.log (объект), вы получаете виджет структуры данных в журнале, который вы можете расширить и изучить более подробно. Это многократно дает явное преимущество перед «мертвым» текстовым журналом.


Поскольку вы просили указатели на книги ... Что касается отладки Windows, у Джона Роббинса есть несколько выпусков хорошей книги по отладке Windows:

Отладка приложений для Microsoft .NET и Microsoft Windows

Обратите внимание, что последнее издание ( отладка приложений Microsoft .NET 2.0 ) - это только .NET, поэтому вам может понадобиться более старая (как в первой ссылке), если вы хотите отлаживать собственный код (он охватывает как .NET, так и native).


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

К сожалению, человеческий мозг только однопоточный.


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


Просто хотел упомянуть полезную функцию консольного отладчика vs printf и vs отладчика в среде IDE.

Вы можете подключиться к удаленному приложению (obvioustly, скомпилированному в режиме DEBUG) и проверить его состояние, выгружая вывод отладчика в файл с помощью утилиты POSIX tee . По сравнению с printf вы можете выбрать, где выводить состояние во время выполнения.

Это помогло мне, когда я отлаживал приложения Adobe Flash, развернутые в агрессивной среде . Вам просто нужно определить некоторые действия, которые печатают требуемое состояние в каждой точке останова, запустить консольный отладчик с помощью fdb | tee output.log fdb | tee output.log и пройдите через некоторые точки останова. После этого вы можете распечатать журнал и проанализировать информацию путем тщательного сравнения состояния в разных точках останова.

К сожалению, эта функция [запись в файл] редко доступна в отладчиках GUI, что позволяет разработчикам сравнивать состояние объектов в их голове.

Кстати, я считаю, что нужно планировать, где и что отлаживать, прежде чем смотреть на отладчика.


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

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

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

Я чувствую, что отладчики лучше для некоторых языков, чем для других, однако ...

Мое общее мнение заключается в том, что отладчики IDE абсолютно, удивительно замечательны для управляемых языков, таких как Java или C #, довольно полезны для C ++ и не очень полезны для языков сценариев, таких как Python (но может быть, что я просто не пробовал debugger для любых языков сценариев).

Мне очень нравится отладчик в IntelliJ IDEA, когда я занимаюсь разработкой Java. Я просто использую инструкции печати, когда я использую Python.


Это даже реальный вопрос от реального программиста?

Любой, кто потратил даже 5 минут на отладку с заявлениями печати и отладкой с помощью IDE, - он ОБЕСПЕЧИЛ ему / ей, даже не спрашивая!


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

Тем не менее, вы действительно должны знать, как использовать пошаговый отладчик, поскольку для другого класса ошибок это проще. Я оставлю это до других отличных ответов, уже отправленных, чтобы объяснить, почему :)


Я использовал как отпечатки, так и IDE для отладки, и я бы скорее отлаживал использование среды IDE. Единственное время для меня, когда это не работает, - это критические ситуации во времени (например, отладка онлайн-игр), где вы замаскируете код инструкциями печати, а затем смотрите на файлы журнала после того, как он ужасно ошибочно. Тогда, если вы все еще не можете понять это, добавьте больше отпечатков и повторите.


Я не развиваюсь почти 20 лет, но я считаю, что с помощью IDE / отладчика я могу:

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

It's not just debugging. An IDE helps you build better software faster in a lot of ways:

  • refactoring tools
  • intellisense to make api's more discoverable, or remind of exact spelling/case of familiar items(not much use if you've used the same system for 15 years, but that's rare)
  • save on typing by autocompleting variable and class names
  • find certain kinds of errors before you even start to compile
  • Automatically jump to variable/method/class declarations/definitions, even if they're not in the same file or folder.
  • Break on unhandled and handled exceptions

I could go on.


  • Отладчик IDE позволяет изменять значения переменных во время выполнения.

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

  • Отладчик IDE позволяет видеть стек вызовов и проверять состояние функции, переданной странными значениями. (думайте, что эта функция вызывается из сотен мест, вы не знаете, откуда эти странные значения)

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

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


  • Отладчик может подключаться к запущенному процессу

  • Часто проще отлаживать потоковый код от отладчика





ide