Стал замечать за собой такую особенность -- отладчиком пользуюсь всё реже и реже. Специально никакой "философии" вокруг этого не выстраивал, всё как-то само собой получилось.
Сейчас пишу в основном на C++, Python и JS, и вместо debugger'а прибегаю к отладочной печати в Release-сборке (ну, это если мы про C++, например, говорим).
Сейчас, когда задумался, вроде бы и плюсы нашёл:
Банально меньше проверять. Так мы должны протестировать Debug-сборку, а потом ещё и Release.
Нет необходимости привыкать к особенностям работы какого-то отладчика. Вывод в лог / stdout универсален, т.к. реализуется обычно средствами языка или его стандартной библиотеки.
Легче "отлаживать" многопоточные приложения. Во-первых, меньше вероятность изменить поведение программы из-за уменьшения "производительности" приложения в Debug-сборке (да, логгирование тоже может повлиять, но, как показывает практика, гораздо меньше, чем запущенный отладчик или бряки). Во-вторых, в логах явно будет прослеживаться параллельная работа потоков, легче отследить взаимосвязь и меньше контекста придётся запоминать самостоятельно.
???
Есть, конечно, у такого подхода и минусы. Если сходу, то на ум приходит:
Если надо часто узнавать контекст приложения в какие-то моменты времени (значения переменных, элементов коллекций и т.д.), то окно "Variables" в отладчике гораздо удобнее и быстрее реализуется. Да, если перегружать операторы вывода / преобразования к строке для каждого имеющегося объекта, то ещё ничего, но я так обычно не делаю.
Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время. Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым".
На Debug-сборке могут проявиться какие-то баги, которые бы, возможно, не всплыли в случае Release.
???
Здравствуйте, b0r3d0m, Вы писали:
B>Стал замечать за собой такую особенность -- отладчиком пользуюсь всё реже и реже. Специально никакой "философии" вокруг этого не выстраивал, всё как-то само собой получилось.
B>Сейчас пишу в основном на C++, Python и JS, и вместо debugger'а прибегаю к отладочной печати в Release-сборке (ну, это если мы про C++, например, говорим).
... B>А вы что думаете?
Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи.
_>Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи.
Так вот и объясните мне, какие задачи вы видите для этого лома. Я уже описал очевидные для меня плюсы и минусы.
Здравствуйте, b0r3d0m, Вы писали:
_>>Если вы редко пользуетесь ломом, то это не значит что он не нужен. Просто у него другие задачи. B>Так вот и объясните мне, какие задачи вы видите для этого лома. Я уже описал очевидные для меня плюсы и минусы.
Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных...
Освоение незнакомых библиотек и фреймворков анализом на ходу (расстановка точек останова и изучение, какие сработают, просмотр значений переменных внутри чужих функций...)
Принципиальное изменение логики без исходников (обычно используются специализированные отладчики).
N>Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных...
Ничоси "помощь". Надо дополнительно запоминать команды отладчика, научиться не прыгать в реализацию библиотечных функций (например, в VS для этого надо проделать несколько махинаций с конфигами) и т.д.
N>Освоение незнакомых библиотек и фреймворков анализом на ходу (расстановка точек останова и изучение, какие сработают, просмотр значений переменных внутри чужих функций...)
Если они header-only, то да. А как Вы отладите какие-нибудь lib / dll-файлы по-нормальному?
N>Принципиальное изменение логики без исходников (обычно используются специализированные отладчики).
Попахивает, нет? Впрочем, это субъективное мнение.
P>Если тебе не нужны — не пользуй
Спасибо, что разрешили!
P>а мы всё же будем пользоваться достижениями прогресса.
Так я тоже ими пользуюсь, просто со временем всё реже и реже.
Здравствуйте, b0r3d0m, Вы писали:
B>А вы что думаете?
Да вобщем нечто кэповское — отладчики нужны тогда, которая для упрощения поиска багов требуется мониторить большое количество переменных одновременно — в отладчике это удобнее, чем печать. У меня еще отладчик строит графики нужных мне результатов вычислений по ходу, что тоже здорово жизнь упрощает.
Здравствуйте, b0r3d0m, Вы писали:
B>Так я тоже ими пользуюсь, просто со временем всё реже и реже.
Опыт видимо, у меня тоже так — если скомпилилось — то 99,999999% код без багов. Но сказать, что они не нужны — это нонсенс. В случае чего я лучше пройдусь отладчиком и за пару минут пофикшу баг (со всеми удобствами, когда видно всё-всё execution окружение/состояние), чем буду ковыряться в логах.
А то, что можно и без отладчика жить — то можно, но зачем? (также можно и без IDE, профайлеров и т.д.)
Здравствуйте, b0r3d0m, Вы писали:
N>>Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных... B>Ничоси "помощь". Надо дополнительно запоминать команды отладчика
Их крайне мало. Step over, step in, continue, toggle breakpoint.
Иногда ещё и step out. Но все в меню есть, основная идея понимается за минуту, запомнить клавиатурные сокращения — максимум на 20-м вызове каждой команды.
B> научиться не прыгать в реализацию библиотечных функций (например, в VS для этого надо проделать несколько махинаций с конфигами)
Махинации? С конфигами?? О каком случае речь??? Step over спасает от захода в любую функцию, неважно, свою или чужую, если в ней не сработал останов.
B> и т.д.
Никакого "и т.д.", всё банальности.
N>>Освоение незнакомых библиотек и фреймворков анализом на ходу (расстановка точек останова и изучение, какие сработают, просмотр значений переменных внутри чужих функций...) B>Если они header-only, то да. А как Вы отладите какие-нибудь lib / dll-файлы по-нормальному?
Случай, когда есть исходники, или хотя бы IL. Это не так редко, как кажется со стороны. Хедера тут ни при чём (какие хедера, например, в Python, Java, Javascript, C#?)
N>>Принципиальное изменение логики без исходников (обычно используются специализированные отладчики). B>Попахивает, нет? Впрочем, это субъективное мнение.
ZEN>Это вы ещё автоматизированное тестирование не изучили!
Selenium юзаю, например. Но протестировать можно далеко не всё, и это немного другая стихия.
B>А вы что думаете?
В систему BlackBox Component Builder отладчик не включен сознательно. Пользуются assert'ами.
Вирт с возрастом тоже пришел к выводу, что отладчик в большинстве своем чисто психологически вреден:
провоцирует не продумывать прогу, а лепить в режиме потока сознания — все равно потом отладим.
Есть задачи, в которых отладчик бесполезен.
Например, матрица заполняется методом монте-карло.
На маленьких матрицах типа 10 на 10 еще можно посмотреть процесс.
А на реальных матрицах размера 10000 на 10000 — нереально.
Приходится продумывать отладочную инфраструктуру и писать отладочные функции...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
N>>>Помощь в обучении: визуализация прохождения исполнителя по коду, изменений переменных... B>>Ничоси "помощь". Надо дополнительно запоминать команды отладчика
N>Их крайне мало. Step over, step in, continue, toggle breakpoint. N>Иногда ещё и step out. Но все в меню есть, основная идея понимается за минуту, запомнить клавиатурные сокращения — максимум на 20-м вызове каждой команды.
Особенно круто, когда переключаешься между разными средами, каждая из которых обладает своими хоткеями на обозначенные операции. Переназначить можно не везде, да и время тратит, плюс привыкаешь. Помню, как прыгал между отладчиками в VS и OllyDbg.
B>> научиться не прыгать в реализацию библиотечных функций (например, в VS для этого надо проделать несколько махинаций с конфигами)
N>Махинации? С конфигами?? О каком случае речь??? Step over спасает от захода в любую функцию, неважно, свою или чужую, если в ней не сработал останов.
A>Да вобщем нечто кэповское — отладчики нужны тогда, которая для упрощения поиска багов требуется мониторить большое количество переменных одновременно — в отладчике это удобнее, чем печать
Отладчики, кстати, зачастую ещё готовить надо перед таким употреблением. Вспомнить хотя бы отображение C++ коллекций в gdb. Да, один раз сделал и забыл, не спорю, но всё же.
A>У меня еще отладчик строит графики нужных мне результатов вычислений по ходу, что тоже здорово жизнь упрощает.
Что-то не понял. Пример можно?
Здравствуйте, LaptevVV, Вы писали:
LVV>В систему BlackBox Component Builder отладчик не включен сознательно. Пользуются assert'ами.
Экий артефакт... LVV>Вирт с возрастом тоже пришел к выводу, что отладчик в большинстве своем чисто психологически вреден: LVV>провоцирует не продумывать прогу, а лепить в режиме потока сознания — все равно потом отладим.
И где сейчас этот ваш оберон, стал мейнстримом уже? Или так и остался игрушкой фанатиков, никому кроме них не нужной?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, b0r3d0m, Вы писали:
B>А вы что думаете?
Для шарпа всё просто, т.к. там инструментарий здорового человека. Подрубился к уже запущенному процессу / запустил под отладчиком, поставил точки останова, нашёл-поправил налету ошибку, отрубился. Done.
В 90% случаев даж точек останова не требуется, расставленные ассерты сами прерывают выполнение в нужном месте.
Если этого нет — каменный век, да.
Ну и понятно, что собственно обнаружение / воспроизведение ошибок лучше делать тестами, для отладки оставлять только диагностику и исправление (если ошибка тривиальная м легко чинится).
Здравствуйте, b0r3d0m, Вы писали:
A>>У меня еще отладчик строит графики нужных мне результатов вычислений по ходу, что тоже здорово жизнь упрощает. B>Что-то не понял. Пример можно?
Здравствуйте, b0r3d0m, Вы писали:
B> Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время. Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым".
Отладочную печать убирать убирать как раз не надо. Ее надо делать опцией, которую всегда можно включить, если надо какие-то баги поймать в релизе.
B>> Отладочную печать надо убирать из кода после проведения тестов. Следовательно, тратим лишнее время. Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым".
M>Отладочную печать убирать убирать как раз не надо. Ее надо делать опцией, которую всегда можно включить, если надо какие-то баги поймать в релизе.
Ну, я же как раз написал:
>Ну, или оставлять в коде, но отключать каким-то препроцессингом (например, макросами в случае C++), но тогда код может получиться неслабо так "засорённым"
