Я немного систематизировал свой опыт разработки приложений, а точнее отладки. За годы работы я заметил, что правильная и эффективная отладка может существенно повысить качество приложений. Статьи, в которых я изложил свой опыт можно найти по адресу http://www.devdoc.ru/index.php/content/view/debugging_p1.htm
Помимо отладки я освятил некоторые приемы по работе с отладчиком среды MS VS .Net 2003. Думаю, это будет полезно не только начинающим, но и гуру. Всегда можно найти что-то новое в привычных вещах.
Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
ЗЫ: движок сайта в процессе разработки, так что ругайте господа, ругайте!
02.02.07 17:23: Перенесено модератором из 'C/C++' — Павел Кузнецов
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Kudinov Alexander, Вы писали:
KA>>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
A>Реферат по программизму? Честное слово, по-другому назвать не получается.
Может быть и реферат. К сожалению за 3 года проведения собеседований я выяснил, что 80% кандидатов на должность программиста С++ не знает этих азов.
Я с удовольствием улучшу содержание статей, если критика будет более конструктивная. Что бы вы хотели видеть?
Здравствуйте, Kudinov Alexander, Вы писали:
KA>Продвинутая отладка приложений
KA>Я немного систематизировал свой опыт разработки приложений, а точнее отладки. За годы работы я заметил, что правильная и эффективная отладка может существенно повысить качество приложений. Статьи, в которых я изложил свой опыт можно найти по адресу http://www.devdoc.ru/index.php/content/view/debugging_p1.htm
KA>Помимо отладки я освятил некоторые приемы по работе с отладчиком среды MS VS .Net 2003. Думаю, это будет полезно не только начинающим, но и гуру. Всегда можно найти что-то новое в привычных вещах.
KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
KA>ЗЫ: движок сайта в процессе разработки, так что ругайте господа, ругайте!
Статья на сайте посвящённая отладке, и то более познавательна... Вобщем ничего нового пока...
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Re[3]: Продвинутая отладка приложений, повышение эффективнос
Здравствуйте, Kudinov Alexander, Вы писали:
KA>Может быть и реферат. К сожалению за 3 года проведения собеседований я выяснил, что 80% кандидатов на должность программиста С++ не знает этих азов.
KA>Я с удовольствием улучшу содержание статей, если критика будет более конструктивная. Что бы вы хотели видеть?
Галопом по европам. Все свалено в одну кучу. По охватываемому тобой материалу можно элементарно книгу написать страниц так на 400. "Debugging Applications for Microsoft .NET and Microsoft Windows" — толстенная книга, но там и то меньше тем затронуто. Сосредоточься на чем нибудь одном и опиши подробно. Полезность всех четырех статей с практической точки зрения стремится к нулю.
Re: Продвинутая отладка приложений, повышение эффективности
Можете закидать меня камнями, но я не согласен с утверждениеми, что "Надо обязательно проверять все аргументы функции на корректность".
Корректность передаваемых парамеметров должен отслеживать вызывающий код. Возьмем пример, функция работающая с сортированным вектором,так чтоже теперь в теле функции проверять все элементы этотого вектора? Кроме того, такой подход делает код плохо читаемым и непереносимым.
Разработчик разрабатывает ту или иную функцию (метод) в соответствии с вариантами ее использования, соответственно и тестирование ведется
по вариантам использования. Если в методе есть баг, который никогда не всплывет, то это не баг (точно так же как new без delete не всегда означает утечку памяти). Мне кажется правильнее дисциплинированно подходить к написанию кода, а не полагаться на всякие отладочные примочки, тогда и код будет и надежнее и красивее. Если у системы грамотная архитектура, то ошибку в аргументах почти всегда можно выявить в течении нескольких минут. А кучи проверок, не дают нормально проанализировать код и выявить логические ошибки, которые гораздо опаснее. Я разрабатывал системы состоящие из сотни классов, и ни в одном методе небыло проверки аргументов и все прекрасно работало 24/7.
Все выше сказанное не относиться к библиотекам повторного использования.
Re: Продвинутая отладка приложений, повышение эффективности
Здравствуйте, Kudinov Alexander, Вы писали:
KA>Продвинутая отладка приложений
KA>Я немного систематизировал свой опыт разработки приложений, а точнее отладки. За годы работы я заметил, что правильная и эффективная отладка может существенно повысить качество приложений. Статьи, в которых я изложил свой опыт можно найти по адресу http://www.devdoc.ru/index.php/content/view/debugging_p1.htm
KA>Помимо отладки я освятил некоторые приемы по работе с отладчиком среды MS VS .Net 2003. Думаю, это будет полезно не только начинающим, но и гуру. Всегда можно найти что-то новое в привычных вещах.
KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
Мне статья понравилась. Читается легко. Я думаю будет полезна новичкам, даётся хороший обзор.
От себя хочу добавить метод, который я думаю многим известен:
метод бинарного поиска по коду
суть его в том чтобы локализовать проблемный участок кода, то есть просто отключать какие то функции программы (закомментировать их) пока не удасться обнаружить проблемный кусок, после этого иногда достаточно просто тщательно посмотреть на код для обнаружения ошибки.
Простой такой дедовский метод, но мне очень часто помогает.
Как народ относиться к подходу к разработке кода, обозначенному в subj? Разработка через тестирование всем знакома — использование unit-тестов, приемочный тестов и.т.п. Отладка для большинства — это дантов ад, бессонные ночи, workaround ы и.т.п. Возможно, причина в том, что отладка началась слишком поздно?
Основные принципы я бы сформулировал так:
1. весь код должен хотя бы раз трассироваться вручную на этапе разработки, даже если он по мнению разработчика работает верно.
2. код должен быть написан так, чтобы ручная трассировка не превращалась в бессмысленную и тупую работу и была удобным средством тестирования кода, а не только средством поиска ошибок.
3. дополнительный код, облегчающий трассировку и отладку полезен и ему нужно уделить максимальное внимание
Приведу антитезы:
1. Код должен разрабатывать так, чтобы отладка не понадобилась. Идеальный код вообще не нуждается в отладке.
2. Поскольку идеальных кодеров нет, то придуманы тесты. Грамотно разработанные тесты позволяют находить ошибки без трассировки — и это гуд, поскольку трассировка отнимает слишком много времени. И в любом случае трассировка — это тупая работа.
3. Программа на отладку которой потрачено времени больше, чем на разработку — плохая, возможно стоит остановить бессмысленную работу по ее доведению до работоспособного состояния, провести рефакторинг или даже заново разработать отдельные части проекта.
Реальная жизнь всегда требует компромисов, но на мой взгляд первый подход к отладке и трассировке как минимум имеет право на жизнь . Было бы интересно услышать доводы про и контра а также расширить и детализировать перечень тезисов.
Да пребудет с тобою сила
Re: Продвинутая отладка приложений, повышение эффективности
TarasCo wrote: > > Основные принципы я бы сформулировал так: > 1. весь код должен хотя бы раз трассироваться вручную на этапе > разработки, даже если он по мнению разработчика работает верно.
Не согласен, сильно зависит от кода и реализуемой функциональности. > 3. дополнительный код, облегчающий трассировку и отладку полезен и ему > нужно уделить максимальное внимание
Согласен. > > Приведу антитезы: > 1. Код должен разрабатывать так, чтобы отладка не понадобилась. > Идеальный код вообще не нуждается в отладке.
Теоретически, а практически идеальный код, как и идельный газ. > 2. Поскольку идеальных кодеров нет, то придуманы тесты. Грамотно > разработанные тесты позволяют находить ошибки без трассировки — и это > гуд, поскольку трассировка отнимает слишком много времени. И в любом > случае трассировка — это тупая работа.
Если UT не прошел, то чтобы исправить ошибку, часто без трассировки не
обойтись. > > Реальная жизнь всегда требует компромисов, но на мой взгляд первый > подход к отладке и трассировке как минимум имеет право на жизнь .
В реальной жизни бывает так, что без отладчика я не всегда могу написать
работающий код — голова то не резиновая. > Было > бы интересно услышать доводы про и контра а также расширить и > детализировать перечень тезисов.
Так что думаю, в зависимости от кучи причин нужно выбирать подход
совмещающий в себе и то и другое. Любые крайности сильно опасны и вредны.
Posted via RSDN NNTP Server 2.0
Re: Продвинутая отладка приложений, повышение эффективности
Здравствуйте, Kudinov Alexander, Вы писали: KA>Продвинутая отладка приложений
Смесь банальностей и, скажем мягко, вещей вводящих в заблуждение.
Умение ставить точки остановки -- продвинутая?
Ассерты (к слову, ASSERT и TRACE -- MFC-specific) тоже rocket science прямо из лабораторий Пентагона?
KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
Прежде всего -- поправить русский язык: s/будите/будете/, разобраться с употреблением "-тся" и "-ться". Это самое бросающееся в глаза.
Про s/</</g уже тоже написали.
Ну и, непонятно зачем это вообще было написано. По степени раскрытия темы -- очень слабо, по каждому из затронутых вопросов можно было написать вдесятеро больше. По широте охвата тоже фигово: где compile-time assert'ы, где обзор способов прострелить себе ногу, где многопоточность, наконец? Упоминается стиль, но не упоминается о том, что его вообще можно (и нужно) стандартизировать, не говоря уж о ссылках на самые известные вещи типа "Industrial Strength C++". Кстати, о ссылках. Где они? Все это квинтессенция десятилетнего опыта, взятая прямо из головы? Не верю ! (c) Станиславский.
Re[2]: Продвинутая отладка приложений, повышение эффективнос
K>Простой такой дедовский метод, но мне очень часто помогает.
Отличный способ. Тусил вот тут на одном форуме, там буржуи, пользователи некоторого фрэймворка плачутся, что у них что-то падает, что-то не получается и т.п. У них интерпретатор С++, очень скверный — пропускает море ошибок и поощряет кривой способ программирования на С++ — сплошные new, указатели, все течет, грохается и т.п.
Вот у человека скрипт, его длина где-то пара сотен строк — это просто одна функиця . Я рекомендовал славный способ, описанный тобой, раз уж он просмотрев текст не видит свою ошибку (скрипт человек не показывает, секрет . Разработчики оплевали меня и посоветовали бедолаге ... юзать ВАЛГРИНД. Хорошо, он их не послушал, сам быстро нашел тривиальную "опечатку" (с поганым их интерпретером много какой байды проходит). А то бы потратил немало времени на чтение мануалов валгринда и чтение сообщений валгринда — а он много чего неприятного находит в самой библиотеке.
Of course, the code must be complete enough to compile and link.
Re[3]: Продвинутая отладка приложений, повышение эффективнос
Здравствуйте, Lorenzo_LAMAS, Вы писали:
K>>Простой такой дедовский метод, но мне очень часто помогает.
L_L> L_L>Отличный способ.
Ну так, фирма веников не вяжет
> Тусил вот тут на одном форуме[...]
У меня таких историй тоже много, помню текла память у меня, ну сидел с BoundsChecker'ом, маялся, чего то ничего не получалось, потом плюнул на это всё, начал просто комментировать куски кода пока не пропали утечки, потом начал раскомментировать пока не появились снова.В общем в течении часа нашёл источник утечек. В общем чо тут говорить — бинарный поиск — классика.
Re[4]: Продвинутая отладка приложений, повышение эффективнос
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте, Lorenzo_LAMAS, Вы писали:
K>>>Простой такой дедовский метод, но мне очень часто помогает.
L_L>> L_L>>Отличный способ.
K>Ну так, фирма веников не вяжет
>> Тусил вот тут на одном форуме[...]
K>У меня таких историй тоже много, помню текла память у меня, ну сидел с BoundsChecker'ом, маялся, чего то ничего не получалось, потом плюнул на это всё, начал просто комментировать куски кода пока не пропали утечки, потом начал раскомментировать пока не появились снова.В общем в течении часа нашёл источник утечек. В общем чо тут говорить — бинарный поиск — классика.
Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" . Только это прокатывает в небольших проетах (аля нотэпада). А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться. Один раз понять как и больше не будет желания комментировать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Продвинутая отладка приложений, повышение эффективнос
Здравствуйте, Splin, Вы писали:
S>Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" .
Нет, метод "тыка" это метод Монте-Карло, а я говорю о бинарном поиске
> Только это прокатывает в небольших проетах (аля нотэпада). А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться. Один раз понять как и больше не будет желания комментировать.
Я умею пользоваться и BoundsChecker и DevPartner. И ещё я согласен с такой фразой "Никогда не говори никогда" В общем по ситуации надо смотреть.
Re[3]: Продвинутая отладка приложений, повышение эффективнос
Здравствуйте, Kudinov Alexander, Вы писали:
KA>Может быть и реферат. К сожалению за 3 года проведения собеседований я выяснил, что 80% кандидатов на должность программиста С++ не знает этих азов.
80% кандидатов не знают этой примиты? Эк вас угораздило. Где же такое нашествие чайников?
Re[5]: Продвинутая отладка приложений, повышение эффективнос
. Есть другое название этому методу — "метод тыка" 
