dev.net.ua

Возникла такая тема в непрофильном форуме - решили перенести сюда, может будет кому-то интересна.

 

Mike Chaliy писал(а):

Pavlo писал(а): А как должен выглядеть цивилизованный дебаг? Уметь изменять перменные, сохранять/востанавливать состояние обьектов, уменять дебажить тока куски, уметь визуализировать комплексные обьекты, предоставлять возможность делать не "умные" бряки, менеджить бряки не тока точками, ...

ИМХО, при граммотно спроектированной до написания кода поддержки отладки, интегрированной в сам код (логирование, ассерты, трассировки, коды возврата, исключения) плюс сегментация проекта для помодульной отладки усе эти фичи дебагерров не нужны в 99% случаев, достаточно консоли. Хотя в некоторых случаях, конечно, могут ускорить поиск проблемы. Однако ориентироваться на дебаггер, как на необходимую часть среды разработки, я б не стал, буть он хоть трижды суперским. Сам код может сам себя отлаживать:)

 

mosh писал(а):

ИМХО, при граммотно спроектированной до написания кода поддержки отладки, интегрированной в сам код (логирование, ассерты, трассировки, коды возврата, исключения) плюс сегментация проекта для помодульной отладки усе эти фичи дебагерров не нужны в 99% случаев, достаточно консоли. Хотя в некоторых случаях, конечно, могут ускорить поиск проблемы. Однако ориентироваться на дебаггер, как на необходимую часть среды разработки, я б не стал, буть он хоть трижды суперским. Сам код может сам себя отлаживать:)

Представляю себе ваши методы. Наверное полсотни ассертов на входе, еще пол сотни на выходе. Трейс через каждую строчку. Кейсы на пол класса для обработки кодов возврата. Вобщемто 90% кода для потдержки 10%.

Вобщемто ИМХО это не правильно.

Есть ТДД которое позволяет убедиться в работоспособности кода с внешней стороны. И не имеет смысла засорять код ассертами внутри. А дебаг тайм ассерты так это вообще дырка в безопасности...

Так чтобы трейсы выдали то что стало причиной ошибки, надо быть ну просто супер везунчиком. Обычно же если не забываеш вывести в трейс то и не забываеш не сделать ошибки ).

Коды возврата вообще устрашающая фишка. Я когда ревьювлю код, методы которые могут нулл возаращать отношу к потенцеально небезопасным. И только потому что они могут возаращать два пути, либо нул либо информацию. А тут коды возарата, количестов путей = количество кодов возарата + безконечное количество неизвесных путей возврата.

Mike Chaliy писал(а):

Представляю себе ваши методы. Наверное полсотни ассертов на входе, еще пол сотни на выходе. Трейс через каждую строчку. Кейсы на пол класса для обработки кодов возврата. Вобщемто 90% кода для потдержки 10%.

Ну де Вы видели методы с 25 параметрами на входе и таким же числов выходных данных. Обычно 2-4 на входе, выход проверяется в вызывающем контексте. Ну а процентовка такая, как Вы написали, только наоборот, ну инода 20-80. Я уточнил сразу - грамотно написанный отладочный фреймвёрк.

Mike Chaliy писал(а):

Есть ТДД которое позволяет убедиться в работоспособности кода с внешней стороны. И не имеет смысла засорять код ассертами внутри. А дебаг тайм ассерты так это вообще дырка в безопасности...

Ну да ТестСуит (ТДД это оно, как я понял) верифицирует код по признаку работает-не работает с точки зрения требований или там структурного покрытия. Однако, без отладочного фреймвёка найти ошибку в неработающем модуле можно только неформализованно лазя дебагером по коду. Согласен, если проект один в данной технологии, то можент мучаться и не стоит, но в случае серии, скорость отладки увеличивается многократно.

Mike Chaliy писал(а):

Так чтобы трейсы выдали то что стало причиной ошибки, надо быть ну просто супер везунчиком. Обычно же если не забываеш вывести в трейс то и не забываеш не сделать ошибки ).

Никакого везения - нормальный трейс на выдаёт стек вызовов и строку кода, где произошла ошибка.

Mike Chaliy писал(а):

Коды возврата вообще устрашающая фишка. Я когда ревьювлю код, методы которые могут нулл возаращать отношу к потенцеально небезопасным. И только потому что они могут возаращать два пути, либо нул либо информацию. А тут коды возарата, количестов путей = количество кодов возарата + безконечное количество неизвесных путей возврата.

