Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Совершенно нормально и правильно. Неправильно — стесняться выбора подходящих средств. Перед тобой стоит задача понять, как работает код. Ты можешь его хоть расколупать на кусочки копипастом в отдельные программы — лишь бы была решена исходная задача.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Кэр, Вы писали:
Кэр>Если мы говорим об использовании отладчика для поиска ошибок — то вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага. Дебаггер отличный инструмент позволяющий подтвердить теорию о том, где может быть ошибка. Никогда не запускайте дебаггер, если у вас нет теории, что может быть не так и на что нужно посмотреть. Если вы оказались неправы — отойдите от дебаггера и начните анализ сначала. Иначе миру может явиться довольно жалкое зрелище — зачастую отличный инжинер, стоящий приличных денег в час, вслепую тыкающийся в дебаггере то туда, то сюда на протяжении многих часов. Зачастую без малейшой идеи, что было не так — просто надеясь, что его осенит в процессе. При этом перегруженный совершенно лишней информацией, которую в изобилии готов предоствить дебаггер.
Не знаю кто такой John Robbins, но чувак явно не в теме. Правильно написанный код + отладчик позволяют мгновенно и абсолютно точно локализовать проблему без всякого предварительного анализа. John Robbins наверно очень сильно удивится, но в большинстве случаев локализация багов лично у меня состоит из следующих простых действий:
— запуск отладчика,
— повторение действий для воспроизведения бага,
— исключение,
— останов выполнения и автоматический переход в проблемную точку кода.
Всё вместе занимат обычно не более одной минуты. После этого можно начинать анализ, call stack и всё окружение в наличии.
Кстати, замечено, что обычно отладчик критикуют те, кто сам им ещё толком не научился пользоваться. Также забавно наблидать как эти люди потом открывают для себя новые возможности отладчика и искренне этому удивляются и радуются.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Использования дебаггера, чтобы разобраться как работа
IT>Кстати, замечено, что обычно отладчик критикуют те, кто сам им ещё толком не научился пользоваться. Также забавно наблидать как эти люди потом открывают для себя новые возможности отладчика и искренне этому удивляются и радуются.
не умеет пользоватся
умеет пользоватся
умеет не пользоватся
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Не знаю кто такой John Robbins, но чувак явно не в теме. Правильно написанный код + отладчик позволяют мгновенно и абсолютно точно локализовать проблему без всякого предварительного анализа. John Robbins наверно очень сильно удивится, но в большинстве случаев локализация багов лично у меня состоит из следующих простых действий:
IT>- запуск отладчика, IT>- повторение действий для воспроизведения бага, IT>- исключение, IT>- останов выполнения и автоматический переход в проблемную точку кода.
Случаи бывают разные. Когда отлаживаешь чужой код, то можно и два дня под отладчиком просидеть. Вот недавний пример. В суботу всю ночь ловил один баг с помощью отладчика (интеграция открывала один и тот же файл в двух разных закладках (view)). В конце концов локализовал и нашел обходной путь.
Никак за минуту тут не справишся.
Конечно отладчиком мы всегда проверяем некоторые предположения. Сам по себе отладчик мало что даст если мы не знаем как должна вести программа если она работает верно.
Однако идея опасаться отладчика выглядит мягко говоря странной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, VladD2, Вы писали:
IT>>- запуск отладчика, IT>>- повторение действий для воспроизведения бага, IT>>- исключение, IT>>- останов выполнения и автоматический переход в проблемную точку кода.
VD>Случаи бывают разные.
Конечно бывают. Тем не менее между моим предыдущим и этим постом я уже успел пофиксить один баг по такой же схеме. Причём сначала мы с товарищем 15 минут анализировали код и делали всякие умные предположения. Потом мне это надоело и через минуту баг был пофикшен.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, FR, Вы писали:
FR>не умеет пользоватся FR>умеет пользоватся FR>умеет не пользоватся
Это мне напоминает прогрессирование у ресторанных певцов:
выпил — не может петь
выпил — может петь
не выпил — не может петь
Какой смысл не пользоваться? Я пользуюсь отладчиком исключительно из-за собственной лени. Анализировать сотни и даже десятки строк кода мне банально лень. Запуск отладчика решает проблему в большинстве случаев быстро и эффективно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали: IT>Конечно бывают. Тем не менее между моим предыдущим и этим постом я уже успел пофиксить один баг по такой же схеме. Причём сначала мы с товарищем 15 минут анализировали код и делали всякие умные предположения. Потом мне это надоело и через минуту баг был пофикшен.
Медитативная отладка разрешается только начиная с четвёртого дана. Остальным — запуск дебаггера и wax on, wax off...
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Sinclair, Вы писали:
S>Медитативная отладка разрешается только начиная с четвёртого дана. Остальным — запуск дебаггера и wax on, wax off...
Что такое wax?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Не знаю кто такой John Robbins, но чувак явно не в теме. Правильно написанный код + отладчик позволяют мгновенно и абсолютно точно локализовать проблему без всякого предварительного анализа. John Robbins наверно очень сильно удивится, но в большинстве случаев локализация багов лично у меня состоит из следующих простых действий:
IT>- запуск отладчика, IT>- повторение действий для воспроизведения бага, IT>- исключение, IT>- останов выполнения и автоматический переход в проблемную точку кода.
IT>Всё вместе занимат обычно не более одной минуты. После этого можно начинать анализ, call stack и всё окружение в наличии.
Блин. Завидую таким спокойным задачам, которые спокойно могут ждать, пока им "после этого можно начинать анализ", call stack устойчиво даёт информацию о контексте, окружение способно сохраняться на период более полсекунды, и "повторение действий для воспроизведения бага" возможно всегда и не подвергается принципиальному сомнению. Если бы у меня были сплошь такие задачи, я бы сам отладчик использовал на каждом шагу... ;(
IT>Кстати, замечено, что обычно отладчик критикуют те, кто сам им ещё толком не научился пользоваться. Также забавно наблидать как эти люди потом открывают для себя новые возможности отладчика и искренне этому удивляются и радуются.
Так конечно, когда вдруг оказывается (в ~10% случаев) что можно что-то увидеть отладчиком — я радуюсь, как младенец, потому что это становится так просто... Когда дети были маленькие, я радовался погремушкам вместе с ними...
Ничего личного, пардон...
The God is real, unless declared integer.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
Кэр>>Если мы говорим об использовании отладчика для поиска ошибок — то вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага. Дебаггер отличный инструмент позволяющий подтвердить теорию о том, где может быть ошибка. Никогда не запускайте дебаггер, если у вас нет теории, что может быть не так и на что нужно посмотреть. Если вы оказались неправы — отойдите от дебаггера и начните анализ сначала. Иначе миру может явиться довольно жалкое зрелище — зачастую отличный инжинер, стоящий приличных денег в час, вслепую тыкающийся в дебаггере то туда, то сюда на протяжении многих часов. Зачастую без малейшой идеи, что было не так — просто надеясь, что его осенит в процессе. При этом перегруженный совершенно лишней информацией, которую в изобилии готов предоствить дебаггер.
IT>Не знаю кто такой John Robbins, но чувак явно не в теме. На всякий случай давайте зафиксируем, что я просто процитировал его как помню и его имя не является аргументом. Дальше я защищать эту позицию буду со своей точки зрения.
IT>Правильно написанный код + отладчик позволяют мгновенно и абсолютно точно локализовать проблему без всякого предварительного анализа. John Robbins наверно очень сильно удивится, но в большинстве случаев локализация багов лично у меня состоит из следующих простых действий:
IT>- запуск отладчика, IT>- повторение действий для воспроизведения бага, IT>- исключение, IT>- останов выполнения и автоматический переход в проблемную точку кода.
Нет он не удивится, также как не удивлюсь я сам. Дело в том, что первым шагом в этой последовательности все же является тот факт, что у вас (как и у меня) есть теория о том, что в managed коде исключения вещь очень правильная, и если есть понимание как можно сделать репро и увидеть исключение под отладчиком — то зачастую это может быть точнейшей диагностикой проблемы. Таким образом идея, зачем запускается отладчик — найти исключение определенного типа и проанализировать состояние программы в этот момент.
Утверждается здесь следующее — если после пары часов отладки решение так и не найдено (проблема оказалась сложнее чем найти где вылетает OutOfRangeException и понять какой индекс надо исправить), то нужно отойти от отладчика и проанализировать проблему без дебаггера.
Также здесь утверждается что в unmanaged коде, там где нет исключений лучше все же иметь теорию, что собираемся искать, до запуска дебаггера.
IT>Кстати, замечено, что обычно отладчик критикуют те, кто сам им ещё толком не научился пользоваться. Также забавно наблидать как эти люди потом открывают для себя новые возможности отладчика и искренне этому удивляются и радуются.
Re[6]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Mystic, Вы писали:
M>Опять же, это очень хорошо, когда ты знаешь, что надо найти...
Я не утверждал, что нужно "знать" что искать, это не задачка из учебника по физике, где ответ написан в конце задачника, а аудитории требуется подогнать решение под ответ. Это собственно поиск ответа.
M>На практике ситуация зачастую несколько другая. Например, при реализации алгоритма решения цумэ-го я добился того, что он решает простые задачи. После введения одной оптимизации вдруг при решении одной задачи начал появляться неправильный ответ. В процессе решения строится дерево позиций, на которое нетривиальным образом наращиваются новые узлы. Очевидно, что в одном из узлов вернулась неправильная оценка, но как понять в каком из и на какой итерации? M>При решении таких вопросов очень хорошо себя проявили дампы этого дерева позиций и добавление отладочного кода. Чистая отладка начиналась уже после момента диагностики ошибки, а зачастую и не требовалась...
Ну так у вас было четкое понимание, что может быть не так, почему и как использовать отладчик, чтобы найти это. Неправильным на мой взгляд было бы итерироваться вдоль программы, анализируя состояние на каждом шагу, чтобы обнаружить ошибку на 1045 цикле алгоритма.
Re[8]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, netch80, Вы писали:
N>Так конечно, когда вдруг оказывается (в ~10% случаев) что можно что-то увидеть отладчиком — я радуюсь, как младенец, потому что это становится так просто... Когда дети были маленькие, я радовался погремушкам вместе с ними...
Чтобы в процессе взросления памперсы не отдавили чего-нибудь нужного, их следует периодически апгрейдить под растущий организм, а позже перейти на что-нибудь более взрослое. Второй вариант — выкинуть жмущие папмерсы совсем и ходить всю жизнь с голой задницей. Я так понимаю, ты как раз и радуешься этим своим старым памперсам, когда их удаётся опять натянуть
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, netch80, Вы писали:
N>>Так конечно, когда вдруг оказывается (в ~10% случаев) что можно что-то увидеть отладчиком — я радуюсь, как младенец, потому что это становится так просто... Когда дети были маленькие, я радовался погремушкам вместе с ними...
IT>Чтобы в процессе взросления памперсы не отдавили чего-нибудь нужного, их следует периодически апгрейдить под растущий организм, а позже перейти на что-нибудь более взрослое. Второй вариант — выкинуть жмущие папмерсы совсем и ходить всю жизнь с голой задницей. Я так понимаю, ты как раз и радуешься этим своим старым памперсам, когда их удаётся опять натянуть :)
Ну если ты считаешь, что альтернатива памперсам (отладчику) — голая задница, мне добавить нечего.:))
The God is real, unless declared integer.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Кэр, Вы писали:
Кэр>Утверждается здесь следующее — если после пары часов отладки решение так и не найдено (проблема оказалась сложнее чем найти где вылетает OutOfRangeException и понять какой индекс надо исправить), то нужно отойти от отладчика и проанализировать проблему без дебаггера.
Процесс отладки (в любом виде: дебагер или логи) — это неотъемлемая и одна из важнейших частей процесса разработки. С этим мы не будем спорить? А раз так, что сам процесс разработки должен быть заточен под процесс отладки. Чем чаще это правило выдерживается, тем реже приходится отходить от отладчика, чтобы понять что произошло.
Конечно, бывают случаи, когда ни отладчик, ни логи не помогают. Но это чаще связано с проколами в архитектуре и здесь уже не только надо откладывать в сторону дебагер, но даже и код.
Но вопрос как раз не в этом, а в том, что круче — дебагер или логи. По мне так они только дополняют друг друга и не должны противопоставляться.
Кэр>Также здесь утверждается что в unmanaged коде, там где нет исключений лучше все же иметь теорию, что собираемся искать, до запуска дебаггера.
Отлаживайте вы сами ваш unmanaged код.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
N>>Ну если ты считаешь, что альтернатива памперсам (отладчику) — голая задница, мне добавить нечего. IT>Я-то как раз считаю, что в процессе взросления нужно переходить к более взрослым вещам, а не светить голой задницей, оплакивая старый памперс.
Учитывая, что netch занимался создание софтсвитча, то вполне понятно, почему он так плохо думает об отладчике. Он там, действительно, не сильно помогает — многие события зависят от времени, а таймауты часто меньше, чем нужно на детальное обследование ситуации человеком.
Sapienti sat!
Re[8]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Cyberax, Вы писали:
C>Учитывая, что netch занимался создание софтсвитча, то вполне понятно, почему он так плохо думает об отладчике. Он там, действительно, не сильно помогает — многие события зависят от времени, а таймауты часто меньше, чем нужно на детальное обследование ситуации человеком.
Понятно. Об этой небольшой детали нужно было упомянуть сразу. Тогда не было бы один про Ерёму, другой про Фому.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
