Как последовательно организовать код для отладки?

Question

Работая в большом проекте, который требует отладки (как и любой проект), вы понимаете, как сильно люди любят "printf" перед встроенным отладчиком IDE. Под этим я подразумеваю

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

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

Как вы решаете это?

Всегда хорошо иметь стандарты именования, и я думаю, что стандарты кодирования отладки должны быть весьма полезны (например, пометить каждую переменную отладки суффиксом _DBG). Но я также предполагаю, что наименования просто недостаточно. Может быть, объединить его в дружественный класс трекера или создать надежную базу макросов, чтобы стереть все это для выпуска. Я не знаю.

Какие методы проектирования, шаблоны и стандарты вы бы приняли, если бы вас попросили написать документ для отладки кода для всех остальных участников проекта?

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

Спасибо.

Answer 1

Не фиксируйте код отладки, просто инструменты отладки.

Loggin OTOH занимает естественное место в процедурах обработки исключений и тому подобном. Также для отладки могут быть полезны несколько удачно размещенных журналов регистрации в нескольких часто используемых API.

Как одна запись журнала для регистрации всего SQL, выполненного из системы.

Answer 2

Создание собственных правильных инструментов отладки может быть чрезвычайно полезным. Например, в трехмерной среде у вас может быть возможность отобразить октодерево, или отобразить запланированные пути AI, или нарисовать путевые точки, которые обычно невидимы. Возможно, вы также захотите, чтобы экранное меню также помогало с профилированием: текущая частота кадров, количество полигонов на экране, использование текстурной памяти и т. Д.

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

Answer 3

Меня смутила одна и та же проблема почти во всех проектах, с которыми я был связан, так что теперь у меня есть привычка, которая включает в себя широкое использование библиотек журналов (независимо от языка / платформы) с самого начала. Любой порт Log4X мне подходит.

Answer 4

Код отладки / регистрации действительно может быть навязчивым. В наших проектах C ++ мы заключаем общий код отладки / журнала в макросы - очень похоже на утверждения. Я часто нахожу, что ведение журнала наиболее полезно в компонентах нижнего уровня, поэтому оно не должно идти везде.

В других ответах есть много вопросов, с которыми можно согласиться и не согласиться :) Наличие кода отладки / регистрации может быть очень полезным инструментом для устранения неполадок. В Windows есть много методов - две основные из них:

• Широкое использование проверенных (DBG) сборок подтверждает и много тестов на сборках DBG.
• использование ETW в том, что мы называем 'fre' или 'retail' сборками.

Проверенные сборки (которые чаще всего называют сборками DEBUG) также очень полезны для нас. Мы запускаем все наши тесты как на сборках 'fre', так и на сборке 'chk' (также на x86 и AMD64, все более серьезные вещи работают и на Itanium ...). Некоторые люди даже самостоятельно принимают (собачий корм) на проверенных сборках. Это делает две вещи

1. Находит много ошибок, которые иначе не найдутся.
2. Быстро устраняет шумные или неестественные утверждения.

В Windows мы широко используем Event Tracing для Windows (ETW). ETW - эффективный механизм статического каротажа. Ядро NT и многие компоненты очень хорошо оснащены. ETW имеет много преимуществ:

• Любой поставщик событий ETW может быть динамически включен / отключен во время выполнения - перезагрузка или перезапуск процесса не требуются. Большинство провайдеров ETW обеспечивают детальный контроль над отдельными событиями или группами событий.
• События от любого провайдера (наиболее важно, ядра) могут быть объединены в одну трассировку, поэтому все события могут быть коррелированы.
• Объединенную трассировку можно скопировать из коробки и полностью обработать - с помощью символов.
• Образец прерывания файла образца ядра NT может генерировать событие ETW - это дает очень легкий образец профилировщика, который можно использовать в любое время
• В Vista и Windows Server 2008 регистрация событий не блокируется и полностью поддерживает несколько ядер - поток на каждом процессоре может независимо регистрировать события без необходимости синхронизации между ними.

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

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

Я очень уважительно не согласен с tvanfosson. Даже лучший код может извлечь выгоду из хорошо реализованной регистрации. Хорошо реализованная статическая регистрация во время выполнения может упростить поиск многих проблем - без этого вы не будете иметь никакого отношения к тому, что происходит в вашем компоненте. Вы можете посмотреть на входы, выходы и догадаться - вот и все.

Здесь ключом является термин «хорошо реализованный». Контрольно-измерительные приборы должны быть в нужном месте. Как и любая другая вещь, это требует некоторых мыслей и планирования. Если его нет в полезных / интересных местах, он не поможет вам найти проблемы в сценарии разработки, тестирования или развертывания. Вы также можете иметь слишком много инструментария, вызывающего проблемы с перфорацией, когда он включен - или даже выключен!

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

Вот сценарий для вас (обратите внимание, это очень хорошо может не относиться к вам ... :)). Допустим, у вас есть бизнес-приложение, развернутое на каждом настольном компьютере в вашей компании - сотни или тысячи пользователей. Что вы делаете, когда у кого-то есть pbolem? Вы заходите в их офис и подключаете отладчик? Если да, то как узнать, какая у них версия? Где вы получаете правильные символы? Как вы получаете отладчик в своей системе? Что делать, если это происходит только раз в несколько часов или дней? Собираетесь ли вы позволить системе работать с подключенным отладчиком все это время?

Как вы можете себе представить - подключение отладчика в этом сценарии разрушительно.

Если ваш компонент оснащен ETW, вы можете попросить своего пользователя просто включить трассировку; продолжать делать свою работу; затем нажмите кнопку «WTF», когда возникнет проблема. Еще лучше: ваше приложение может иметь возможность самостоятельной регистрации - обнаружение проблем во время выполнения и автоматическое включение регистрации. Он может даже отправлять вам файлы ETW при возникновении проблем.

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

Answer 5

Просто не прибегайте к инструменту, изменяя его. Научитесь пользоваться отладчиком. Сделайте регистрацию и обработку ошибок легкой. Взгляните на Аспектно-ориентированное программирование

Answer 6

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

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

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

Answer 7

В VB6 у вас есть

Debug.Print

, который отправляет вывод в окно в IDE. Это терпимо для небольших проектов. VB6 также имеет

#If <some var set in the project properties>
'debugging code
#End If

У меня есть класс журналирования, который я объявляю вверху

Dim Trc as Std.Traces

и использовать в разных местах (часто внутри блоков # If / # End If)

Trc.Tracing = True
Trc.Tracefile = "c:\temp\app.log"
Trc.Trace 'with no argument stores date stamp
Trc.Trace "Var=" & var

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

Answer 8

Я думаю, что особенно важно избегать непосредственного использования System.outs / printfs и вместо этого использовать (даже пользовательский) класс ведения журнала. Это, по крайней мере, дает вам централизованный переключатель уничтожения для всех журналов (минус затраты на вызовы в Java).

Также полезно, чтобы у этого класса журнала была информация / warn / error / caveat и т. Д.

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

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

Answer 9

Ведение журнала или отладка? Я считаю, что хорошо разработанное и должным образом протестированное на модуле приложение не должно постоянно использоваться для отладки. С другой стороны, регистрация может быть очень полезна как для поиска ошибок, так и для аудита действий программы. Вместо того, чтобы охватывать много информации, которую вы можете получить в другом месте, я бы указал вам logging.apache.org для конкретных реализаций, которые вы можете использовать, или для шаблона для разумного проектирования инфраструктуры ведения журналов.

Answer 10

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

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