Код возврата несёт не только триггерную функцию, но и информативную составляющую для релиз версии, где нет не трассироввок , не ассертов и невозможно логгирование. По совокупности состояние объектов (GetLastError) после завершения каждого шага выполнения при обходе их иерархии модулем встроенного тестирования мона локализовать ошибку с точностью до строки кода, минимум до метода, как и в случае с трассировкой. Что весьма полезно для анализа крэшей уже в работающей реальной системе.

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

ЗЫ в целом можно куда-нибудь перепозти с этой интересной темой в более подходящее место

 

mosh писал(а):

Mike Chaliy писал(а): Представляю себе ваши методы. Наверное полсотни ассертов на входе, еще пол сотни на выходе. Трейс через каждую строчку. Кейсы на пол класса для обработки кодов возврата. Вобщемто 90% кода для потдержки 10%. Ну де Вы видели методы с 25 параметрами на входе и таким же числов выходных данных. Обычно 2-4 на входе, выход проверяется в вызывающем контексте. Ну а процентовка такая, как Вы написали, только наоборот, ну инода 20-80. Я уточнил сразу - грамотно написанный отладочный фреймвёрк.

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

mosh писал(а):

Mike Chaliy писал(а): Есть ТДД которое позволяет убедиться в работоспособности кода с внешней стороны. И не имеет смысла засорять код ассертами внутри. А дебаг тайм ассерты так это вообще дырка в безопасности... Ну да ТестСуит (ТДД это оно, как я понял) верифицирует код по признаку работает-не работает с точки зрения требований или там структурного покрытия. Однако, без отладочного фреймвёка найти ошибку в неработающем модуле можно только неформализованно лазя дебагером по коду. Согласен, если проект один в данной технологии, то можент мучаться и не стоит, но в случае серии, скорость отладки увеличивается многократно.

ТДД - Тест Драйвен Девелопмент - бузверд - Юнит Тесты. Упрощенно это специальные классы которые вызвают ваш код. Есть специальные фреимворки для упрощения тестирования. Кроме того что проверяют что метод работает правильно с правильными данными, так же проверяют и работу с неправильными данными.

mosh писал(а):

Mike Chaliy писал(а): Так чтобы трейсы выдали то что стало причиной ошибки, надо быть ну просто супер везунчиком. Обычно же если не забываеш вывести в трейс то и не забываеш не сделать ошибки ). Никакого везения - нормальный трейс на выдаёт стек вызовов и строку кода, где произошла ошибка.

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

mosh писал(а):

Mike Chaliy писал(а): Коды возврата вообще устрашающая фишка. Я когда ревьювлю код, методы которые могут нулл возаращать отношу к потенцеально небезопасным. И только потому что они могут возаращать два пути, либо нул либо информацию. А тут коды возарата, количестов путей = количество кодов возарата + безконечное количество неизвесных путей возврата. Код возврата несёт не только триггерную функцию, но и информативную составляющую для релиз версии, где нет не трассироввок , не ассертов и невозможно логгирование. По совокупности состояние объектов (GetLastError) после завершения каждого шага выполнения при обходе их иерархии модулем встроенного тестирования мона локализовать ошибку с точностью до строки кода, минимум до метода, как и в случае с трассировкой. Что весьма полезно для анализа крэшей уже в работающей реальной системе.

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

mosh писал(а):

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

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

mosh писал(а):

ЗЫ в целом можно куда-нибудь перепозти с этой интересной темой в более подходящее место

Если вас устраивает что я буду разговаривть исключительно на украинском можете запостить тему на http://dev.net.ua/.

 

Mike Chaliy писал(а):

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

Ну я не знаю про инварианты, но указатели проверяются на ненулёвость, значения на диапазон или равенство, а перечисляемые типы на множество. Последний случай конечно несколько тяжеловат, но по практике полчается от 1 до максимум 8 ассертов.

Mike Chaliy писал(а):

ТДД - Тест Драйвен Девелопмент - бузверд - Юнит Тесты. Упрощенно это специальные классы которые вызвают ваш код. Есть специальные фреимворки для упрощения тестирования. Кроме того что проверяют что метод работает правильно с правильными данными, так же проверяют и работу с неправильными данными.

Правильно, это фреймвёк для тестирования типа cpp-unit или там java-unit. Мы ж говорим про фрейвёки для отладки. С помощью тестового фрейвёка Вы определяет факт того, что модуль не работает, а с помощью отладочного локализуете место, которое не работает.

mosh писал(а):

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

Мы ж говорим про фреймвёрк, который позволяет не использовать дебаггеры. Мануал трейсом легко делается СтэкТрейс, досточно писать в префиксе сообщения класс::метод:)

