Организация процесса отладки программ что это

Содержание

РАЗРАБОТКА И ОТЛАДКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Преобразование схемы алгоритма в исходный текст программы для выбранного микроконтроллера осуществляется достаточно просто с использованием инструментальных средств разработки и отладки программного обеспечения. В настоящее время для программирования и отладки программного обеспечения микроконтроллеров используются большое количество разнообразных инструментальных средств.

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

Как устроен процесс разработки? ДЛЯ НОВИЧКОВ / Про IT / Geekbrains

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

Если МК имеет гарвардскую архитектуру, то память программ и данных физически и логически разделены. Память данных обычно имеет ограниченный объем. Это обстоятельство нужно учитывать при разработке программ для МК. Так, при программировании МК константы лучше хранить не как переменные, а заносить в ПЗУ программ. Прикладные программы должны ориентироваться на работу без использования больших массивов данных.

В памяти данных МК также находится стек. Стековая память обычно имеет ограниченный объем. Разработчик микроконтроллерных систем должен следить за тем, чтобы стек не переполнялся. При разработке программ для компьютеров наполняемость стека контролируется интегрированной средой программирования.

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

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

Без этого вы не станете программистом! Найти ошибку в коде. Отладка. Как пользоваться отладчиком #23

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

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

В компьютере программа в определенный момент времени запускается и завершается. Программа, управляющая МК, запускается при включении устройства и не завершает свою работу, пока не будет выключено питание. Она как бы «наблюдает» за использованием ресурсов микроконтроллерной системы, поэтому ее иногда называют «монитором». Схема алгоритма программы-монитора приведена на рис.2.

Рис. 2. Схема работа программы–монитора

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

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

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

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

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

Рис. 3. Схема реализации параллельных программных потоков

В настоящее время самым мощным средством разработки программного обеспечения для МК являются интегрированные среды разработки, имеющие в своем составе менеджер проектов, текстовый редактор и симулятор, а также допускающие подключение компиляторов языков высокого уровня типа Паскаль или Си. При этом необходимо иметь в виду, что архитектура многих 8-разрядных микроконтроллеров вследствие малого количества ресурсов, страничного распределения памяти, неудобной индексной адресации и некоторых других архитектурных ограничений не обеспечивает компилятору возможности генерировать эффективный код. Для обхода этих ограничений разработчики ряда компиляторов вынуждены были переложить на пользователя заботу об оптимизации кода программы.

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

Что такое отладка?

Введение в отладку

Введение в отладку

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

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

Зачем нам нужна отладка?

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

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

Процесс отладки

Ниже приведен список этапов, участвующих в процессе отладки

1. Определить ошибку

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

2. Определите местонахождение ошибки

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

3. Анализ ошибки

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

4. Докажите анализ

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

5. Покройте боковой ущерб

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

Преимущества отладки

Ниже приведен список преимуществ отладки

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

Различные инструменты отладки

Для выявления и исправления ошибок использовались различные инструменты, отладочные средства — это программное обеспечение, которое используется для тестирования и отладки других программ. На рынке доступно множество инструментов отладки с открытым исходным кодом, таких как DBX, GDB и т. Д.

Некоторые из инструментов отладки перечислены ниже.
1. GDB (отладчик GNU)
2. LLDB
3. Radare2
4. Microsoft Visual Studio отладчик
5. Вальгринд
6. WinDBg
7. Firefox JavaScript отладчик
8. Eclipse отладчик
9. Рука DTT (Allinea ДДТ)
10. WDW (отладчик OpenWatcom)

Стратегии отладки

Ниже приведены различные стратегии отладки следующим образом:

1. Стратегия обучения

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

2. Опыт

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

3. Форвардный анализ

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

4. Обратный анализ

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

Вывод

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

Общая методика отладки программного обеспечения

Суммируя все сказанное выше, можно предложить следующую методику отладки программного обеспечения, написанного на универсальных языках программирования для выполнения в операционных системах MS DOS и Win32:

1- й этап — изучение проявления ошибки — если выдано какое-либо сообщение или выданы неправильные или неполные результаты, то необходимо их изучить и попытаться понять, какая ошибка могла так проявиться. При этом используют индуктивные и дедуктивные методы отладки. В результате выдвигают версии о характере ошибки, которые необходимо проверить. Для этого можно применить методы и средства получения дополнительной информации об ошибке.

Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.

2- й этап — локализация ошибки — определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса. Локализация может выполняться:

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

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

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

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

5-й этап — повторное тестирование — повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

Следует иметь в виду, что процесс отладки можно существенно упростить, если следовать основным рекомендациям структурного подхода к программированию:

