Настоящие программисты используют отладчики? [закрыто]

Если опытные программисты действительно когда-либо используют отладчики, и если да, то при каких обстоятельствах. Хотя в ответе на этот вопрос я сказал «месяцы» назад, я, вероятно, имел в виду «годы» - я действительно не использую отладчик. Итак, мой конкретный вопрос: при каких обстоятельствах вы, как опытный программист, используете отладчик?

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

Я часто использую отладчик, потому что я работаю в большой системе, и поэтому я отстой. http://steve-yegge.blogspot.com/2007/06/rich-programmer-food.html

Независимо от того, насколько короток и часто читается ваш код, всегда будет вероятность того, что в нем будут ошибки. http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

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

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

Итак, когда мне не нужен отладчик?

Я не самый умный программист и не самый опытный, но все же иногда мне не нужно использовать отладчик. Вот когда:

• Код мой или хорошо написанный И
• Он написан на читаемом языке И
• Общий проект небольшой.

Когда я сильно полагаюсь на отладчик?

• Краткий ответ: часто .
• Когда приложение вылетает. Особенно когда это развернуто. Установив VS2010 на этот компьютер, вы можете изменить разницу между «Неизвестной ошибкой» и FileNotFoundException.
• Когда происходит сбой или плохая работа сторонней библиотеки.
• Когда код плохо написан. В частности, если за один и тот же файл за последние 10 лет работали 10 разных людей, 7 из которых больше не работают в компании.
• Когда проект большой
• Когда код достаточно монолитный.
• Когда задействовано несколько уровней (GUI, SQL, BL).

Обратите внимание, что «отладчик» может относиться к более чем одному инструменту. Я использую отладчик Visual Studio, отладчик SQL (в основном для хранимых процедур), а также профилировщик SQL (чтобы выяснить, какой SP вызывается). Буду ли я нуждаться в инструментах такого калибра, которые я написал для быстрого Python-скрипта sysadmin-ish? Нет. Если бы я сделал свой собственный маленький инструмент на основе графического интерфейса? Зависит. Если это .Net WinForms - вероятно, нет. Если это WPF - да.

Что в любом случае определяет «настоящий» программист? Тот, который быстро? осведомленный? Хорошо в алгоритмах? Пишет хорошую документацию? Только когда точно кто-то выпускается в этом новом названии? Когда человек пересекает магическую линию?

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

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

...

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

«Я не люблю отладчики. Никогда, наверное, никогда не буду». - Линус Торвальдс

С другой стороны, у него нет учетной записи переполнения стека, поэтому я не уверен, что вам интересно его мнение :)

Итак, мой конкретный вопрос: при каких обстоятельствах вы, как опытный программист, используете отладчик?

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

Редактировать:

Мне повезло / не повезло, что я не знал, как использовать отладчик в моем программировании. Таким образом, в прошлом я был вынужден отлаживать без отладчика. Однако после обучения использованию отладчика -> я стал в 100 раз более продуктивным в поиске ошибок.

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

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

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

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

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

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

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

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

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

Редко.

Ваши методы должны быть небольшими / достаточно простыми, чтобы их можно было скомпилировать и запустить, модульные тесты должны охватывать функциональность. Если вы найдете ошибку, напишите тест. Запустите это, исправьте это.

Я склонен использовать отладчик только в том случае, если я получил неожиданное поведение от непроверяемого кода, такого как среда ASP.NET.

В Smalltalk я почти полностью разрабатываю в отладчике:

1. Написать тест, который я знаю, не удастся.
2. Запустите тест. Когда это не удается, появляется отладчик.
3. Напишите в отладчике код, необходимый для прохождения теста.
4. Возобновить исполнение.
5. Если я получил зеленый свет, перейдите к шагу 1 с новым провальным тестом. В противном случае в отладчике выясните, что я сделал не так и исправьте.

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

Я должен признать, что использую отладчики все меньше и меньше. Я работаю в Delphi более 10 лет. Я также пишу хранимые процедуры в PL / SQL. Уже пару месяцев я тоже PHP-разработчик.

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

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

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

Я иногда кодирую без отладчика, но только когда вынужден под дулом пистолета, т.е. Устаревший встроенный Gunge на 8051 или Z80.

ИМХО, вам нужен отладчик и вход на любую сложную работу. Один раз не заменит другого. Система регистрации не может помочь, если приложение, например, загружается в драйвер, где единственное, что может сделать код, это взаимодействовать с оборудованием и устанавливать семафор.

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

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

Я должен иметь оба - мне нужна вся помощь, которую я могу получить!

Я использую отладчик только в случае сбоя этих шагов:

1. Получите ошибку, воспроизводимую. Думать. Это часто все, что нужно.
2. Проверьте все трассировки стека и журналы.
3. Добавьте больше журналов вокруг оскорбительного кода.

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

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

Может ли быть так, что очень опытные программисты такие же, как очень старые программисты, и они учились программировать и формировали свои привычки, когда отладчики были не всегда доступны, а иногда и не очень хороши?

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

Это вопрос личного выбора.

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

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

Помимо этих двух функций, я не думаю, что отладчик действительно необходим; любая сложная программа, которую вы делаете, должна иметь своего рода «подробный» режим, то есть сообщать обо всем, что она делает с printf или std :: cout, о том, что она сделала, и множестве других параметров.

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

Отладчики похожи на электрическое рулевое управление для вашего автомобиля: иметь его удобнее, но оно не улучшит вашу езду.

Progamming - это дизайн и логика, то, как инструменты могут помочь вам отслеживать вещи, не делает вас лучшим программистом.

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