Здравствуйте, IT, Вы писали:

IT>Не знаю кто такой John Robbins, но чувак явно не в теме.

А John Robbins знает, что ты его не знаешь?

PS. John Robbins является автором книги Debugging Applications for Microsoft® .NET and Microsoft Windows.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Cyberax, Вы писали:

C>>Учитывая, что netch занимался создание софтсвитча, то вполне понятно, почему он так плохо думает об отладчике. Он там, действительно, не сильно помогает — многие события зависят от времени, а таймауты часто меньше, чем нужно на детальное обследование ситуации человеком.

IT>Понятно. Об этой небольшой детали нужно было упомянуть сразу. Тогда не было бы один про Ерёму, другой про Фому.

Значит, ты читаешь собеседников, мягко говоря, очень избирательно. Потому что я про эту "небольшую деталь" написал совершенно ясно:

Блин. Завидую таким спокойным задачам, которые спокойно могут ждать, пока им "после этого можно начинать анализ", call stack устойчиво даёт информацию о контексте, окружение способно сохраняться на период более полсекунды, и "повторение действий для воспроизведения бага" возможно всегда и не подвергается принципиальному сомнению.

Это относится далеко не только к софтсвичу: на текущей работе у меня таких задач не меньше.

Ты же вцепился в упоминание темы младенцев и больше уже ничего не заметил.

Здравствуйте, Cyberax, Вы писали:

IT>>Я-то как раз считаю, что в процессе взросления нужно переходить к более взрослым вещам, а не светить голой задницей, оплакивая старый памперс.
C>Учитывая, что netch занимался создание софтсвитча, то вполне понятно, почему он так плохо думает об отладчике.

Ещё один читатель по диагонали. Я _плохо думаю_?;(( Я же написал — завидую! :)

Здравствуйте, netch80, Вы писали:

N>Значит, ты читаешь собеседников, мягко говоря, очень избирательно. Потому что я про эту "небольшую деталь" написал совершенно ясно:

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

N>

N>Блин. Завидую таким спокойным задачам, которые спокойно могут ждать, пока им "после этого можно начинать анализ", call stack устойчиво даёт информацию о контексте, окружение способно сохраняться на период более полсекунды, и "повторение действий для воспроизведения бага" возможно всегда и не подвергается принципиальному сомнению.

N>Это относится далеко не только к софтсвичу: на текущей работе у меня таких задач не меньше.

Я могу под неспокойными задачами понимать всё что угодно. Я таких задач насмотрелся мильён и все они не имели отношения к софтсвичам.

N>Ты же вцепился в упоминание темы младенцев и больше уже ничего не заметил.

Что ты написал, то я и заметил.

Здравствуйте, igna, Вы писали:

IT>>Не знаю кто такой John Robbins, но чувак явно не в теме.

I>А John Robbins знает, что ты его не знаешь?

Мне это индифферентно.

I>PS. John Robbins является автором книги Debugging Applications for Microsoft® .NET and Microsoft Windows.

Тем более. Лично у меня к человеку, советующему использовать дебаггер как крайнее, последнее средство в процессе отладки бага, возникает после таких советов определённое недоверие. Либо этот парень имел ввиду что-то другое и его переврали, либо но не до конца понимает сам процесс разработки.

А книжки писать дело хорошее. Мартин Фаулер тоже много всего написал. И комьюнити ещё не решило причислить его за это к лику святых или придать анафеме.

Здравствуйте, Кэр, Вы писали:

Кэр>Здравствуйте, ton4eg, Вы писали:
T>>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Кэр>Для того чтобы понять как работает код — дебаггер является хорошим инструментом в том плане, что он позволяет отследить цепочку вызовов и состояние памяти на пути этой цепочки. В более-менее сложном коде порой бывает сложно проследить, что, кого, когда, зачем зовет. Но это только небольшая часть. Я бы сказал что хорошие тулзы анализа кода/навигации по коду вносят гораздо больший вклад.

(+)

Кэр>Если мы говорим об использовании отладчика для поиска ошибок — то вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага. Дебаггер отличный инструмент позволяющий подтвердить теорию о том, где может быть ошибка. Никогда не запускайте дебаггер, если у вас нет теории, что может быть не так и на что нужно посмотреть. Если вы оказались неправы — отойдите от дебаггера и начните анализ сначала. Иначе миру может явиться довольно жалкое зрелище — зачастую отличный инжинер, стоящий приличных денег в час, вслепую тыкающийся в дебаггере то туда, то сюда на протяжении многих часов. Зачастую без малейшой идеи, что было не так — просто надеясь, что его осенит в процессе. При этом перегруженный совершенно лишней информацией, которую в изобилии готов предоствить дебаггер.

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

Здравствуйте, ton4eg, Вы писали:

T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?

Более эфективного способа разобраться в том "что делает" и "как делает" код я не знаю. Какие есть еще альтернативные варианты ?

Здравствуйте, minorlogic, Вы писали:

M>Более эфективного способа разобраться в том "что делает" и "как делает" код я не знаю. Какие есть еще альтернативные варианты ?

Логи.

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, minorlogic, Вы писали:

M>>Более эфективного способа разобраться в том "что делает" и "как делает" код я не знаю. Какие есть еще альтернативные варианты ?

U>Логи.

Какой тип логов? если ручной, то их просто может не быть в программе.

Здравствуйте, Mystic, Вы писали:

N>>Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку.
M>Можно, но часто это бывает следствие бага на 7286-й итерации.

Верно, но чтобы отловить этот баг на 7286-й итерации надо иметь предположение о том, что и как там происходит не так. Для финальной проблемы мы поставим conditional breakpoint. А для того, что её вызвало? Вот тут и начинается настоящая работа — определить, где оно и как.

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

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

Здравствуйте, minorlogic, Вы писали:

M>Какой тип логов? если ручной, то их просто может не быть в программе.

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

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, minorlogic, Вы писали:

M>>Какой тип логов? если ручной, то их просто может не быть в программе.

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

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

Здравствуйте, minorlogic, Вы писали:

M>>>Какой тип логов? если ручной, то их просто может не быть в программе.

M>Что именно актуально? какие такие ? Вы не ответили на мой вопрос, о каких логах идет речь. Я потерял нить рассуждений, помогайте.

Честно говоря, я не понял разделения на ручные и автоматические логи. Ручные это какие? Добавляемые на время отладки? А автоматические логи это те, которые ушли в релиз?

Здравствуйте, Undying, Вы писали:

U>Честно говоря, я не понял разделения на ручные и автоматические логи. Ручные это какие? Добавляемые на время отладки? А автоматические логи это те, которые ушли в релиз?

Хехе.
Полуавтоматический станок для перемотки основы туалетной бумаги в логи<br />
<br />
Назначение: перемотка основы туалетной бумаги в технологические рулончики (логи).

Вот вам и логи... :)

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, minorlogic, Вы писали:

