Как вы отлаживаете без IDE? [закрыто]

Каждый раз, когда я ищу IDE (в настоящее время я работаю с Go), я нахожу нить, полную людей, которые рекомендуют Vi, Emacs, Notepad ++ и т. Д.

Я никогда не занимался разработкой вне IDE; Я думаю, что я был избалован. Как вы отлаживаете без IDE? Вы ограничены только регистрации?

С помощью отладчика. По большей части, это также то, что IDE делает за кулисами - это просто оборачивает опыт в GUI.

В Unix одним из наиболее часто используемых отладчиков является GNU gdb, который в значительной степени вытеснил более ранние отладчики Unix, такие как dbx.

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

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

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

Что касается чисто программных проблем, я считаю, что думать о проблеме и тестировать систему, чтобы узнать больше о проблеме, гораздо полезнее, чем поэтапно проходить по коду. С помощью операторов print у меня есть список всего, что произошло в командной строке или в файле журнала, на который я могу посмотреть и восстановить то, что произошло, переходя назад и вперед, легче, чем когда-либо с отладчиком.

Самые серьезные ошибки, как правило, решаются путем понимания проблемы вдали от компьютера. Иногда с листом бумаги или доской, а иногда ответ раскрывается, пока я занимаюсь чем-то другим. Самые хитрые ошибки решаются путем тщательного изучения кода, например игры «Где есть Уолдо». Все остальное кажется проще всего с помощью операторов print или logging.

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

Некоторые люди используют GDB в командной строке или плагин . Есть также автономные интерфейсы GUI для GDB, как DDD . В зависимости от вашего языка существуют отдельные языковые графические интерфейсы отладчика, такие как Winpdb для python или jswat для java. Поскольку эти проекты ориентированы только на отладку, они часто превосходят встроенные отладчики.

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

Некоторые языки предлагают REPL - то есть вы можете писать и выполнять код построчно по мере его написания, что может стать первым шагом в проверке фрагмента кода. Многие из них также предлагают средства отладки. GHC для Haskell поставляется с GHCi, который можно использовать для интерактивной отладки программы в командной строке, аналогично тому, как это делает среда IDE.

Я не понимаю, почему существует отвращение к отладке с использованием операторов printf. Было время, когда перекомпиляция и компоновка программы занимала слишком много времени, но сегодня это занимает всего несколько секунд. Я нахожу, что очень легко отлаживать, используя тип вывода cout, printf, qDebug () и т. Д. Операторы printf дают вам историю выполнения всего, что сделала программа, которую вы можете проанализировать после факта, тогда как запуск в отладчике заставляет вас вручную запоминать поток программы во время ее выполнения. С помощью printf вы можете конвертировать значения переменных в определенные единицы, отображать их в шестнадцатеричном, десятичном виде и так далее. Операторы printf могут перечислять имена подпрограмм и переменных, а также номера строк. Вы можете перечислить только определенные элементы массива в зависимости от других переменных. Вы можете следовать указаниям. Вы можете контролировать выход очень легко, вставлять счетчики, печатать только определенное время через цикл, добавлять и удалять операторы печати во время отладки, иметь разные уровни вывода отладочной информации, записи в файлы и т. д. Гораздо проще увидеть историю вашей программы, записанной в файл, чем постарайтесь запомнить все места, через которые вы проходили вручную, и, возможно, придется записать содержимое переменных по мере их изменения во времени, чтобы узнать, что сделала программа. И, наконец, с помощью операторов printf вы можете оставить их постоянно, чтобы включать и выключать их для будущей отладки. Гораздо проще увидеть историю вашей программы, записанной в файл, чем пытаться запомнить все места, которые вы проходили вручную, и, возможно, придется записать содержимое переменных при их изменении во времени, чтобы узнать, что программа сделано. И, наконец, с помощью операторов printf вы можете оставить их постоянно, чтобы включать и выключать их для будущей отладки. Гораздо проще увидеть историю вашей программы, записанной в файл, чем пытаться запомнить все места, которые вы проходили вручную, и, возможно, придется записать содержимое переменных при их изменении во времени, чтобы узнать, что программа сделано. И, наконец, с помощью операторов printf вы можете оставить их постоянно, чтобы включать и выключать их для будущей отладки.

Jimwise достаточно хорошо ответил на вопрос, но я подумал, что должен добавить, что, если вы решите работать без полной IDE, предоставляемый Microsoft отладчик командной строки для Windows называется CDB . CDB поставляется с несколькими другими инструментами, включая WinDBG, который является эквивалентом GUI, при загрузке Windows SDK.

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

Самый важный инструмент в моей работе настолько повсеместен, что я почти забыл упомянуть об этом - следы стека. Более 90% проблем, с которыми я сталкиваюсь, могут быть решены путем изучения трассировки стека. Этот инструмент не всегда очень полезен в зависимости от вашего языка, но когда он хорошо реализован на языке, он может сэкономить вам огромное количество времени.

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

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

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

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

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

Нет причин, по которым вы не можете использовать отладчик в IDE вместе с отдельным текстовым редактором. Раньше я использовал! Zap для редактирования, JBuilder для отладки на другом компьютере и файловый сервер в подвале. Традиционно отладчики были автономными программами без перетаскивания по IDE, и это тоже работает.

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

Там тоже printf. Может быть полезно создать большое количество «логов» и выполнить поиск по ним, а не останавливаться на каждой строке. Я нахожу особенно полезным, если вы можете модифицировать библиотечные классы, которые вы не сможете изменить в рабочей среде, например, используя -Xbootclasspath/p:для взлома библиотечные классы Java.

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

Вы можете использовать pudb - консоль с простым пользовательским интерфейсом. Вы можете выбрать предпочитаемый отладчик, например, pdb или ipdb, если хотите ввести REPL и изучить более подробно.

Также, пожалуйста, проверьте PythonDebuggingTools Wiki для более полной коллекции доступных инструментов.