что такое отладчик в программировании
Что такое отладка?
Отладчик Visual Studio — очень эффективное средство. Прежде чем приступать к его использованию, следует ознакомиться с базовыми терминами, такими как отладчик, отладка и режим отладки. Когда позднее мы будем вести речь о поиске и устранении ошибок, мы будем иметь в виду то же самое.
Отладчик и отладка
Термин отладка может иметь разные значения, но в первую очередь он означает устранение ошибок в коде. Делается это по-разному. Например, отладка может выполняться путем проверки кода на наличие опечаток или с помощью анализатора кода. Код можно отлаживать с помощью профилировщика производительности. Кроме того, отладка может производиться посредством отладчика.
Отладчик — это узкоспециализированное средство разработки, которое присоединяется к работающему приложению и позволяет проверять код. В документации по отладке для Visual Studio именно это обычно подразумевается под отладкой.
Режим отладки и выполнение приложения
При первом запуске приложения в Visual Studio его можно запустить, нажав кнопку с зеленой стрелкой 
на панели инструментов (или клавишу F5). По умолчанию в раскрывающемся списке слева отображается элемент Отладка. Если вы не имеете опыта работы с Visual Studio, может показаться, что отладка приложения — это практически то же самое, что его запуск. На самом деле эти задачи хоть и связаны, но коренным образом различаются.
Значение Отладка соответствует конфигурации отладки. Когда вы запускаете приложение (нажимая зеленую стрелку или клавишу F5) в конфигурации отладки, оно запускается в режиме отладки. Это означает, что приложение запускается с присоединенным отладчиком. В результате вы получаете полный набор функций отладки, которые можно использовать для поиска ошибок в приложении.
Если у вас открыт проект, выберите в раскрывающемся списке Отладка элемент Выпуск.
При выборе этого параметра конфигурация отладки для проекта меняется на конфигурацию выпуска. Проекты Visual Studio имеют отдельные конфигурации выпуска и отладки для вашей программы. Производится построение отладочной версии для отладки и версии выпуска для окончательного выпуска программы. Сборка выпуска оптимизирована для обеспечения максимальной производительности, а отладочная сборка лучше подходит для отладки.
Когда следует использовать отладчик
Отладчик — важнейший инструмент для поиска и устранения ошибок в приложениях. Однако большое значение имеет контекст. Важно использовать все средства, имеющиеся в вашем распоряжении, чтобы быстро устранять ошибки. Зачастую лучшим «средством» являются правильные методики написания кода. Зная, когда лучше использовать отладчик, а когда — другие средства, вы также сможете более эффективно использовать отладчик.
Следующие шаги
Из этой статьи вы узнали общие принципы отладки приложений. Теперь вы можете приступить к знакомству с процессом отладки в Visual Studio и написанию кода с меньшим количеством ошибок. В следующих статьях приводятся примеры кода на C#, но основные понятия применимы ко всем языкам, поддерживаемым средой Visual Studio.
Принципы отладки для начинающих
Независимо от обстоятельств код, создаваемый разработчиками программного обеспечения, далеко не всегда работает так, как задумано. В некоторых случаях все идет совершенно не по плану! В подобных ситуациях необходимо выяснить, почему так происходит. При этом вместо многочасового изучения кода в поисках ошибок гораздо проще и эффективнее будет использовать средство отладки (отладчик).
К сожалению, отладчик не является той волшебной палочкой, по мановению которой будут выявлены абсолютно все проблемы в коде. Процесс отладки подразумевает пошаговое выполнение кода в средстве отладки (например, в Visual Studio) в поисках точки, в которой вы допустили ошибку при написании программы. Таким образом, вы получите возможность проанализировать код и внести в него необходимые исправления. При этом средства отладки часто допускают внесение временных изменений, благодаря чему вы можете продолжать выполнение программы.
Эффективное использование отладчика также требует определенных навыков, которые вырабатываются только с практикой, однако умение работать с ним является основополагающим требованием к любому разработчику программного обеспечения. В этой статье мы познакомим вас с основными принципами отладки и поделимся рекомендациями о том, с чего можно начать.
Проанализируйте проблему, задавая себе правильные вопросы
Это поможет вам выяснить, в чем состоит проблема, прежде чем приступать к ее решению. Мы полагаем, что вы уже сталкивались с проблемами в коде, иначе вряд ли читали бы сейчас эту статью в поисках советов по его отладке! Итак, прежде чем начать отладку, проанализируйте проблему, которую вы пытаетесь решить:
Что именно должен был выполнить код?
Что произошло вместо этого?
Если во время выполнения приложения вы столкнулись с ошибкой или исключением, это может быть хорошим признаком! Исключение возникает в том случае, если при выполнении кода происходит непредвиденное событие (как правило, это ошибка какого-либо рода). С помощью средства отладки вы можете перейти точно к тому месту в коде, где возникло исключение, и исследовать возможные способы исправления ситуации.
Если произошло что-то еще, каковы признаки проблемы? Есть ли у вас предположения относительно того, в каком месте кода возникла проблема? Например, если код должен выводить какой-то текст, но при этом текст содержит ошибки, вы можете сделать вывод, что в этом случае используются неверные данные или код вывода текста содержит ошибки другого рода. При пошаговом выполнении кода в отладчике вы можете изучить каждое изменение переменных и точно определить, когда и каким образом были присвоены неверные значения.
Проверьте свои предположения
Прежде чем исследовать причины возникновения ошибки, проверьте предположения, на основании которых вы ожидаете тот или иной результат. Скрытые или неизвестные предположения могут помешать выявлению проблемы, даже если вы изучаете непосредственно место ее возникновения в отладчике. Перечень возможных предположений может быть достаточно большим. Чтобы проверить их, задайте себе несколько вопросов.
Используете ли вы нужный API (то есть соответствующие объект, функцию, метод или свойство)? Возможно, используемый вами API работает не так, как вы ожидаете. (После проверки вызова API в отладчике для исправления проблемы и выявления нужного API вам может потребоваться обратиться к документации.)
Правильно ли вы используете API? Даже если вы выбрали нужный API, он может использоваться неправильно.
Нет ли в вашем коде опечаток? Некоторые опечатки, например ошибки в написании имени переменной, могут быть незаметными, особенно при работе с языками, в которых не требуется объявление переменных перед их использованием.
Вносили ли вы изменения в код и могут ли они быть связаны с возникшей проблемой?
Должны ли объект или переменная содержать определенное значение (или определенный тип значения) и соответствует ли это действительности?
Известно ли назначение кода? Как правило, отладка кода, написанного другим разработчиком, дается гораздо сложнее. Если это не ваш код, возможно, для его эффективной отладки вам потребуется изучить, что он делает.
При написании кода старайтесь начинать с небольших и гарантированно работающих фрагментов! (В этом вам может помочь хороший пример кода.) В некоторых случаях для исправления большого сложного фрагмента кода можно начать с маленького сегмента, демонстрирующего основную задачу, которую требуется выполнить. Затем вы можете последовательно изменять или добавлять код в поисках точки возникновения ошибки.
Анализируя собственные предположения, вы можете сократить время, необходимое на поиск проблем в коде. Кроме того, вы можете ускорить решение самих проблем.
Используйте режим пошагового выполнения во время отладки для поиска места возникновения проблемы.
Очевидно, что ошибки и неверные результаты можно увидеть только после выполнения кода приложения. Кроме того, работа программы может завершиться неожиданно без каких-либо сообщений.
При выполнении приложения в отладчике (в так называемом режиме отладки) осуществляется активный мониторинг всего, что происходит во время работы программы. Кроме того, вы можете в любой точке приостановить работу приложения, исследовать его состояние и при необходимости перейти в режим пошагового выполнения, чтобы изучить необходимые строки кода более детально.
Чтобы перейти в режим отладки в Visual Studio, необходимо нажать клавишу F5 (также вы можете выбрать пункт меню Отладка > Начать отладку или нажать кнопку Начать отладку в панели инструментов «Отладка»). Если возникает исключение, помощник по исправлению ошибок Visual Studio направит вас к точке его появления и предоставит другую необходимую информацию. См. дополнительные сведения об обработке исключений в коде в разделе Приемы и инструменты отладки.
Если исключение не возникает, возможно, вам следует проанализировать определенные места в коде, которые могут являться источником проблемы. На этом этапе следует использовать точки останова в отладчике, благодаря которым вы сможете исследовать код более внимательно. Точки останова — это один из самых простых и важных компонентов надежной отладки. Точка останова указывает, где Visual Studio следует приостановить выполнение кода, чтобы вы могли проверить значения переменных, поведение памяти или последовательность выполнения кода.
Чтобы задать точку останова в Visual Studio, достаточно щелкнуть в левом поле рядом с интересующей вас строкой кода. Также для этого можно поместить указатель мыши в нужную строку и нажать клавишу F9.
Чтобы продемонстрировать это, мы рассмотрим пример кода, который уже содержит несколько ошибок. В этом случае мы используем C#, однако функции отладки также работают для Visual Basic, C++, JavaScript, Python и других поддерживаемых языков. Также предоставлен пример кода для Visual Basic, но снимки экрана приведены для C#.
Создание образца приложения с ошибками
Сейчас мы создадим приложение, которое содержит некоторые ошибки.
Установите Visual Studio бесплатно со страницы скачиваемых материалов Visual Studio, если еще не сделали этого.
Запустите Visual Studio.
Visual Studio создаст консольный проект и откроет его в обозревателе решений (правая область).
Откройте файл Program.cs (или Program.vb) и замените все его содержимое по умолчанию следующим кодом. (Сначала выберите вкладку для нужного языка: C# или Visual Basic.)
Этот код выводит список, содержащий название галактики, расстояние до нее, а также тип галактики. При отладке важно учитывать предназначение кода. Ниже показан формат одной строки списка, который должен выводить код.
название галактики, расстояние, тип галактики.
Запуск приложения
Нажмите клавишу F5 или кнопку Начать отладку на панели инструментов «Отладка», которая расположена над редактором кода.
По результатам запуска приложения отладчик не демонстрирует никаких исключений. Тем не менее данные, выводимые в окно консоли, не соответствуют ожиданиям. Вот, что мы должны были увидеть.
Вместо этого выводятся следующие данные.
Проанализировав выходные данные и код, мы можем сделать вывод, что в классе GType содержится тип галактики. Нам необходимо выводить на экран тип галактики (например, Spiral), а не название класса.
Отладка приложения
В месте установки точки останова в левом поле появится красный круг.
Поскольку возникшая проблема связана с выходными данными, необходимо начать отладку с проверки кода, который выполняется перед установкой выходных данных.
Нажмите кнопку Перезапустить 
на панели инструментов отладки (CTRL + SHIFT + F5).
Выполнение приложения приостановится в заданной точке останова. Место приостановки отладчика будет выделено желтым цветом (при этом желтая строка кода на этот момент не выполнена).
Изначально вы ожидаете, что в окно консоли будет выведено именно значение Spiral. Таким образом, вам следует проверить это значение в коде во время выполнения приложения. В этом сценарии мы используем неправильный API. Посмотрим, сможем ли мы исправить проблему во время выполнения кода в отладчике.
Чтобы выполнить отладку примера кода Visual Basic, пропустите несколько следующих шагов до инструкции, по которой нужно щелкнуть Перезапустить .
Измените предшествующий код на следующий.
Нажмите кнопку Перезапустить на панели инструментов отладки (CTRL + SHIFT + F5), чтобы выполнить повторную компиляцию кода и снова запустить его.
Удалите точку останова, щелкнув ее кружок в левом поле (также для этого можно выбрать команду Точка останова > Удалить точку останова). После этого нажмите клавишу F5 для продолжения.
Приложение запускается и отображает выходные данные. Теперь все работает правильно, однако вы можете заметить еще одну неточность. Для галактики Small Magellanic Cloud, которая имеет тип Irregular, в консоли не выводится никакой тип.
Установите точку останова в этой строке кода перед инструкцией switch (перед инструкцией Select в Visual Basic).
Здесь задается тип галактики, поэтому нам необходимо изучить эту строку более пристально.
Нажмите кнопку Перезапустить на панели инструментов отладки (CTRL + SHIFT + F5) для перезапуска.
Отладчик приостановит работу в строке кода, где вы задали точку останова.
Нажмите клавишу F11 (выберите Отладка > Шаг с заходом или нажмите кнопку Шаг с заходом в панели инструментов «Отладка»).
При нажатии клавиши F11 отладчик переходит на одну инструкцию вперед и выполняет соответствующий код. Клавиша F10 (Шаг с обходом) имеет схожую функцию и также полезна при работе с отладчиком.
Нажимайте клавишу F11 до тех пор, пока вы не остановитесь в строке кода с инструкцией switch для значения «I» (инструкция Select для Visual Basic). Здесь вы увидите очевидную ошибку, связанную с опечаткой. Вы ожидали, что код будет выполнен дальше до места, где для MyGType задается тип галактики Irregular, однако вместо этого отладчик полностью пропускает этот код и приостанавливает работу в разделе default инструкции switch (инструкция Else для Visual Basic).
Удалите точку останова и нажмите кнопку Перезапустить, чтобы запустить приложение снова.
Теперь все ошибки исправлены и приложение выдает ожидаемые результаты.
Нажмите любую клавишу, чтобы завершить работу приложения.
Сводка
Если вы сталкиваетесь с проблемой, воспользуйтесь отладчиком и командами пошагового выполнения, такими как F10 и F11, для поиска области кода, в которой возникают ошибки.
Если выявить проблемную область кода не удается, задайте точку останова в коде, который выполняется перед возникновением ошибки, после чего используйте команды пошагового выполнения, пока проблема не проявится. Также вы можете использовать точки трассировки для вывода сообщений в окно вывода. Анализируя сообщения, которые выводятся в окно или отсутствуют в нем, нередко можно изолировать область кода, где возникает проблема. Для дальнейшего сужения области поиска этот процесс может потребоваться повторить несколько раз.
Выявив проблемную область кода, используйте отладчик для ее детального анализа. Чтобы определить причину возникновения проблемы, проверьте код во время выполнения приложения в отладчике.
Проверьте переменные и убедитесь, что они содержат значения того типа, который вы ожидаете. Если переменная содержит недопустимое значение, найдите, где оно было задано. Для этого может потребоваться перезапустить отладчик, проверить стек вызовов или выполнить одновременно оба этих действия.
Проверьте, выполняет ли ваше приложение код, который вы ожидаете. (Так, в примере приложения должна была выполняться инструкция switch, устанавливающая тип галактики Irregular, однако нужный код был пропущен из-за опечатки.)
Отладчик представляет собой эффективное средства для выявления ошибок. Средство отладки может искать ошибки вместо вас в том случае, если ему известно предназначение кода. Для этого вы должны указать предназначение. Этого можно добиться с помощью модульных тестов.
Следующие шаги
Из этой статьи вы узнали общие принципы отладки приложений. Теперь вы можете приступить к изучению других возможностей отладчика.
Отладка как процесс
Существует мнение, что разработка занимает около 10% времени, а отладка — 90%. Возможно, это утверждение утрировано, но любой разработчик согласится с тем, что отладка — крайне затратный по ресурсам процесс, особенно в больших многопоточных системах.
Таким образом, оптимизация и систематизация процесса debugging’а может приносить весомые плоды в виде сэкономленных человеко-часов, повышения скорости решения проблем и, в конце концов, увеличения лояльности ваших пользователей.
Сергей Щегрикович (dotmailer) на конференции DotNext 2018 Piter предложил взглянуть на отладку как на процесс, который может быть описан и оптимизирован. Если вы до сих пор не имеете четкого плана поиска багов — под катом видео и текстовая расшифровка доклада Сергея.
(А еще в конце поста мы добавили обращение Джона Скита ко всем дотнетчикам, обязательно посмотрите)
Моя цель — ответить на вопрос: как фиксить баги эффективно и на чем должен быть фокус. Я думаю, что ответ на этот вопрос — процесс. Процесс debugging’а, который состоит из очень простых правил, и вы хорошо их знаете, но, наверно, используете неосознанно. Поэтому моя задача — это систематизировать их и на примере показать как стать более эффективными.
Мы выработаем общий язык общения во время отладки, а также увидим прямой путь к поиску основных проблем. На своих примерах я покажу что получалось из-за нарушения этих правил.
Утилиты отладки
Конечно, любой debugging невозможен без утилит для отладки. Моими любимыми являются:
Падающий сервис
Начнем с примера из моей жизни, в котором я покажу, как бессистемность процесса debugging’а ведет к неэффективности.
Наверно, у каждого такое бывало, когда ты приходишь в новую компанию в новую команду на новый проект, то с самого первого дня хочется нанести непоправимую пользу. Так было и у меня. В то время у нас был сервис, который на вход принимал html, а на выход выдавал картинки.
Сервис был для нас не критичен и мы могли это пережить. Но к проекту подключился я и первое, что решил сделать — исправить это.
Компилируем, деплоим, сервис падает, ошибок нет. За этим процессом проходит три дня, теперь уже приходят мысли о том, что надо наконец-то начать думать и делать что-нибудь другое. Делать можно много чего: попробовать воспроизвести ошибку на локальной машине, смотреть дампы памяти и тд. Казалось, еще дня два и я пофикшу этот баг…
Я смотрел в PerformanceMonitor, где видел сервис, который падает, потом поднимается, потом снова падает. Это состояние называется отчаяние и выглядит вот так:
В этом разнообразии меток ты пытаешься понять, где же на самом деле проблема? После нескольких часов медитации проблема вдруг обнаруживается:
Красная линия — это количество нативных handle’ов, которыми владеет процесс. Нативный handle — это ссылка на ресурс операционной системы: файл, реестр, ключ реестра, мьютекс и тд. По какому-то непонятному стечению обстоятельств падение роста количества handle’ов совпадает с моментами падения сервиса. Это наталкивает на мысль о том, что где-то есть утечка handle’ов.
Берем дамп памяти, открываем его в WinDbg. Начинаем выполнять команды. Попробуем посмотреть очередь финализации тех объектов, которые должны быть освобождены приложением.
В самом конце списка я нашел web-браузер.
Решение простое — взять WebBrowser и вызывать для него dispose :
Выводы из этой истории можно сделать такие: две недели — это долго и слишком много, чтобы найти невызванный dispose ; то, что мы нашли решение проблемы — везение, так как не было какого-то определенного подхода, не было системности.
После этого у меня возник вопрос: а как дебажить эффективно и что для этого делать?
Для этого надо знать всего три вещи:
Правила отладки
Повтори ошибку. Очень простое правило, поскольку, если ты не можешь повторить ошибку, то, возможно, и фиксить нечего. Но бывают разные случаи, особенно это касается багов в многопоточной среде. У нас как-то была ошибка, которая появлялась только на процессорах Itanium и только на продакшн-серверах. Поэтому первая задача в процессе отладки — найти такую конфигурации тестового стенда, на которой бы ошибка воспроизводилась.
Если ты не исправил ошибку, то она не исправлена. Иногда бывает такое: в баг-трекере лежит баг, который появлялся пол года назад, уже его давно никто не видел, и есть желание его просто закрыть. Но в этот момент мы упускаем шанс на знание, шанс на то, чтобы понять как работает наша система и что с ней действительно происходит. Поэтому любой баг — это новая возможность что-то выучить, узнать больше о своей системе.
Пойми систему. Брайан Керниган сказал как-то, что если мы были такие умные, чтобы написать эту систему, то нам нужно быть вдвойне умными, чтобы её дебажить.
Небольшой пример к правилу. Наш мониторинг рисует графики:
Это график количества запросов, обработанных нашим сервисом. Однажды посмотрев на него мы пришли к идеи о том, что можно было бы увеличить скорость работы сервиса. В этом случае график поднимется, возможно, удастся уменьшить количество серверов.
Оптимизация web-performance делается просто: берем PerfView, запускаем его на продакшн-машине, он снимает trace в течении 3-4 минут, мы этот trace забираем на локальную машину и начинаем его изучать.
Одна из статистик, которую показывает PerfView — garbage collector.
Посмотрев на эту статистику мы увидели, что 85% времени сервис тратит на сборку мусора. Можно в PerfView увидеть где конкретно тратится это время.
В нашем случае — это создание строк. Исправление напрашивается само самой: заменяем все string’и на StringBuilder’ы. Локально получаем прирост производительности на 20-30%. Деплоим на продакшн, смотрим результаты в сравнении со старым графиком:
Правило «Пойми систему» — это не только о том, чтобы понять как в вашей системе происходят взаимодействия, как ходят сообщения, а о том, чтобы попробовать смоделировать свою систему.
В примере график показывает пропускную способность. Но если посмотреть на всю систему с точки зрения теории очередей, то окажется, что пропускная способность нашей системы зависит только от одного параметра — от скорости прихода новых сообщений. По факту в системе просто не было больше 80 сообщений единовременно, поэтому оптимизировать этот график не получится никак.
Проверь штепсель. Если открыть документацию любого домашнего прибора, то там обязательно будет написано: если прибор не работает, проверь, что вилка вставлена в розетку. После нескольких часов в отладчике часто ловлю себя на мысли, что надо было просто перекомпилировать, либо просто забрать последнюю версию.
Правило «проверь штепсель» — это про факты и данные. Отладка не начинается с запуска WinDbg или PerfView на продакшн-машинах, она начинается с проверок фактов и данных. Если сервис не отвечает, возможно он просто не запущен.
Разделяй и властвуй. Это первое и, наверно, единственное правило, которое включает в себя отладку как процесс. Оно про гипотезы, их выдвижение и проверку.
Один из наших сервисов не хотел останавливаться.
Делаем гипотезу: возможно, в проекте есть цикл, который бесконечно что-то обрабатывает.
Проверить гипотезу можно по-разному, один из вариантов — это взять дамп памяти. Из дампа вытаскиваем call-stack’и всех потоков с помощью команды
Делаем вторую гипотезу: возможно, у нас deadlock одной задачи на вторую. Чтобы это проверить, можно через WinDbg посмотреть каждую задачу по-отдельности.
Оказывается, одна из задач упала, а вторая — нет. В проекте мы увидели такой код:
Он означает, что инициализационная задача открывает connection и после этого выставляет TaskCompletionSource в true. А что, если здесь упадет Exception? Тогда мы не успеваем выставить SetResult в true, поэтому fix к этому багу был такой:
В этом примере мы выдвигали две гипотезы: о бесконечном цикле и о deadlock’e. Правило «разделяй и властвуй» помогает локализовать ошибку. Последовательными приближениями и решаются такие проблемы.
Самое важное в этом правиле — это гипотезы, поскольку со временем они превращаются в паттерны. И в зависимости от гипотезы мы применяем разные действия.
Освежись. Это правило о том, что надо просто встать из-за стола и пройтись, выпить воды, сока или кофе, сделать что угодно, но самое главное — отвлечься от своей проблемы.
Есть очень хороший метод под названием «уточка». Согласно методу мы должны рассказать о своей проблеме уточке. В качестве уточки можно использовать коллегу. Причем, ему не обязательно отвечать, достаточно слушать и соглашаться. И зачастую, после первых проговоров проблемы, ты сам находишь решение.
Это твой баг. Об этом правиле расскажу на примере.
Для меня это вылилось в 11 месяцев работы с поддержкой Microsoft, конечно, не ежедневно, но от начала до fix’а прошло именно 11 месяцев. Кроме этого, мы отправили им десятки гигабайт дампов памяти, мы ставили сотни private-сборок, чтобы поймать эту ошибку. И все это время мы не могли сказать нашим клиентам, что виновата Microsoft, а не мы. Поэтому баг всегда ваш.
Пять почему. Мы у себя в компании используем Elastic. Elastic хорош для агрегации логов.
Ты приходишь с утра на работу, а Elastic лежит.
Вопросы «почему?» помогают найти корень проблемы. В примере мы много раз могли свернуть с правильного пути, но полный fix выглядит так: обновляем плагин, запускаем сервисы, наращиваем память и делаем пометку на будущее, что в следующий раз, при добавлении новых узлов в кластер, нужно убедиться в достаточности памяти на Master Nodes.
Алгоритм отладки
Впервые про алгоритм отладки я прочитал в книге Джона Роббинса «Debugging applications». Он описывает процесс отладки так:
Этот алгоритм полезен своим внутренним циклом — работой с гипотезой.
С каждым витком цикла мы можем себя проверить: знаем ли мы больше о системе или нет? Если мы выдвигаем гипотезы, проверяем, они не срабатывают, мы не узнаем ничего нового о работе системы, то, наверно, пора освежиться. Два актуальных вопроса на этот момент: какие гипотезы ты уже проверил и какую гипотезу проверяешь сейчас.
Этот алгоритм очень хорошо согласуется с правилами отладки, о которых мы говорили выше: повтори ошибку — это твой баг, опиши проблему — пойми систему, сформулируй гипотезу — разделяй и властвуй, проверь гипотезу — проверь штепсель, убедись что исправлено — пять почему.
На этот алгоритм у меня есть хороший пример. На одном из наших web-сервисов падал exception.
Первая наша мысль — это не наша проблема. Но по правилам, это все-таки проблема наша.
Во-вторых, пытаемся описать проблему: если пользователь делает http-запрос на наш сервис в момент, когда StructureMap пытается сделать новую зависимость, то в этом случае происходит исключение.
В-третьих, выдвигаем гипотезу о том, что StructureMap — это wrapper и внутри что-то есть, что кидает внутреннее исключение. Проверяем гипотезу с помощью procdump.exe.
Исследуя call-stack этого исключения понимаем, что оно происходит внутри object-builder’а в самом StructureMap.
Но NullReferenceException — это не сама проблема, а следствие. Нужно понять где оно возникает и кто его генерирует.
Итак, алгоритм отладки — это интуитивный алгоритм, который существенно экономит время. Он делает упор на гипотезу — а это самое главное в отладке.
Проактивная отладка
По своей сути проактивная отладка отвечает на вопрос «что произойдет, когда появится баг».
Важность техники проактивной отладки можно увидеть на диаграмме цикла жизни бага.
Проблема в том, что чем дольше баг живет, тем больше мы ресурсов (времени) на него тратим.
Правила отладки и алгоритм отладки фокусируют нас на моменте, когда баг найден и мы можем придумать что дальше с ним делать. На самом же деле мы хотим сместить свой фокус на момент создания бага. Я считаю, что мы должны делать Minimum Debuggable Product (MDP), то есть такой продукт, который имеет минимально необходимый набор инфраструктуры для эффективной отладки в продакшене.
MDP состоит из двух вещей: фитнес-функции и USE метода.
Фитнес-функции. Были популяризированы Нил Фордом и соавторами в книге «Building Evolutionary Architectures ». По своей сути фитнес-функции, по мнению авторов книги, выглядят так: есть архитектура приложения, которую мы можем разрезать под разными углами, получая такие свойства архитектуры, как maintainability, performance и прочее, и на каждый такой разрез мы должны писать тест — фитнес-функцию. Таким образом, фитнес-функция — это тест на архитектуру.
В случае MDP, фитнес-функция — это проверка debuggability. Для написания таких тестов можно использовать все что угодно: NUnit, MSTest и тд. Но, поскольку, отладка — это, зачастую, работа с внешними tool’ами, я покажу на примере использование Pester’а (powershell unit testing framework). Его плюс здесь в том, что он хорошо работает с командной строкой.
Например, внутри компании мы договариваемся, что будем использовать конкретные библиотеки для логирования; при логировании мы будем использовать конкретные паттерны; pdb-символы должны быть отданы всегда на symbol server. Это и будет являться теми условностями, которые мы будем проверять в наших тестах.
Этот тест проверяет, что все pdb-символы были отданы на symbol server и были отданы правильно, то есть те, которые содержат номера строк внутри. Для этого берем скомпилированную версию продакшена, находим все exe- и dll-файлы, пропускаем все эти бинарники через утилиту syschk.exe, которая входит в пакет «Debugging tools for windows». Утилита syschk.exe сверяет бинарник с symbol server’ом и, если находит там pdb-файл, печатает отчет об этом. В отчете мы ищем строку «Line numbers: TRUE». И в финале проверяем, чтобы результат был не «null or empty».
Такие тесты необходимо встраивать в continuous deployment pipeline. После того, как прошли интеграционные тесты и unit-тесты, запускаются фитнес-функции.
Покажу ещё один пример с проверкой нужных библиотек в коде.
В тесте мы берем все файлы packages.config и пытаемся найти в них библиотеки nlog. Аналогично мы можем проверить, что внутри поля nlog используется поле correlation id.
USE методы. Последнее, из чего состоит MDP — это метрики, которые нужно собирать.
Продемонстрирую на примере метода USE, который был популяризирован Бренданом Греггом. Идея простая: если в коде есть какая-то проблема, достаточно взять три метрики: utilization (использование), saturation (насыщение), errors (ошибки), которые помогут осознать где проблема.
Некоторые компании, например Circonus (они делают monitoring soft), свои дашборды выстраивают в виде обозначенных метрик.
Если посмотреть детально, например, на память, то использование — это количество свободной памяти, насыщение — это количество обращений к диску, ошибки — это любые ошибки, которые появлялись. Поэтому чтобы делать удобные для отладки продукты, нужно собирать USE-метрики для всех фич и всех частей подсистемы.
Если взять какую-нибудь бизнес-фичу, то, скорее всего, в ней можно выделить три метрики:
Первая гипотеза, которую мы сделали, — сервис упал и надо его запустить заново. При проверке оказывается, что сервис работает, использует 4-5% CPU.
Вторая гипотеза — внутри сервиса падает ошибка, которую мы не видим. Воспользуемся утилитой etrace.
Утилита позволяет в realtime подписываться к ETW-events и выводить их на экран.
Следующая гипотеза — кто-то съедает всю память. Согласно дампу памяти, больше всего объектов находится в кэше.
Из кода видно, что каждый час кэш должен очищаться. Но памяти уже не хватало, до очистки даже не доходили. Посмотрим на пример метрики USE для кеша.
По графику сразу видно — возросла память, сразу начались ошибки.
Итак, выводы о том, что же такое проактивная отладка.