M>>>>Какой тип логов? если ручной, то их просто может не быть в программе.

M>>Что именно актуально? какие такие ? Вы не ответили на мой вопрос, о каких логах идет речь. Я потерял нить рассуждений, помогайте.

U>Честно говоря, я не понял разделения на ручные и автоматические логи. Ручные это какие? Добавляемые на время отладки? А автоматические логи это те, которые ушли в релиз?

Ручные это те которые надо писать вручную , например:

std::cout << "Example log message" << endl;

Автоматические , это например список вызовов функций.

Здравствуйте, minorlogic, Вы писали:

M>Ручные это те которые надо писать вручную , например:
M>Автоматические , это например список вызовов функций.
M>>>>Какой тип логов? если ручной, то их просто может не быть в программе.

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

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, minorlogic, Вы писали:

M>>Ручные это те которые надо писать вручную , например:
M>>Автоматические , это например список вызовов функций.
M>>>>>Какой тип логов? если ручной, то их просто может не быть в программе.

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

Речь идет не об отладке а о знакомствес кодом. В коде может не быть логов в вашем понимании.

Здравствуйте, minorlogic, Вы писали:

M>Речь идет не об отладке а о знакомствес кодом. В коде может не быть логов в вашем понимании.

А кто их мешает добавить? Разве что undo checkout потом сделать надо, дабы изменения на сервер не ушли.

Здравствуйте, Undying, Вы писали:

U>Здравствуйте, minorlogic, Вы писали:

M>>Речь идет не об отладке а о знакомствес кодом. В коде может не быть логов в вашем понимании.

U>А кто их мешает добавить? Разве что undo checkout потом сделать надо, дабы изменения на сервер не ушли.

Не мешает , вопрос в трудоемкости метода, получится ли этот вариант быстрее трассировки в отладчике

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Кэр, Вы писали:

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

IT>Процесс отладки (в любом виде: дебагер или логи) — это неотъемлемая и одна из важнейших частей процесса разработки. С этим мы не будем спорить?

Почему вам показалось, что я с этим спорю?

IT>А раз так, что сам процесс разработки должен быть заточен под процесс отладки. Чем чаще это правило выдерживается, тем реже приходится отходить от отладчика, чтобы понять что произошло.

Импликация ложная. Некоторые проблемы — многопоточность, особо сложные алгоритмы, пр. — просто сложно отлаживать. И когда применяется подход "что там думать — запускаем дебаггер и пробуем получить пошагово получить репро и понять что произошло" — то в результате времени может уйти гораздо больше.
Возвращаясь к изначальному вашему примеру про исключение — у вас было репро, у вас было желание увидеть код и данные в месте, где вылетело исключение. Это очень полезная информация для анализа — дебаггер должен быть запущен моментально. Но это не является всеобщим рецептом только из-за этого частного случая.
Одна из наиболее сложных проблем в отладке — когда нет четкого репро. Вот тут лучше сначала подумать перед тем как прыгать и запускать дебаггер.
Надо еще оговориться, если код вы знаете уже очень хорошо и много о нем уже думали, то время пред-дебажного анализа у вас в среднем получается гораздо меньше, чем в самом начале ознакомления с кодом. Но это получается естественным путем. Главный критерий запуска дебаггера остается по-прежнему — должна быть конкретная теория, что хочется увидеть в дебаггере, и как это может помочь в поиске изначальной ошибки.

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

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

IT>Но вопрос как раз не в этом, а в том, что круче — дебагер или логи. По мне так они только дополняют друг друга и не должны противопоставляться.

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

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

Я сам managed код люблю гораздо больше. Но совсем закрывать глаза на unamanged не стоит — это искусственное ограничение. После того как тот же John Robbins на семинаре показал как можно отлаживать x64 release binary код без подгруженных символов — я знаю что это возможно. При этом я примерно теперь понимаю, сколько это стоит и могу примерно оценить подобную работу. Раньше мне этого делать просто ни разу не приходилось (и я, честно говоря, надеюсь что не придется).
Но если через некоторое время у меня будет своя контора и кто-нибудь мне будет утверждать что отлаживать ассемблерный код "супер невозможно" или наоборот "работы на пару часов" — я буду понимать, что либо человек не понимает что он говорит, либо пытается вермишель развесить сушиться.