• программу наращивать «сверху-вниз», от интерфейса к обрабатывающим подпрограммам, тестируя ее по ходу добавления подпрограмм;
• выводить пользователю вводимые им данные для контроля и проверять их на допустимость сразу после ввода;
• предусматривать вывод основных данных во всех узловых точках алгоритма (ветвлениях, вызовах подпрограмм).

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

Возвращаясь к рис. 11.2, можно отметить, что проще всего обычно искать ошибки определения данных и ошибки накопления погрешностей: их причины локализованы в месте проявления. Логические ошибки искать существенно сложнее. Причем обнаружение ошибок проектирования требует возврата на предыдущие этапы и внесения соответствующих изменений в проект. Ошибки кодирования бывают как простые, например использование неинициализированной переменной, так и очень сложные, например ошибки, связанные с затиранием памяти.

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

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

Контрольные вопросы

1. Какой процесс называют отладкой? В чем его сложность?
2. Назовите основные типы ошибок. Как они проявляются при выполнении программы?
3. Перечислите основные методы отладки. В чем заключается различие между ними? Возьмите любую программу, содержащую ошибки, и попробуйте найти ошибку, используя каждый из перечисленных методов. Какой метод для вас проще и естественней и почему?
4. Какие средства получения дополнительной информации об ошибках вы знаете? Вспомните, какие ошибки вы искали дольше всего и почему. В каких случаях дополнительная информация позволяет найти ошибку?

Источник: bstudy.net

Обзор методов отладки программного обеспечения

Отладка — это комплексный процесс по выявлению и исправлению дефектов в программном обеспечении. Сами же дефекты, обычно, обнаруживается в процессе тестирования ПО.

(Прим. Часто под термином «отладка» подразумевают «тестирование» + «непосредственно отладка». В данном посте эти термины я буду разделять.)

Отладка состоит из следующих этапов:

воспроизведение дефекта (любым из доступных способов);
анализ дефекта (поиск причины возникновения дефекта — root-cause);
дизайн исправления дефекта (и возможно ревью, если есть альтернативы);
кодирование исправления дефекта (и какие-либо активности связанные с кодированием);
валидация исправления;
интеграция исправления в кодовую базу или целевую систему;
дополнительные валидации после интеграции (если необходимости).

Читайте также:

Ipsec что это за программа

Пункты 1 и 2 — самые длительные этапы. Они могут объединяться, например, если сложность отладки именно в воспроизведение проблемы и имеется достаточно assert-ов в коде, то тогда после воспроизведение дефекта root-cause будет автоматически выявлен за счёт детального сообщения об ошибке в assert-е. Но бывает и по-другому, когда дефект воспроизводится легко, но root-cause абсолютно не ясен.

Если root-cause дефекта найден, то разработать исправление не составляет большого труда (конечно, в зависимости от требований к качеству ПО). Поэтому с этапами 1 и 2 в большинстве случаев ассоциируется термин «отладка». Более того, отладка — это рекурсивный процесс. На любом этапе отладки могут возникнуть новые дефекты, которые придётся отлаживать.

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

Намерено не даю никакие ссылки на инструментальные средства, чтобы не делать рекламы. Методы предотвращения дефектов (защитное программирование, инспекции кода и т.п.) вне скоупа данного поста. Хотя, assert-ы как часть методики защитного программирования могут считаться отдельным вполне полезным методом отладки ПО. Также существуют различные методики рассуждений при поиске root-cause-а, но они тоже вне скоупа ;).

И так, методы отладки ПО используемые на данный момент в индустрии (которыми я пользовался) перечислены ниже.