Mike Chaliy писал(а):

Коды возврата вообще устрашающая фишка. Я когда ревьювлю код, методы которые могут нулл возаращать отношу к потенцеально небезопасным. И только потому что они могут возаращать два пути, либо нул либо информацию. А тут коды возарата, количестов путей = количество кодов возарата + безконечное количество неизвесных путей возврата.

Mike Chaliy писал(а):

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

Если говорить о c++, то всё зависит от реализации языка (стандарт стандартом, но реализации бывают разные). Но в целом коды возврата и исключительные ситуации весьма схожи по функции локализации, хотя исключения берут на себя обратную раскрутку стека, что действительно снижает вероятность ошибки при этой процедуре. Это большой плюс исключений. Но правильно спроектированная система исключений или кодов должна точно указать место возникновения ошибки - в этом они близнецы братья.

Mike Chaliy писал(а):

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

Mike Chaliy писал(а):

Это и есть ТДД.

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

Mike Chaliy писал(а):

Если вас устраивает что я буду разговаривть исключительно на украинском можете запостить тему на http://dev.net.ua/.

Только я буду часто переспрашивать:)

Имхо, все ушли в обсуждение возможностей и рациональности собственного отладочного фреймворка, так и позабыв, что сравнивать его надо с дебагером. А у дебагера помимо проверки диапазонов (хотя её в том виде как надо при проверке инвариантов и нет) есть много других особенностей.
Я, к примеру, очень часто пользуюсь возможностью в отладчике VS2005 останавливаться не только на необработанных исключениях, а на всех, ну или всех определенного типа. Очень полезно это, если где-то затерялся пустой catch.
Далее измееие переменных на ходу тоже не просто так реализовывали - кому-то надо.
Очень удобно то, что остановив программу можно не только просмотреть значения 2-3 параметров, но и если есть объекты - просмотреть детально их члены и элементы массивов. Думаю выводить это все в консоль крайне неудобно.
Еще есть примеры с отладкой многопоточных приложений и прочее.
Так что давайте шире срванивать. Проверка на инварианты, это действительно простая вещь и реализовывать её можно и юниттестами и Spec# и прочими утилитами. Асерты тут хуже смотряться. У примеру тест утилиты могут выдавать отчеты по покрытиям, а с ассертами нужно самим все просматривать ....

имхо ;)

---

Лучше побыть дураком 5 минут, чем остаться им на всю жизнь ...

ушли в обсуждение возможностей и рациональности собственного отладочного фреймворка

Не совсем так, ниже последний ответ в непрофильном форуме 

mosh писал(а):

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

В этом то и фишка, что код незасоряеться отладочным. Реально это необходимо уже в более мение заметном проекте... Код должен заниматься только выполнением. Желательно чтобы они вообще больше ничем не занимался. Но так как в реальных системах это не возможно то желательно стараться хотябы минимизировать.

Так вот связка ТДД и дебаггера плозволяет полностью убрать дебаг тайм ассерт код.
Автоматические прокси позволяют убрать инструметейшен.
А домаин специфик фрамеворки позволяют убрать код .

__________________Конец цитаты

 

Речь идёт про интеграцию в код систем его самоконтроля на этапе выполнения. Основное противоречие в том, что Mike отвергает такой подход, предлагая вместо него связку внешнего тестового фреймвёка и дебаггера. Насчёт тестового фреймвёка вопросов нет, бо он нужен для формализации написания тестового покрытия, автоматической генерации отчётов по тестированию и т.д. Что используется в любом случае.

Насчёт дебаггера ситуация другая. Как и всякая операция в технологической цепочке разработки ПО процесс отладки должен быть формализован. В случае с использованием фреймвёка это вполне естественным образом получается так же как получается формализация процесса тестирования при использовании тестового фреймвёка. В случае с использованием только дебаггера я не совсем понимаю как это сделать. Писать большую цидулю как должен действовать программер в случае поиска бага дебаггером? Ведь понятно, что модуль написанный одним программером может впоследствии быть передан другому для добавления функциональности и желательно, чтоб второй мог отладить его также эффективно, как и автор. В этом контексте отладочные фреймвёки позволяют формализовать и описать стратегию отладки неразрывно с кодом и добиться независимости отладки от личности  программатра (ну плюс-минус разумеется).

