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

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

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

Видимо потому что создаётся впечатление, что тебе очень хочется поспорить

Кэр>Импликация ложная. Некоторые проблемы — многопоточность, особо сложные алгоритмы, пр. — просто сложно отлаживать. И когда применяется подход "что там думать — запускаем дебаггер и пробуем получить пошагово получить репро и понять что произошло" — то в результате времени может уйти гораздо больше.

В 95% случаев всё просто. Это значит, что для 95% случаев это работает хорошо. Можно, конечно, порассуждать об оставшихся 5%, но только в в том случае, если мы понимаем, что мы говорим не о равнозначных величинах, а о 5-ти процентах.

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

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

Кэр>Одна из наиболее сложных проблем в отладке — когда нет четкого репро. Вот тут лучше сначала подумать перед тем как прыгать и запускать дебаггер.

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

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

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

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

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

Код всегда разный, а вот баги, как это ни странно, в большинстве случаев одни и те же.

Кэр>Я собственно и порасуждал об общей теории использования дебаггера.

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

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

А ты вообще не спрашивай. Пусть покажет

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

IT>Видимо потому что создаётся впечатление, что тебе очень хочется поспорить

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

IT>В 95% случаев всё просто. Это значит, что для 95% случаев это работает хорошо. Можно, конечно, порассуждать об оставшихся 5%, но только в в том случае, если мы понимаем, что мы говорим не о равнозначных величинах, а о 5-ти процентах.

Ну, примерно так. Полную мысль сформулировать можно так — если есть теория, что большинство текущих задач решается нахрапом после запуска дебаггера — то нужно использовать дебаггер. Для полноты картины стоит привести еще одну рекомендацию от Джона: "если после пары часов в отладчике проблема так и не обнаружена — то нужно спросить себя: продвигаюсь ли я куда-либо, остались ли у меня теории которые я могу проверить с помощью отладчика? И если ответ отрицательный — то нужно отойти от отладчика и построить новую теорию". Это работает для меня. Для кого-то другого возможно подход к анализу и решению проблем другой. Меня вот отвлекает поток данных, если у меня нет теории, что я хочу из этого потока достать. Еще меня раздражает временами относительная медленность процесса — иногда идти по шагам, замораживать лишние потоки, промахиваться мимо нужной строчки и начинать с самого начала, потому что set next statement уже не сделать — иногда это слишком долго. Дольше чем продумать что может быть не так заранее.

IT>Это как раз общий случай. Если такой случай становится частным, то нужно серьёзно думать о косяках в архитектуре.

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

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

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

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

IT>А ты вообще не спрашивай. Пусть покажет

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

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

А я на прошлых выходных пытался перевести код который писался как однопоточный в режим работы в фоне в условиях когда его часть работает в UI-потоке.

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

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

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

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

Да и тема не "отладка своих приложений".

Дык код не свой! Код чужой и нада его править

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

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

Например, в отладчике видно: переменной присваивается значение 0x67452301. На каком уровне нужно уметь пользоваться, что бы сказать, что делает код? (это не шутка, ответ может быть дан без отладчика за секунды).

P.S. "чувак не в теме" в своей книге в том числе и о создании отладчика пишет.

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

GN>Да и тема не "отладка своих приложений".
GN>

Дык код не свой! Код чужой и нада его править

GN>Если кто-то разберёт чужой код только при помощи отладчика, в ряде случаев это вообще не будет принято как работа. И это даже не обсуждается, а прописывается в требованиях.

Это ты о чём сейчас?

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

GN>Например, в отладчике видно: переменной присваивается значение 0x67452301. На каком уровне нужно уметь пользоваться, что бы сказать, что делает код? (это не шутка, ответ может быть дан без отладчика за секунды).

Ну и что? Как это демонстрирует ненужность отладчика?

GN>P.S. "чувак не в теме" в своей книге в том числе и о создании отладчика пишет.

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

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

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

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