Запуск программы из под отладчика (софтварного, железячного или удалённого дебагера) с пошаговой отладкой, просмотром состояний (переменных, стека, памяти, регистров, тредов и т.п.) в требуемых точках исполнения программы.
Логирования кода — вывод в файл (или консоль и т.п.) входных, выходных аргументов функций, промежуточных состояний (переменных, стека, памяти, передаваемых или получаемых каким-либо образом данных и т.п.) в процессе исполнения программы. Детальный лог является историческим описанием исполнения программы. При сложностях с воспроизведением сценария дефекта, логирование становится основной методикой отладки.
Анализ кода без исполнения программы — поиск причин возникновения дефекта с помощью анализа исходного кода программы, проблемного контента, конфигурации, состояния базы данных и т.п.
Анализ поведения системы или её части (в т.ч. в более простых use-case-ах) — изолирование проблемы, путём упрощения сценария (используя ручное или автоматическое тестирование). Аксиома звучит так: чем проще сценарий, тем проще отладить проблему. Если найти более простой сценарий, то отладка может упроститься.
Unit тестирование — выполнение автоматических unit test-ов в основном изолировано (т.е. в более простых сценариях) для функций (модулей, компонентов и т.п.), и таким образом автоматическое выявление проблемных участков кода. Unit тестирование в каком-то смысле одна из разновидностей отладки путём «анализа поведения системы».
Прототипирование — проверка функций (модулей, библиотек, и т.п.) в изоляции с помощью небольших примеров кода (прототипов). Прототип легче отлаживать, чем целевую систему. Если проблема воспроизводиться с помощью прототипа, отладка упрощается. Unit тестирование в этом смысле более эффективный метод отладки, поскольку unit test-ы выполняются автоматически и «накапливаются» для будущего реюза, а прототипы редко становятся частью системы.
Отладкас помощью memory-dump-ов или crash-дампов (применимо в основном для анализа паник) — разновидность логирования кода, только здесь логируется не просто некая структура памяти, а целиком вся память процесса и состояния регистров, когда возникает exception. По такому дампу памяти, имея дебажные символы, можно «раскрутить» состояние программы (стеков, очередей, переменных и т.п.), в котором она находилась во время паники. Достаточно много существует инструментальных средств для выполнения этой операции.
Отладка с помощью перехватов (hook-ов, spy-ев) — в основном используется в случаях утечки ресурсов, разновидность логирования кода. Основная идея перехват и логирование вызова функций выделения и освобождения ресурса, а также анализ состояния ресурсов (например, памяти) в требуемый момент времени или в нужной точке исполнения программы.
Профилирование кода (если необходима оптимизация производительности) — разновидность логирования кода, хотя часто выполняется с использованием специализированных инструментальных средств (профилировщиков). Этот метод отладки позволяет получить профиль исполнения программы — сколько и какая функция, строчка кода, модуль, и т.п. отнимают процессорного времени, и таким образом найти узкие места.
Выполнения программы (или её части) в другой среде (операционной системе, эмуляторе, симуляторе) — основная идея в том, что если нет инструментальных средств на целевой платформе, то можно спортировать код на другую платформу, где они есть. Также можно изначально писать кросс-платформенный код системы или какой-то её части, и таким образом, при необходимости практически без портирования отлаживать код на другой платформе.
Отладка методом RPC (remote procedure call) — применимо в основном для встроенного программирования. Суть метода в возможности вызвать любую функцию (модуль и т.п.) передавая аргументы и получая результаты исполнения удалённо с одного хоста на другом вместо того, чтобы тратить время на компиляцию или обновление софта на удалённом хосте (или железке). Существуют множество готовых фреймворков (правда в основном платных), которые инструментируют код и позволяют вызывать любые функции кода через USB или IP соединения.
Отладка путём анализа документации, дизайна, требований или ограничений модулей (программных или аппаратных) — применимо в основном для сложных и крупных проектов. Основная идея понять по имеющейся документации допустимо ли поведение, происходящее в дефекте. Например, поддерживается ли сложная комбинация одновременно работающих фич. Если поведение не поддерживается, то необходимо просто программно закрыть use-case, вместо того, чтобы пытаться глубоко анализировать код или пытаться найти root-cause в third-party компонентах.
Отладка трансляцией кода — сложный алгоритм пишется или прототипируется на одном языке программирования (возможно медленном или интерпретируемом) с наличием всех доступных инструментальных средств (дебагера и т.п.), а потом исходный код отлаженного алгоритма транслируется в ручную или автоматически в другой язык программирования (целевой системы), для которого отсутствуют необходимые инструментальный средства. При таком подходе отладится можно на практически любом удобном для себя языке программирования, а потом заново странслировать программу на целевой язык программирования. Возможны и другие варианты, например, дисассемблерование с целью более низкоуровневого понимания, что происходит при выполнении программы. Т.е. анализируется некий промежуточный вариант кода, который в некоторых ситуациях легче отладить или понять.
Отладка разработкой интерпретатора — это не только метод отладки, но и паттерн проектирования. Этот метод используется, когда модуль требует частых изменений (из-за плавающих требований или поддержки большого количества фич, железок и т.п.), а время построения приложения очень большое. Для ускорения процесса и гибкости пишется небольшой интерпретатор кода с наличием управляющих конструкций if, циклов, goto. При наличии такого интерпретатора разработчик сравнительно не сложно создаёт скрипты, которые можно быстрее исправить и отладить. Как упрощённый вариант такого способа отладки, например, использование дебажных флагов в коде, которые конфигурируют код и позволяют проверить разные варианты исполнения кода сделав лишь один build.

Существуют также неправильные методы отладки. Они обобщаются следующим pattern-ами:

занимают слишком много времени;
root-cause не обнаружен или никого не волнует в чём был root-cause;
исправление ухудшает качество ПО, несмотря на то, что оригинальный дефект исправлен.

Однако, это тема для отдельных обсуждений.

Источник: kodubets.ru