Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Re: Использования дебаггера, чтобы разобраться как работает
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
дело вкуса
А философски неверно писать программы с ошибками
Надо писать сразу без ошибок, тогда и дебаггеры, логгеры и прочие юнит-тесты не будут никому нужны.
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Если это помогает разобраться быстрее — значит правильно, если нет — значит неправильно
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Если разбираешься и поддерживаешь чужой код, то да — без отладчика порой не обойтись. Когда пишешь сам, то я предпочитаю использованию отладчика качественное проектирование и аккуратное кодирование. Во всяком случае стремлюсь к тому, чтобы обойтись без него.
P.S. Кажется Дейкстра сравнивал отладчик с костылями
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, ton4eg, Вы писали:
T>>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
J>дело вкуса
J>А философски неверно писать программы с ошибками J>Надо писать сразу без ошибок, тогда и дебаггеры, логгеры и прочие юнит-тесты не будут никому нужны.
Дык код не свой! Код чужой и нада его править. Свой понятно был бы без ошибок и понятный
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, ton4eg, Вы писали:
T>Дык код не свой! Код чужой и нада его править.
Сначала нужно его понять. Отладчик и логи это крайний случай, для проверки теорий.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Использования дебаггера, чтобы разобраться как работа
log("enter");
if ( full_moon_madness() ) log ("full_moon_madness");
log("exit");
наблюдая вывод, 2е сообщение можно увидеть, а можно и нет нет.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, fplab, Вы писали:
F>Здравствуйте, ton4eg, Вы писали:
T>>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
F>Если разбираешься и поддерживаешь чужой код, то да — без отладчика порой не обойтись. Когда пишешь сам, то я предпочитаю использованию отладчика качественное проектирование и аккуратное кодирование. Во всяком случае стремлюсь к тому, чтобы обойтись без него.
F>P.S. Кажется Дейкстра сравнивал отладчик с костылями
Костыли гораздо лучше дебаггера.
С костылями можно найти оригинального разработчика и надавать ему этими костылями по шее.
А дебаггером — что ты ему сделаешь...
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Надо быть идиотом чтобы не пользоваться инструментом который ускоряет решение проблем.
Отладчик это лог на стероидах. Он позволяет куда более интерактивно исследовать происходящее в коде.
Логи тоже имеют свои преимущества. Они не блокируют выполнение и они позволяют видеть происходящее в динамике.
Это два взаимодополняющих средства поиска ошибок. Если у вас нет ошибок, то вам не нужны ни логи, ни отладчик. Но тогда скорее всего вы не программисты.
ЗЫ
Больше всего разговоров о ненужности отладчиков исходит от тех кто пользуется средствами разработки не имеющими отладчиков вовсе или имеющие отладчики плохого качества. Далее чтобы успокоить свое сознание (которое понимает, что что-то не так) они сами себе проводят внушение, что мол, отладчики не нужны и даже вредны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Использования дебаггера, чтобы разобраться как работа
VD>Отладчик это лог на стероидах. Он позволяет куда более интерактивно исследовать происходящее в коде. VD>Логи тоже имеют свои преимущества. Они не блокируют выполнение и они позволяют видеть происходящее в динамике. VD>Это два взаимодополняющих средства поиска ошибок. Если у вас нет ошибок, то вам не нужны ни логи, ни отладчик. Но тогда скорее всего вы не программисты.
Ну все правильно написано, но вопрос был немного не о том. Что насчет использования отладчика для понимания функционирования кода.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, ton4eg, Вы писали:
T>Ну все правильно написано, но вопрос был немного не о том. Что насчет использования отладчика для понимания функционирования кода.
А какие логи ты хочешь читать, чтобы понять чужой код? Те, которые создает автор исходного кода? А откуда ты знаешь, что он туда пишет и насколько подробно?
Или те логи, записи в которые которые ты будешь сам вставлять по коду? А как ты сможешь их осмысленно вставить, если пока еще не понимаешь, как работает код?
Если ты хочешь туда понавставлять вывод разных переменных — то это будет тот же отладчик только в профиль. Разница будет — исключительно в динамике и удобстве, как сказал Vlad
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, ton4eg, Вы писали:
T>Ну все правильно написано, но вопрос был немного не о том. Что насчет использования отладчика для понимания функционирования кода.
Совершенно нормально. Если ты не понимаешь как функционирует код, то ни исправить ошибки не выйдет, ни изменить. Точнее может и выйдет, но потом с огромной вероятностью придется искать ошибки.
Другой вопрос, что код в котором без отладчика ничего не понять — это плохой код.
Конечно нужно стараться писать код который очевиден как божий день. Но если уже есть код, и в нем нужно разбираться, то отладчик и логи отличные средства для этого.
Я вот скажу честно... В коде компилятора Nemerle мне помог разобраться именно отладчик. С его помощью я исправил кучу багов и нехило доработал компилятор. В это же время авторы языка пасовали, так как использовали только логи для отладки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Почему не правильно? Считай, что дебаггер это тот же расширенный лог на каждой строке. Плюс вывод некоторого окружения этой строки. С другой стороны дебаггер ограничен скоростью человека. Поэтому при выполнении сложных увесистых алгоритмов пользы от него мало. Особенно, если нужный эффект проявляется, скажем, на 19624-й итерации. Тогда нужна изобретательность. А вот лог можно потом проанализировать автоматическими средствами.
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Для того чтобы понять как работает код — дебаггер является хорошим инструментом в том плане, что он позволяет отследить цепочку вызовов и состояние памяти на пути этой цепочки. В более-менее сложном коде порой бывает сложно проследить, что, кого, когда, зачем зовет. Но это только небольшая часть. Я бы сказал что хорошие тулзы анализа кода/навигации по коду вносят гораздо больший вклад.
Если мы говорим об использовании отладчика для поиска ошибок — то вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага. Дебаггер отличный инструмент позволяющий подтвердить теорию о том, где может быть ошибка. Никогда не запускайте дебаггер, если у вас нет теории, что может быть не так и на что нужно посмотреть. Если вы оказались неправы — отойдите от дебаггера и начните анализ сначала. Иначе миру может явиться довольно жалкое зрелище — зачастую отличный инжинер, стоящий приличных денег в час, вслепую тыкающийся в дебаггере то туда, то сюда на протяжении многих часов. Зачастую без малейшой идеи, что было не так — просто надеясь, что его осенит в процессе. При этом перегруженный совершенно лишней информацией, которую в изобилии готов предоствить дебаггер.
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Mystic, Вы писали:
M>Почему не правильно? Считай, что дебаггер это тот же расширенный лог на каждой строке. Плюс вывод некоторого окружения этой строки. С другой стороны дебаггер ограничен скоростью человека. Поэтому при выполнении сложных увесистых алгоритмов пользы от него мало. Особенно, если нужный эффект проявляется, скажем, на 19624-й итерации. Тогда нужна изобретательность. А вот лог можно потом проанализировать автоматическими средствами.
Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку.
The God is real, unless declared integer.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, netch80, Вы писали:
N>Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку.
Можно, но часто это бывает следствие бага на 7286-й итерации.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, netch80, Вы писали:
N>>Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку.
M>Можно, но часто это бывает следствие бага на 7286-й итерации.
Совершено не обязательно ставить условие на номер итерации. Вариантов масса. Другое дело, что нужно заранее представлять, что пытаешься найти, а не просто шарить вслепую.
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Наиболее филосовски верное решение — распечатать ассемблерный код программы, обклеить им всю стену, сесть перед ней в позе йога и сидеть до полного просветления.
Re[5]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Кэр, Вы писали:
Кэр>Совершено не обязательно ставить условие на номер итерации. Вариантов масса. Другое дело, что нужно заранее представлять, что пытаешься найти, а не просто шарить вслепую.
Для того, чтобы понять, что надо найти, надо проводить диагностику. Скажем так, была такая проблема: я писал решатель цумэ-го и при прогоне тестов ряд из них пе
Опять же, это очень хорошо, когда ты знаешь, что надо найти... На практике ситуация зачастую несколько другая. Например, при реализации алгоритма решения цумэ-го я добился того, что он решает простые задачи. После введения одной оптимизации вдруг при решении одной задачи начал появляться неправильный ответ. В процессе решения строится дерево позиций, на которое нетривиальным образом наращиваются новые узлы. Очевидно, что в одном из узлов вернулась неправильная оценка, но как понять в каком из и на какой итерации?
При решении таких вопросов очень хорошо себя проявили дампы этого дерева позиций и добавление отладочного кода. Чистая отладка начиналась уже после момента диагностики ошибки, а зачастую и не требовалась...
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, 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 занимался создание софтсвитча, то вполне понятно, почему он так плохо думает об отладчике. Он там, действительно, не сильно помогает — многие события зависят от времени, а таймауты часто меньше, чем нужно на детальное обследование ситуации человеком.
Понятно. Об этой небольшой детали нужно было упомянуть сразу. Тогда не было бы один про Ерёму, другой про Фому.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Cyberax, Вы писали:
C>>Учитывая, что netch занимался создание софтсвитча, то вполне понятно, почему он так плохо думает об отладчике. Он там, действительно, не сильно помогает — многие события зависят от времени, а таймауты часто меньше, чем нужно на детальное обследование ситуации человеком.
IT>Понятно. Об этой небольшой детали нужно было упомянуть сразу. Тогда не было бы один про Ерёму, другой про Фому.
Значит, ты читаешь собеседников, мягко говоря, очень избирательно. Потому что я про эту "небольшую деталь" написал совершенно ясно:
Блин. Завидую таким спокойным задачам, которые спокойно могут ждать, пока им "после этого можно начинать анализ", call stack устойчиво даёт информацию о контексте, окружение способно сохраняться на период более полсекунды, и "повторение действий для воспроизведения бага" возможно всегда и не подвергается принципиальному сомнению.
Это относится далеко не только к софтсвичу: на текущей работе у меня таких задач не меньше.
Ты же вцепился в упоминание темы младенцев и больше уже ничего не заметил.
The God is real, unless declared integer.
Re[8]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Cyberax, Вы писали:
IT>>Я-то как раз считаю, что в процессе взросления нужно переходить к более взрослым вещам, а не светить голой задницей, оплакивая старый памперс. C>Учитывая, что netch занимался создание софтсвитча, то вполне понятно, почему он так плохо думает об отладчике.
Ещё один читатель по диагонали. Я _плохо думаю_?;(( Я же написал — завидую! :)
The God is real, unless declared integer.
Re[10]: Использования дебаггера, чтобы разобраться как работ
Здравствуйте, netch80, Вы писали:
N>Значит, ты читаешь собеседников, мягко говоря, очень избирательно. Потому что я про эту "небольшую деталь" написал совершенно ясно:
Я читаю прежде всего в контексте темы или подтемы, на которую мы съехали в процессе обсуждения. Если намерен тему повернуть в другую сторону, то должен сделать это явно, а не расчитывать на телепатические способности собеседников.
N>
N>Блин. Завидую таким спокойным задачам, которые спокойно могут ждать, пока им "после этого можно начинать анализ", call stack устойчиво даёт информацию о контексте, окружение способно сохраняться на период более полсекунды, и "повторение действий для воспроизведения бага" возможно всегда и не подвергается принципиальному сомнению.
N>Это относится далеко не только к софтсвичу: на текущей работе у меня таких задач не меньше.
Я могу под неспокойными задачами понимать всё что угодно. Я таких задач насмотрелся мильён и все они не имели отношения к софтсвичам.
N>Ты же вцепился в упоминание темы младенцев и больше уже ничего не заметил.
Что ты написал, то я и заметил.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Тем более. Лично у меня к человеку, советующему использовать дебаггер как крайнее, последнее средство в процессе отладки бага, возникает после таких советов определённое недоверие. Либо этот парень имел ввиду что-то другое и его переврали, либо но не до конца понимает сам процесс разработки.
А книжки писать дело хорошее. Мартин Фаулер тоже много всего написал. И комьюнити ещё не решило причислить его за это к лику святых или придать анафеме.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, ton4eg, Вы писали: T>>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них? Кэр>Для того чтобы понять как работает код — дебаггер является хорошим инструментом в том плане, что он позволяет отследить цепочку вызовов и состояние памяти на пути этой цепочки. В более-менее сложном коде порой бывает сложно проследить, что, кого, когда, зачем зовет. Но это только небольшая часть. Я бы сказал что хорошие тулзы анализа кода/навигации по коду вносят гораздо больший вклад.
(+)
Кэр>Если мы говорим об использовании отладчика для поиска ошибок — то вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага. Дебаггер отличный инструмент позволяющий подтвердить теорию о том, где может быть ошибка. Никогда не запускайте дебаггер, если у вас нет теории, что может быть не так и на что нужно посмотреть. Если вы оказались неправы — отойдите от дебаггера и начните анализ сначала. Иначе миру может явиться довольно жалкое зрелище — зачастую отличный инжинер, стоящий приличных денег в час, вслепую тыкающийся в дебаггере то туда, то сюда на протяжении многих часов. Зачастую без малейшой идеи, что было не так — просто надеясь, что его осенит в процессе. При этом перегруженный совершенно лишней информацией, которую в изобилии готов предоствить дебаггер.
согласен только в одном — негоже профессионалу разумному идти на поводу у инструмента, своя идея должна преобладать и рулить процессом. а вот в частностях того какая это идея, тут "John Robbins" передергивает ("вслепую тыкающийся в дебаггере"), и излишне обобщает.
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Более эфективного способа разобраться в том "что делает" и "как делает" код я не знаю. Какие есть еще альтернативные варианты ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, minorlogic, Вы писали:
M>Более эфективного способа разобраться в том "что делает" и "как делает" код я не знаю. Какие есть еще альтернативные варианты ?
Логи.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, minorlogic, Вы писали:
M>>Более эфективного способа разобраться в том "что делает" и "как делает" код я не знаю. Какие есть еще альтернативные варианты ?
U>Логи.
Какой тип логов? если ручной, то их просто может не быть в программе.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Mystic, Вы писали:
N>>Ну чтобы поймать на 19624-й итерации, можно применить, например, conditional breakpoint. А тогда уже рассматривать обстановку. M>Можно, но часто это бывает следствие бага на 7286-й итерации.
Верно, но чтобы отловить этот баг на 7286-й итерации надо иметь предположение о том, что и как там происходит не так. Для финальной проблемы мы поставим conditional breakpoint. А для того, что её вызвало? Вот тут и начинается настоящая работа — определить, где оно и как.
Собственно это и есть вопрос о том, как грамотно применять отладчик в реальных задачах. Как уже тут сказано (Кэр, цитата из John Robbins) — надо иметь хотя бы первичное представление о том, что и как смотреть, чтобы не топать пошагово. А вот тут уже начинается использование отладчика не как средства раздолбать клавиатуру, а осмысленно, что означает
— условные точки останова
— реакции по точкам останова (печать значений, проверка дополнительных условий, вызов кода)
Твой последующий пример с деревом позиций — вариант решения того же с другой стороны — чтобы то же дерево позиций печаталось основным кодом, а не кодом отладчика. Это тоже правильное решение, но при выборе между основным кодом и отладчиком надо представлять себе, может ли этот диагностический код потребоваться в будущем. Как правило — может, поэтому я стараюсь все подобные отладочно-диагностические действия или просчитывать заранее (тогда надо для их активизации выставить достаточные уровни отладки при сборке и в рантайме), или дорабатывать по месту сбоя, но тогда уже коммитить в постоянный код.
The God is real, unless declared integer.
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, minorlogic, Вы писали:
M>Какой тип логов? если ручной, то их просто может не быть в программе.
Это актуально только для низкоуровневых программ, вроде драйверов. Такие программы действительно отлаживать неудобно, т.к. для них остается только отладчик со всеми его ограничениями.
Re[5]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, minorlogic, Вы писали:
M>>Какой тип логов? если ручной, то их просто может не быть в программе.
U>Это актуально только для низкоуровневых программ, вроде драйверов. Такие программы действительно отлаживать неудобно, т.к. для них остается только отладчик со всеми его ограничениями.
Что именно актуально? какие такие ? Вы не ответили на мой вопрос, о каких логах идет речь. Я потерял нить рассуждений, помогайте.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, minorlogic, Вы писали:
M>>>Какой тип логов? если ручной, то их просто может не быть в программе.
M>Что именно актуально? какие такие ? Вы не ответили на мой вопрос, о каких логах идет речь. Я потерял нить рассуждений, помогайте.
Честно говоря, я не понял разделения на ручные и автоматические логи. Ручные это какие? Добавляемые на время отладки? А автоматические логи это те, которые ушли в релиз?
Re[7]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Undying, Вы писали:
U>Честно говоря, я не понял разделения на ручные и автоматические логи. Ручные это какие? Добавляемые на время отладки? А автоматические логи это те, которые ушли в релиз?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, minorlogic, Вы писали:
M>>>>Какой тип логов? если ручной, то их просто может не быть в программе.
M>>Что именно актуально? какие такие ? Вы не ответили на мой вопрос, о каких логах идет речь. Я потерял нить рассуждений, помогайте.
U>Честно говоря, я не понял разделения на ручные и автоматические логи. Ручные это какие? Добавляемые на время отладки? А автоматические логи это те, которые ушли в релиз?
Ручные это те которые надо писать вручную , например:
std::cout << "Example log message" << endl;
Автоматические , это например список вызовов функций.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[8]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, minorlogic, Вы писали:
M>Ручные это те которые надо писать вручную , например: M>Автоматические , это например список вызовов функций. M>>>>Какой тип логов? если ручной, то их просто может не быть в программе.
Если имеющихся логов для отладки недостаточно, то на время отладки нужно добавить дополнительные логи. По сути логи в этом случае используются вместо брекпоинтов.
Re[9]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, minorlogic, Вы писали:
M>>Ручные это те которые надо писать вручную , например: M>>Автоматические , это например список вызовов функций. M>>>>>Какой тип логов? если ручной, то их просто может не быть в программе.
U>Если имеющихся логов для отладки недостаточно, то на время отладки нужно добавить дополнительные логи. По сути логи в этом случае используются вместо брекпоинтов.
Речь идет не об отладке а о знакомствес кодом. В коде может не быть логов в вашем понимании.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[10]: Использования дебаггера, чтобы разобраться как работ
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, minorlogic, Вы писали:
M>>Речь идет не об отладке а о знакомствес кодом. В коде может не быть логов в вашем понимании.
U>А кто их мешает добавить? Разве что undo checkout потом сделать надо, дабы изменения на сервер не ушли.
Не мешает , вопрос в трудоемкости метода, получится ли этот вариант быстрее трассировки в отладчике
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Кэр, Вы писали:
Кэр>>Утверждается здесь следующее — если после пары часов отладки решение так и не найдено (проблема оказалась сложнее чем найти где вылетает OutOfRangeException и понять какой индекс надо исправить), то нужно отойти от отладчика и проанализировать проблему без дебаггера.
IT>Процесс отладки (в любом виде: дебагер или логи) — это неотъемлемая и одна из важнейших частей процесса разработки. С этим мы не будем спорить?
Почему вам показалось, что я с этим спорю?
IT>А раз так, что сам процесс разработки должен быть заточен под процесс отладки. Чем чаще это правило выдерживается, тем реже приходится отходить от отладчика, чтобы понять что произошло.
Импликация ложная. Некоторые проблемы — многопоточность, особо сложные алгоритмы, пр. — просто сложно отлаживать. И когда применяется подход "что там думать — запускаем дебаггер и пробуем получить пошагово получить репро и понять что произошло" — то в результате времени может уйти гораздо больше.
Возвращаясь к изначальному вашему примеру про исключение — у вас было репро, у вас было желание увидеть код и данные в месте, где вылетело исключение. Это очень полезная информация для анализа — дебаггер должен быть запущен моментально. Но это не является всеобщим рецептом только из-за этого частного случая.
Одна из наиболее сложных проблем в отладке — когда нет четкого репро. Вот тут лучше сначала подумать перед тем как прыгать и запускать дебаггер.
Надо еще оговориться, если код вы знаете уже очень хорошо и много о нем уже думали, то время пред-дебажного анализа у вас в среднем получается гораздо меньше, чем в самом начале ознакомления с кодом. Но это получается естественным путем. Главный критерий запуска дебаггера остается по-прежнему — должна быть конкретная теория, что хочется увидеть в дебаггере, и как это может помочь в поиске изначальной ошибки.
IT>Конечно, бывают случаи, когда ни отладчик, ни логи не помогают. Но это чаще связано с проколами в архитектуре и здесь уже не только надо откладывать в сторону дебагер, но даже и код.
Код бывает очень разный. Поэтому рецепт — запускайте дебаггер сразу при любом случае — не очень верная рекомендация.
IT>Но вопрос как раз не в этом, а в том, что круче — дебагер или логи. По мне так они только дополняют друг друга и не должны противопоставляться.
Я полностью согласен. Эти оба инструмента не противоречат друг другу в техническом плане, могут применяться одновременно и отказываться от них можно только по "философским причинам". Я собственно и порасуждал об общей теории использования дебаггера. Но в общем контексте, а не контексте противопоставления дебаггера логам, так как это противопоставление довольно глупо. Могу также порассуждать об общей теории использования логов
Кэр>>Также здесь утверждается что в unmanaged коде, там где нет исключений лучше все же иметь теорию, что собираемся искать, до запуска дебаггера. IT>Отлаживайте вы сами ваш unmanaged код.
Я сам managed код люблю гораздо больше. Но совсем закрывать глаза на unamanged не стоит — это искусственное ограничение. После того как тот же John Robbins на семинаре показал как можно отлаживать x64 release binary код без подгруженных символов — я знаю что это возможно. При этом я примерно теперь понимаю, сколько это стоит и могу примерно оценить подобную работу. Раньше мне этого делать просто ни разу не приходилось (и я, честно говоря, надеюсь что не придется).
Но если через некоторое время у меня будет своя контора и кто-нибудь мне будет утверждать что отлаживать ассемблерный код "супер невозможно" или наоборот "работы на пару часов" — я буду понимать, что либо человек не понимает что он говорит, либо пытается вермишель развесить сушиться.
Re[6]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Кэр, Вы писали:
IT>>Процесс отладки (в любом виде: дебагер или логи) — это неотъемлемая и одна из важнейших частей процесса разработки. С этим мы не будем спорить?
Кэр>Почему вам показалось, что я с этим спорю?
Видимо потому что создаётся впечатление, что тебе очень хочется поспорить
Кэр>Импликация ложная. Некоторые проблемы — многопоточность, особо сложные алгоритмы, пр. — просто сложно отлаживать. И когда применяется подход "что там думать — запускаем дебаггер и пробуем получить пошагово получить репро и понять что произошло" — то в результате времени может уйти гораздо больше.
В 95% случаев всё просто. Это значит, что для 95% случаев это работает хорошо. Можно, конечно, порассуждать об оставшихся 5%, но только в в том случае, если мы понимаем, что мы говорим не о равнозначных величинах, а о 5-ти процентах.
Кэр>Возвращаясь к изначальному вашему примеру про исключение — у вас было репро, у вас было желание увидеть код и данные в месте, где вылетело исключение. Это очень полезная информация для анализа — дебаггер должен быть запущен моментально. Но это не является всеобщим рецептом только из-за этого частного случая.
Это как раз общий случай. Если такой случай становится частным, то нужно серьёзно думать о косяках в архитектуре.
Кэр>Одна из наиболее сложных проблем в отладке — когда нет четкого репро. Вот тут лучше сначала подумать перед тем как прыгать и запускать дебаггер.
Такие проблемы нужно устранять на уровне архитектуры, тогда и проблем не будет.
Кэр>Надо еще оговориться, если код вы знаете уже очень хорошо и много о нем уже думали, то время пред-дебажного анализа у вас в среднем получается гораздо меньше, чем в самом начале ознакомления с кодом. Но это получается естественным путем. Главный критерий запуска дебаггера остается по-прежнему — должна быть конкретная теория, что хочется увидеть в дебаггере, и как это может помочь в поиске изначальной ошибки.
Это неправильная теория. Это я как собаковод говорю, как контрактник, которому приходилось тушить много пожаров и вытаскивать безнадёжные проекты из пепла. Для того, чтобы фиксить большинство багов никаких особых теорий не нужно. И изучать в подробностях чужой код не нужно. Нужно запустить отладчик, локализовать место и посмотреть на проблему. В большинстве случаев это окажется какая-нибудь глупость, неаккуратность или незнание, потому что люди делают глупости, неаккуратны и не все всё знают.
IT>>Конечно, бывают случаи, когда ни отладчик, ни логи не помогают. Но это чаще связано с проколами в архитектуре и здесь уже не только надо откладывать в сторону дебагер, но даже и код.
Кэр>Код бывает очень разный. Поэтому рецепт — запускайте дебаггер сразу при любом случае — не очень верная рекомендация.
Код всегда разный, а вот баги, как это ни странно, в большинстве случаев одни и те же.
Кэр>Я собственно и порасуждал об общей теории использования дебаггера.
В этой теории не хватает статистики. А именно, как часто и какие баги приходится ловить. И если эту статистику рассмотреть, то окажется, что большинство людей о вещах, о которых ты говоришь понятия не имеют. Им бы свои null references отловить, а ты здесь про многозадачность и многоядерность.
Кэр>Но если через некоторое время у меня будет своя контора и кто-нибудь мне будет утверждать что отлаживать ассемблерный код "супер невозможно" или наоборот "работы на пару часов" — я буду понимать, что либо человек не понимает что он говорит, либо пытается вермишель развесить сушиться.
А ты вообще не спрашивай. Пусть покажет
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Видимо потому что создаётся впечатление, что тебе очень хочется поспорить
Мне всегда хочется поспорить, особенно когда аргументы собеседника весомые и продуманные, но из этого никак не следует, что я не считаю процесс отладки одним из важнейших иструментов разработки.
IT>В 95% случаев всё просто. Это значит, что для 95% случаев это работает хорошо. Можно, конечно, порассуждать об оставшихся 5%, но только в в том случае, если мы понимаем, что мы говорим не о равнозначных величинах, а о 5-ти процентах.
Ну, примерно так. Полную мысль сформулировать можно так — если есть теория, что большинство текущих задач решается нахрапом после запуска дебаггера — то нужно использовать дебаггер. Для полноты картины стоит привести еще одну рекомендацию от Джона: "если после пары часов в отладчике проблема так и не обнаружена — то нужно спросить себя: продвигаюсь ли я куда-либо, остались ли у меня теории которые я могу проверить с помощью отладчика? И если ответ отрицательный — то нужно отойти от отладчика и построить новую теорию". Это работает для меня. Для кого-то другого возможно подход к анализу и решению проблем другой. Меня вот отвлекает поток данных, если у меня нет теории, что я хочу из этого потока достать. Еще меня раздражает временами относительная медленность процесса — иногда идти по шагам, замораживать лишние потоки, промахиваться мимо нужной строчки и начинать с самого начала, потому что set next statement уже не сделать — иногда это слишком долго. Дольше чем продумать что может быть не так заранее.
IT>Это как раз общий случай. Если такой случай становится частным, то нужно серьёзно думать о косяках в архитектуре.
Опять же — это общий случай для менеджед кода. Мне вот недавно пришлось отлаживать плюсовый код с кучей деструктивных ассертов по поводу и без. Если идти по шагам — то это ужас-ужас с учетом, что под капотом довольно сложное распределенное хранилище данных. Гораздо быстрее было остановится, подумать что там было не так, подумать как это проверить отладчиком и где лучше остановиться для этого.
Кэр>>Одна из наиболее сложных проблем в отладке — когда нет четкого репро. Вот тут лучше сначала подумать перед тем как прыгать и запускать дебаггер. IT>Такие проблемы нужно устранять на уровне архитектуры, тогда и проблем не будет.
Я не возражаю. Просто проблемы архитектуры иногда живут вечно.
Кэр>>Но если через некоторое время у меня будет своя контора и кто-нибудь мне будет утверждать что отлаживать ассемблерный код "супер невозможно" или наоборот "работы на пару часов" — я буду понимать, что либо человек не понимает что он говорит, либо пытается вермишель развесить сушиться.
IT>А ты вообще не спрашивай. Пусть покажет
Re[8]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, Кэр, Вы писали:
Кэр>Опять же — это общий случай для менеджед кода. Мне вот недавно пришлось отлаживать плюсовый код с кучей деструктивных ассертов по поводу и без. Если идти по шагам — то это ужас-ужас с учетом, что под капотом довольно сложное распределенное хранилище данных. Гораздо быстрее было остановится, подумать что там было не так, подумать как это проверить отладчиком и где лучше остановиться для этого.
А я на прошлых выходных пытался перевести код который писался как однопоточный в режим работы в фоне в условиях когда его часть работает в UI-потоке.
Отладчик очень помг. Конечно по ходить по шагам и смотреть на гонки и т.п. не получится, но сама возможность перехватить исключение и посмотреть на колстэки двх потоков где возникают конфликты — это уже очень хорошо. Это в двойне хорошо, так как од перекомпилируется весьма медленно и вставлять логи очень не просто. И в тройне хорошо, так как приложение GUI-ёвое и воспроизвести ошибки не так то просто, так что сделав логирование можно долго-долго добиваться воспроизведения ошибки.
Думать конечно нужно и думать нужно в первую очередь, но если ошибка есть, то ее нужно выявлять и устрнять. Так что нет ничего плохого в том, чтобы поймать ошибку отладчиком, осмыслить причину ее возникновения и устранить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Не знаю кто такой John Robbins, но чувак явно не в теме.
Да и тема не "отладка своих приложений".
Дык код не свой! Код чужой и нада его править
Если кто-то разберёт чужой код только при помощи отладчика, в ряде случаев это вообще не будет принято как работа. И это даже не обсуждается, а прописывается в требованиях.
IT>Кстати, замечено, что обычно отладчик критикуют те, кто сам им ещё толком не научился пользоваться.
Например, в отладчике видно: переменной присваивается значение 0x67452301. На каком уровне нужно уметь пользоваться, что бы сказать, что делает код? (это не шутка, ответ может быть дан без отладчика за секунды).
P.S. "чувак не в теме" в своей книге в том числе и о создании отладчика пишет.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[4]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, gear nuke, Вы писали:
GN>Да и тема не "отладка своих приложений". GN>
Дык код не свой! Код чужой и нада его править
GN>Если кто-то разберёт чужой код только при помощи отладчика, в ряде случаев это вообще не будет принято как работа. И это даже не обсуждается, а прописывается в требованиях.
Это ты о чём сейчас?
IT>>Кстати, замечено, что обычно отладчик критикуют те, кто сам им ещё толком не научился пользоваться.
GN>Например, в отладчике видно: переменной присваивается значение 0x67452301. На каком уровне нужно уметь пользоваться, что бы сказать, что делает код? (это не шутка, ответ может быть дан без отладчика за секунды).
Ну и что? Как это демонстрирует ненужность отладчика?
GN>P.S. "чувак не в теме" в своей книге в том числе и о создании отладчика пишет.
Вот и пусть пишет о создании. За это ему будет большой респект. А выдавать свои предпочтения, основанные исключительно на личном опыте, за незыблемые догмы — это лишь способ продемонстрировать собственную ограниченность.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Использования дебаггера, чтобы разобраться как работает
Здравствуйте, ton4eg, Вы писали:
T>Считаете ли вы правильным использование дебагера для целей понимания работы кода, то есть расставлять брейк поинты смотреть чему равны переменные и т.д.? Или это философски неверно и следует печатать логи и смотреть уже на них?
Собственно дебагер для этого и предназначен, чтобы понять как работает код. Использование логов оправдано там где отладчик бессилен, так как для добавления точек логирования нужно время, которое нужно ценить.
Re[5]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Это ты о чём сейчас?
О теме АТ — обратной разработке.
GN>>Например, в отладчике видно: переменной присваивается значение 0x67452301. На каком уровне нужно уметь пользоваться, что бы сказать, что делает код? (это не шутка, ответ может быть дан без отладчика за секунды).
IT>Ну и что? Как это демонстрирует ненужность отладчика?
Наглядно: отладчик не даёт ответа "выше приведен фрагмент такой-то функции". А, например, Гугл — даёт Кстати, функции тоже не случайно выбраны — по результатам работы нельзя достоверно определить, как они устроены (что делают).
IT>Вот и пусть пишет о создании. За это ему будет большой респект. А выдавать свои предпочтения, основанные исключительно на личном опыте, за незыблемые догмы — это лишь способ продемонстрировать собственную ограниченность.
То есть ему нельзя, а другим можно?! обобщать самый простой частный случай (отладка своего правильно спроектированного кода).
А вообще, это было к тому, что без умения пользоваться отладчиком вряд ли возникнет желание реализовать свой.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[2]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, minorlogic, Вы писали:
M>Более эфективного способа разобраться в том "что делает" и "как делает" код я не знаю. Какие есть еще альтернативные варианты ?
Предлагаю взять любую программу отсюда и разобраться с ней с помощью дебагера.
Re[6]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, gear nuke, Вы писали:
IT>>Это ты о чём сейчас? GN>О теме АТ — обратной разработке.
Какой ещё разработке? Может ты местом ошибся?
IT>>Ну и что? Как это демонстрирует ненужность отладчика?
GN>Наглядно: отладчик не даёт ответа "выше приведен фрагмент такой-то функции". А, например, Гугл — даёт Кстати, функции тоже не случайно выбраны — по результатам работы нельзя достоверно определить, как они устроены (что делают).
Каких ещё функций? Перечитай ветку, у меня складывается впечатление, что ты хотел поговорить с кем-то другим о чём-то другом в каком-то другом месте.
GN>То есть ему нельзя, а другим можно?! обобщать самый простой частный случай (отладка своего правильно спроектированного кода).
Если потихонечьку написать своё предпочтение где-нибудь на заборе, то сколько угодно.
GN>А вообще, это было к тому, что без умения пользоваться отладчиком вряд ли возникнет желание реализовать свой.
А при чём тут умение? Давай сначала. Вот цитата:
вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага.
Далее я утверждаю, что при соответствующем дизайне приложения 95% багов ловятся отладчиком за пару минут даже не глядя в код. В своё время, работая в IBM, у меня уходило на выполнение своих обязанностей по 15 минут в день, в предрелизную неделю, в то время как другие девелоперы брали овертаймы (видимо они тоже книжки про дебаггер почитали). Отсюда я делаю утверждение, что либо Робинса переврали и он хотел сказать не то, либо, если он сказал именно это, то он не прав. Так вот, давай попробуем опять начать с этой точки. У тебя есть что сказать по этому поводу?
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, IT, Вы писали:
IT>Перечитай ветку, у меня складывается впечатление, что ты хотел поговорить с кем-то другим о чём-то другом в каком-то другом месте.
автора топика. Извините, что влез
IT>Далее я утверждаю, что при соответствующем дизайне приложения 95% багов ловятся отладчиком за пару минут даже не глядя в код.
Я с этим никогда не спорил и, надеюсь, не буду.
Попробую по другому: представь, есть симулятор Вселенной, где все идентификаторы имеют вид qhga7645, иногда неправильно считает годичный параллакс. Некто, впервые увидев проект, потыкает в отладчик и скажет, что нашел ошибку Он прав?
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[8]: Использования дебаггера, чтобы разобраться как работа
Здравствуйте, gear nuke, Вы писали:
GN>Попробую по другому: представь, есть симулятор Вселенной, где все идентификаторы имеют вид qhga7645, иногда неправильно считает годичный параллакс. Некто, впервые увидев проект, потыкает в отладчик и скажет, что нашел ошибку Он прав?
Для того, чтобы идентификатор вида qhga7645 посчитать ошибкой нужно иметь для этого какие-то основания. Если они у него есть, то он нашёл ошибку.
О случаях, о которых я говорю, прилетевшее юзеру (или в сапорт) исключение достаточно веское основание для того, чтобы считать ситуацию ошибочной.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