Дебаггер несомненно штука полезная, так как имеет встроенные механизмы визуализации. Однако, например временной развёртки состояния объекта у их нет (или я чего то не знаю:)). То есть в моём понимании дебаггер можно эффективно исопользовать когда точка бага локализована и нужно просмотреть информационное окружение данной точки. Ну и на этапе изучения технологии он просто незаменим. Но строить ВЕСЬ процесс отладки на нём - это, на мой взгляд, решение неэффективное в силу отсутствия стратегии этой отладки.

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

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

Ну и некоторые технологий  имеют свой собственный отладочный фреймвёк. Для MS это и собственная подсистема исключений, правила генерации кодов, ASSERT, ТRАСЕ в MFC плюс специальные методы классов... Что использовать - дело десятое, но в том, что код должен в себе содержать подсистему отладки и контроля выполнеия, а не только функционал, это, ИМХО, правильный подход. Бо тогда в коде содержится стратегия его отладки. А ведь самоотлаживающийся код, равно как и самодокументирующийся - это хороший код;)

 

 

Имхо, все ушли в обсуждение возможностей и рациональности собственного отладочного фреймворка, так и позабыв, что сравнивать его надо с дебагером. А у дебагера помимо проверки диапазонов (хотя её в том виде как надо при проверке инвариантов и нет) есть много других особенностей.

А 200 Мб. проект в вихідних текстах на C# + ще проект для 6-ї студії  на С++ + MFC + COM теж на 170 Мб пробував запускати,
Двуядронні машини з 2 Гб памяті захлинаються і пихтять до 2-3 хвилин, це ще без Visual Assist і ReSharper, якщо їх врубаєш, можна сміло кожен запуск відладки перетворювати чайну церемонію, якраз встигнеш чашку чаю випити поки студію запустиш.
А тепер головне  питання: Навіщо запускати відлагоджувач лише щоб подивитися значення потрібної змінної. З незапамятних часів існує відлагоджувальний вивід, в Руссиновича навіть утиліта для цього є (DbgView), що не потрібно студію додатково грузити . А в коді

using System.Diagnostics;
...
Debugger.Log(...); чи якщо дуже кортить відлагоджувач запустити
Debugger.Break();

Для багатопоточного коду це взагалі єдиний спосіб щось відловити, враховуючи загальний тренд в сторону багатопоточності взагалі альтернатив не бачу. А ввійти ще раз в відлагоджувач, якщо ви з C# перейшли на виконання JavaScript неможливо, треба запускати наприклад ScriptDebugger який суттєво обмежений в можливостях. При даному підході єдине що вбиває, що неможна вигрузити .NET dll-лку, щоб на льоту замінити перекомпільованою.

Треба зразу намагатися писати чисто і головне розбивати на код на контрольні точки , щоб максимально локалізувати проблему і вирішити без запуску відлагоджувача. Особисто я його зараз запускаю десь у 5% випадків. Відлагоджувальні фреймворки якщо добре написані це дуже добре, а взагалі про їх переваги стільки написано , що я не уявляв що в когось ще сумніви є в їхній ефективності. В замовника теж відлагоджувач запускати будете, а в 1000 замовників? А так добрий фремворк може запакувати значенням StackTrace, змінні оточення і відіслати вам максимальну кількість інфи для відтворення дефекту. Та ж ХР має вбудовані такі речі.
До речі корисно запустити DbgView і простежити скільки софта на твоїй машині сповідують підхід виводу інформації в відлагоджувальну консоль.
Для мене (зловживаєш відлагоджувачем == поганий, або некваліфікований розробник), це не стосується супроводу , іноді щоб розібратися як працює система інакше , ніж як через відлагоджувач не побачиш.


P.S. До використання відлагоджувальної консолі використовував журнал подій з заведенням окремого журналу для моєї програми, так роблять наприклад Interne Explorer, драйвера відеокарт ATI.
P.P.S.Все це моє imho, але перевірене кров'ю потом і безсонними ночами.

stoune:

Имхо, все ушли в обсуждение возможностей и рациональности собственного отладочного фреймворка, так и позабыв, что сравнивать его надо с дебагером. А у дебагера помимо проверки диапазонов (хотя её в том виде как надо при проверке инвариантов и нет) есть много других особенностей.

А 200 Мб. проект в вихідних текстах на C# + ще проект для 6-ї студії  на С++ + MFC + COM теж на 170 Мб пробував запускати,
Двуядронні машини з 2 Гб памяті захлинаються і пихтять до 2-3 хвилин, це ще без Visual Assist і ReSharper, якщо їх врубаєш, можна сміло кожен запуск відладки перетворювати чайну церемонію, якраз встигнеш чашку чаю випити поки студію запустиш. А тепер головне  питання: Навіщо запускати відлагоджувач лише щоб подивитися значення потрібної змінної.