IT>Это ты о чём сейчас?

О теме АТ — обратной разработке.

GN>>Например, в отладчике видно: переменной присваивается значение 0x67452301. На каком уровне нужно уметь пользоваться, что бы сказать, что делает код? (это не шутка, ответ может быть дан без отладчика за секунды).

IT>Ну и что? Как это демонстрирует ненужность отладчика?

Наглядно: отладчик не даёт ответа "выше приведен фрагмент такой-то функции". А, например, Гугл — даёт Кстати, функции тоже не случайно выбраны — по результатам работы нельзя достоверно определить, как они устроены (что делают).

IT>Вот и пусть пишет о создании. За это ему будет большой респект. А выдавать свои предпочтения, основанные исключительно на личном опыте, за незыблемые догмы — это лишь способ продемонстрировать собственную ограниченность.

То есть ему нельзя, а другим можно?! обобщать самый простой частный случай (отладка своего правильно спроектированного кода).

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

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

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

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

IT>>Это ты о чём сейчас?
GN>О теме АТ — обратной разработке.

Какой ещё разработке? Может ты местом ошибся?

IT>>Ну и что? Как это демонстрирует ненужность отладчика?

GN>Наглядно: отладчик не даёт ответа "выше приведен фрагмент такой-то функции". А, например, Гугл — даёт Кстати, функции тоже не случайно выбраны — по результатам работы нельзя достоверно определить, как они устроены (что делают).

Каких ещё функций? Перечитай ветку, у меня складывается впечатление, что ты хотел поговорить с кем-то другим о чём-то другом в каком-то другом месте.

GN>То есть ему нельзя, а другим можно?! обобщать самый простой частный случай (отладка своего правильно спроектированного кода).

Если потихонечьку написать своё предпочтение где-нибудь на заборе, то сколько угодно.

GN>А вообще, это было к тому, что без умения пользоваться отладчиком вряд ли возникнет желание реализовать свой.

А при чём тут умение? Давай сначала. Вот цитата:

вот что говорит John Robbins про использование дебаггера: используйте его как крайнее, последнее средство в процессе отладки бага.

Далее я утверждаю, что при соответствующем дизайне приложения 95% багов ловятся отладчиком за пару минут даже не глядя в код. В своё время, работая в IBM, у меня уходило на выполнение своих обязанностей по 15 минут в день, в предрелизную неделю, в то время как другие девелоперы брали овертаймы (видимо они тоже книжки про дебаггер почитали). Отсюда я делаю утверждение, что либо Робинса переврали и он хотел сказать не то, либо, если он сказал именно это, то он не прав. Так вот, давай попробуем опять начать с этой точки. У тебя есть что сказать по этому поводу?

Предлагаю взять любую программу оттуда и разобраться в ней без помощи дебаггера

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

IT>Перечитай ветку, у меня складывается впечатление, что ты хотел поговорить с кем-то другим о чём-то другом в каком-то другом месте.

Верно, я хотел обсудить проблему

Автор: ton4eg
Дата: 18.06.09

автора топика. Извините, что влез

IT>Далее я утверждаю, что при соответствующем дизайне приложения 95% багов ловятся отладчиком за пару минут даже не глядя в код.

Я с этим никогда не спорил и, надеюсь, не буду.

Попробую по другому: представь, есть симулятор Вселенной, где все идентификаторы имеют вид qhga7645, иногда неправильно считает годичный параллакс. Некто, впервые увидев проект, потыкает в отладчик и скажет, что нашел ошибку Он прав?

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

GN>Попробую по другому: представь, есть симулятор Вселенной, где все идентификаторы имеют вид qhga7645, иногда неправильно считает годичный параллакс. Некто, впервые увидев проект, потыкает в отладчик и скажет, что нашел ошибку Он прав?

Для того, чтобы идентификатор вида qhga7645 посчитать ошибкой нужно иметь для этого какие-то основания. Если они у него есть, то он нашёл ошибку.

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