А навіщо її запускати з кодом? Для того щоб підключатись дебаггером потрібно просто студію запустити. Потім підключитись до працюючого додатку. Якщо будуть pdb файли то студія автоматично буде підтягувати код.

stoune:

З незапамятних часів існує відлагоджувальний вивід, в Руссиновича навіть утиліта для цього є (DbgView), що не потрібно студію додатково грузити . А в коді

using System.Diagnostics;
...
Debugger.Log(...); чи якщо дуже кортить відлагоджувач запустити Debugger.Break();

Ну з тих самих часів є багато чого. Але з тих часів дещо змінилось ;). Я вже казав що вірогідність того що за допомгою Debugger.Log ви отримаєте те що хочете дуже мала. Про Debugger.Break незрозумів... Ви хочете для того щоб щось показати прекомпліювати 200Мб коду? Як на мене це занадото.

stoune:

Для багатопоточного коду це взагалі єдиний спосіб щось відловити, враховуючи загальний тренд в сторону багатопоточності взагалі альтернатив не бачу.

Так це майже правда. Але для цьго є лоад тести і таке інше. За допомогою трейсів ви так само не зможете гарантувати правильної работи як і з дебаггером. Дотогож майже всі вендори з цим зараз ю'ються. Наприклад майкри в 2008 стідії додали підтримку потоків. Як подивлюсь, розповім як воно...

stoune:

А ввійти ще раз в відлагоджувач, якщо ви з C# перейшли на виконання JavaScript неможливо, треба запускати наприклад ScriptDebugger який суттєво обмежений в можливостях. При даному підході єдине що вбиває, що неможна вигрузити .NET dll-лку, щоб на льоту замінити перекомпільованою.

Ходить. Просто в дебаггері потрібно вказати усі таргети.

stoune:

Треба зразу намагатися писати чисто

І захламляти код ассертами...

stoune:

 і головне розбивати на код на контрольні точки , щоб максимально локалізувати проблему і вирішити без запуску відлагоджувача.

Я вже казав про вірогідності...

stoune:

Особисто я його зараз запускаю десь у 5% випадків. Відлагоджувальні фреймворки якщо добре написані це дуже добре, а взагалі про їх переваги стільки написано , що я не уявляв що в когось ще сумніви є в їхній ефективності. В замовника теж відлагоджувач запускати будете, а в 1000 замовників?

Ні, я до них буду ремот дебаггером під'єднуватись ;). Один раз навіть таке було. Але то ще за царя панька.

В більшості своїх додатків я отримую інформацію тільки на час виколючної ситуації. СтакТрейс, ДодатковаІнфа, КрокиДляВідтворення (якщо є можливість). Покищо цієї інформацієє було достатньо. В деяких ддодакаї використовую той чи інший тип інструментейшена - автоматичне отримання додаткової інформації про виконананя (не про виключні ситуації).

stoune:

 А так добрий фремворк може запакувати значенням StackTrace, змінні оточення і відіслати вам максимальну кількість інфи для відтворення дефекту. Та ж ХР має вбудовані такі речі.

В .Net це вбудоване. Ми про що розмовляємо? Мені здавалось про Debug.Assert. А ви про обробку виключних ситуацій...

stoune:

До речі корисно запустити DbgView і простежити скільки софта на твоїй машині сповідують підхід виводу інформації в відлагоджувальну консоль.

За той час поки я пишу відповідь тільки ffdshow драйвера. Це ж відкирття внутрішнбої інформації яку можно використати для того щоб щось зламати... Цікаво що вона їм зовсім не допоможе якщо цей драйвер впаде...

stoune:

Для мене (зловживаєш відлагоджувачем == поганий, або некваліфікований розробник), це не стосується супроводу , іноді щоб розібратися як працює система інакше , ніж як через відлагоджувач не побачиш.

;), я зловживаю. Я навіть тести пишу так щоб з них можно було дебаггер запускати ;)).

stoune:

P.S. До використання відлагоджувальної консолі використовував журнал подій з заведенням окремого журналу для моєї програми, так роблять наприклад Interne Explorer, драйвера відеокарт ATI.

Туди пишуть не кожний чих. А тільки ящо щось скоїлось. Трейси це кожний чих...

stoune:

P.P.S.Все це моє imho, але перевірене кров'ю потом і безсонними ночами.

Ндя, в мене такго досвіду немає. В мне кров, пот та безсонні ночі уходять на биття з архітектурами...

---

MCPD(Web,Windows,Enterprise), MCTS (WPF, WCF)