какой модуль помогает находить ошибки в коде программы
10 полезных советов для отладки и устранения неполадок в программировании
Новенький файл, открытый в текстовом редакторе, и ни одной написанной строчки кода…Каждый новый проект видится полным возможностей и перспектив…
Несколькими тысячами строк кода позже, тот же самый проект может оказаться отягощенным ошибками, из-за которых добавление новых функций становится головной болью, и падает энтузиазм программистов. Лучшие разработчики знают, как найти и устранить ошибки, и придерживаются лучших практик в разработке программного обеспечения, чтобы свести к минимуму, в первую очередь, возникновение ошибок.
Ваш набор инструментов для борьбы с ошибками
1. Оператор печати
Операторы печати – это самый быстрый, простой и непосредственный для программиста способ инспектирования значений данных и типов переменных. Правильно размещенные операторы печати позволяют программисту отслеживать поток данных на участке кода и быстро определять источник ошибки.
Не имеет значения, сколько передовых технологий используется, скромный оператор печати должен быть первым инструментом, к которому обращается программист, когда пытается отладить участок кода.
2. Отладчик
Отладчики исходного кода доводят метод отладки с помощью операторов печати до его логического завершения. Они позволяют программисту отследить по шагам выполнение кода строка за строкой и инспектировать все, что угодно, начиная от значений переменных и заканчивая состоянием виртуальной машины.
Большинство языков программирования имеют множество доступных отладчиков, которые предлагают различные возможности, включая графические интерфейсы, настройки точек останова для приостановки выполнения программы, и выполнение произвольного кода внутри среды исполнения.
3. Система отслеживания ошибок
Использование какой-либо системы отслеживания ошибок является жизненно важным условием для нетривиальных проектов по созданию программного обеспечения. Типичная ситуация, которая складывается, когда не используют систему отслеживания ошибок, такова: программисты вынуждены разбираться в старых е-мейлах или переписке в чате в поисках информации об ошибках, или того хуже — единственным хранилищем информации об ошибках является память программиста.
Когда такое случается, некоторые ошибки неизбежно остаются неисправленными, и что более важно, их труднее обнаружить и устранить другие, связанные с ними ошибки.
Простой текстовый файл может служить начальной системой отслеживания ошибок для проекта. С ростом объема кода количество ошибок выйдет за рамки текстового файла.
Существует большой выбор систем отслеживания ошибок в программном обеспечении, как коммерческих, так и с открытым исходным кодом. Самым важным критерием в выборе такой системы является доступность для сотрудников-непрограммистов, которым нужно работать с файлом ошибок.
4. Верификация программ
В некоторых языках программирования верификатор может проводить статический анализ кода для обнаружения проблемных мест до того, как код будет откомпилирован или выполнен, а в других языках верификатор полезен для проверки синтаксиса и стиля написания.
Исполнение программы верификации внутри редактора во время написания кода или прогон кода через верификатор до компиляции и выполнения помогает программистам находить и исправлять неисправности до того, как они переросли в ошибки в исполняемом программном обеспечении.
5. Контроль версий
Также как и использование системы отслеживания ошибок, применение системы контроля версии – это самая лучшая практика в разработке программного обеспечения, которая не может быть игнорирована при разработке любого проекта значительного размера.
Системы контроля версий играют ключевую роль еще и потому, что позволяют программистам откатить изменения до более ранней версии кода, просто возвратившись в состояние базы до появления ошибок, не допуская при этом других ошибок, за исправление которых пришлось бы дорого поплатиться.
6. Модульность
Плохо спроектированный код – это главный источник трудно исправляемых ошибок. Если код легко понять, и он может быть « выполнен » в уме или на бумаге, есть большая вероятность, что программисты смогут быстро находить и исправлять ошибки.
Самый лучший способ добиться этого – писать функции, выполняющие что-то одно. А вот участок кода с большим количеством функций имеет большую склонность к возникновению ошибок, которые сложно отслеживать.
Проектирование компонентов программного обеспечения, которые осуществляет только одну функцию, часто называется модульным дизайном. Модульность помогает программистам рассматривать системы программного обеспечения в двух измерениях. Во-первых, модульность создает уровень абстракции, позволяющий думать о модуле системы без понимания всех деталей его работы.
Например, программист, разрабатывающий систему электронной коммерции, мог бы, рассматривая модуль обработки кредитной карты, видеть, как он связан с остальным кодом, не вдаваясь в детали самой обработки кредитной карты. С другой стороны, детали модуля (в нашем примере того, который занимается обработкой кредитной карты) могут быть рассмотрены и поняты без обращения к не имеющему отношение к этому модулю коду.
7. Автоматизированные тесты
Модульные тесты и другие типы автоматизированных тестов идут рука об руку с модульным программированием.
Автоматизированный код – это участок кода, который выполняет программу с определенными входными параметрами и проверяет, соответствует ли поведение программы ожидаемому.
Модульные тесты проверяют функционирование отдельных функций или методов класса, в то время как функциональные тесты проверяют специфичное поведение всей программы, а интеграционные тесты проверяют большие части системы или всю систему в целом.
8. Метод «Плюшевый мишка» (или отладка «Резиновая уточка»)
Если верить легендам программирования Брайану Кернигану и Робу Пайку (Brain Kernighan и Rob Pike), отладка по типу «Резиновая уточка» возникла в университетском компьютерном центре, где студенты должны были садиться напротив плюшевого мишки и объяснять ему их ошибки, прежде чем обращаться за помощью к живому человеку.
Этот метод отладки оказался настолько эффективным, что быстро распространился во всем мире разработки программного обеспечения, и также как простой оператор печати, продолжает существовать по сей день, несмотря на то, что есть, казалось бы, более сложные инструменты. Практически все может заменить плюшевого мишку: резиновые уточки, как терпеливые слушатели, тоже пользуются спросом.
Важной частью этого метода является то, что нужно объяснять код и проблему вслух в простых и понятных терминах. Есть подобная методика, которая также полезна – вести журнал программирования, в который нужно записывать мысли о коде до и после его реализации.
9. Пишите комментарии к коду
Комментарии должны объяснять цель кода на низком уровне. Должна существовать возможность легко ответить на вопросы о том, что строка кода делает и как она это делает, прочитав сам код. Это достигается путем написания читаемого кода, который разработан настолько просто, насколько это возможно, и использует осмысленные имена для функций и переменных.
Комментарии к коду должны заполнять пробелы информации в максимально возможной степени, отвечая на такие вопросы, как: почему используется конкретная реализация, или как данный участок кода взаимодействует с остальной частью программы.
Написание хороших комментариев – это отличная практика разработки программного обеспечения даже в свободном от ошибок коде, но когда ошибки появляются, комментарии помогут сэкономить массу времени, затрачиваемого на понимание кода, написанного несколько дней, недель или даже месяцев назад.
10. Пишите документацию
В то время как комментарии описывают код на низком уровне, с точки зрения программиста, программная документация описывает функционирование всей системы в доступной для пользователей форме. В зависимости от типа разрабатываемого программного обеспечения, документация может описывать интерфейсы программирования, графические интерфейсы или рабочие процессы.
Написание документации демонстрирует понимание программной системы, и часто указывает на те части системы, которые не до конца понятны и являются вероятным источником ошибок.
На пути к мастерству: избавляемся от ошибок
Программирование – это, прежде всего, искусство. И также как для любого другого вида искусства, путь к мастерству в нем вымощен трудолюбием и стремлением учиться. Работа по изучению программирования никогда не заканчивается. Всегда есть что-то новое для изучения и новые способы по улучшению.
Какими из этих 10 средств отладки вы пользуетесь сейчас? Какими вы могли бы начать пользоваться с сегодняшнего дня? Какие из этих инструментов требуют времени на практику и освоения новых навыков?
Программисты пользуются преимуществом, которым только некоторые другие мастера могут когда-либо воспользоваться: самые лучшие инструменты и знания о программировании свободно и бесплатно доступны для всех, кто заинтересован в этом вопросе. Вы можете стать профи в отладке кода: все, что вы должны сделать для этого – просто взять инструменты по отладке и приступить к работе.
Как и какими средствами находить ошибки в коде Java?
При написании кода он, порой, не работает так, как я задумал или не работает в принципе. Я сижу и гадаю: что и где не так?
В итоге очень часто проблема мелкая: дурацкая опечатка, ошибка в синтаксисе и подобное. Профессионалом так не стать, если по каждой мелочёвке бегать по ресурсам. А я хочу им быть.
Вопрос: какие есть способы, чтобы найти ошибки в Java коде? Какие есть инструменты, методы, пути и пр.?
2 ответа 2
Вчера всё работало, а сегодня не работает / Код не работает как задумано
Debugging (Отладка)
В чем заключается процесс отладки? Что это такое?
Процесс отладки состоит в том, что мы останавливаем выполнения скрипта в любом месте, смотрим, что находится в переменных, в функциях, анализируем и переходим в другие места; ищем те места, где поведение отклоняется от правильного.
Заметка: Отладка производится как правило в IDE (Интегрированная среда разработки). Что это такое можно чуть подробнее ознакомиться в вопросе
Какие есть способы предупреждения ошибок, их нахождения и устранения?
В данном случае будет рассмотрен пример с Intellij IDEA, но отладить код можно и в любой другой IDE.
Подготовка
Достаточно иметь в наличии IDE, например Intellij IDEA
Запуск
Отладка запускается сочетанием Shift+F9 или выбором в верхнем меню Run → Debug или нажатием зеленого «жучка»:
В данном случае, т.к. функция вызывается сразу на той же странице, то при нажатии кнопки Debug — отладчик моментально вызовет метод, выполнение «заморозится» на первом же брейкпойнте. В ином случае, для активации требуется исполнить действие, при котором произойдет исполнение нужного участка кода (клик на кнопку в UI, передача POST запроса с данными и прочие другие действия)
Процесс
Для самого процесса используются элементы управления (см. изображение выше, выделено зеленым прямоугольником) и немного из дополнительно (см. изображение выше, выделено оранжевым прямоугольником)
Show Execution Point ( Alt+F10 ) — переносит в файл и текущую линию отлаживаемого скрипта. Например если файлов много, решили посмотреть что в других вкладках, а потом забыли где у вас отладка 🙂
Step Over ( F8 ) — делает один шаг не заходя внутрь функции. Т.е. если на текущей линии есть какая-то функция, а не просто переменная со значением, то при клике данной кнопки, отладчик не будет заходить внутрь неё.
Step Into ( F7 ) — делает шаг. Но в отличие от предыдущей, если есть вложенный вызов (например функция), то заходит внутрь неё.
Step Out ( Shift+F8 ) — выполняет команды до завершения текущей функции. Удобна, если случайно вошли во вложенный вызов и нужно быстро из него выйти, не завершая при этом отладку.
Rerun ( Ctrl+F5 ) — Перезапустить отладку
Resume Program( F9 ) — Продолжает выполнения скрипта с текущего момента. Если больше нет других точек останова, то отладка заканчивается и скрипт продолжает работу. В ином случае работа прерывается на следующей точке останова.
Stop ( Ctrl+F2 ) — Завершить отладку
View Breakpoints ( Ctrl+Shift+F8 ) — Посмотреть все установленные брейкпойнты
Mute Breakpoints — Отключить брейкпойнты.
Итак, в текущем коде видно значение входного параметра:
Если нажмем F8 2 раза, то окажемся на строке 27; во вкладках Watches и Variables и в самой странице с кодом увидим, что переменная sum была инициализирована и значение равно 0, а также nums инициализирована и в ней лежит массив целых чисел <23, 24, 11, 18>.
Дальнейшие нажатия F8 переместит линию кода на строки 31, 32 и, наконец, 36.
Дополнительно
Если нажать на View Breakpoints в левой панели, то можно не только посмотреть все брейкпойнты, но в появившемся окно можно еще более тонко настроить условие, при котором на данной отметке надо остановиться. В методе выше, например, нужно остановиться только когда sum превысит значение 20.
Это удобно, если останов нужен только при определённом значении, а не всегда (особенно в случае с циклами).
ТОП-10 бесплатных программ для отслеживания багов/ошибок кода
Отслеживание ошибок – важное дело. При разработке программного обеспечения ошибки неизбежны. Однако, когда вы сталкиваетесь с одной ошибкой, это часто означает, что в коде есть какие-то проблемы.
Чтобы помочь сократить ИТ-расходы, мы выбрали десять бесплатных программных решений для отслеживания ошибок с открытым исходным кодом, которые помогут любой команде отслеживать проблемы без каких-либо затрат.
10 бесплатных программ для отслеживания ошибок с открытым исходным кодом
Некоторые бесплатные системы имеют ограничения по количеству пользователей или проектов, которые можно присоединить к ней. Для небольших команд это не проблема. Но, вероятно, не будет иметь смысла для более крупных команд или компаний, работающих одновременно над несколькими клиентскими проектами, то такие ограничения перечислены, чтоб знать о них заранее.
Параметры, которые применялись при отборе программного обеспечения:
1. Pivotal Tracker
Меню настроек и бэклог в Pivotal Tracker ( Source )
Система также интегрируется с GitHub, поэтому можно отслеживать код во всем проекте.
Пользователям Pivotal Tracker нравится, тем что панели инструментов программы дают им хорошую видимость проектов как в усечённом малом, так и в большом масштабе. Многие считают, что система проста в использовании, но некоторые пользователи отметили, что системой становится сложно пользоваться, если они отслеживают сразу несколько проектов.
Ограничения бесплатной версии:
Стоимость обновления: самая низкая цена платной версии Pivotal Tracker составляет 12,50 долларов США в месяц для пяти пользователей, пяти проектов и 5 ГБ памяти.
2. Redmine
Список проблем в Redmine
Если просто ищете отслеживание ошибок, то Redmine может дать намного больше, чем рассчитывали. Можно использовать гибкость настраиваемого интерфейса и множество доступных плагинов для адаптации системы к потребностям команды.
Пользователи Redmine обнаружили, что базовая версия программы проста в применении и довольно интуитивна в использовании. При установке плагинов и расширении с помощью модулей можно повысить функциональность программного обеспечения. Хотя это может сделать систему сложной в использовании. Однако, без плагинов и настроек, интерфейс кажется устаревшим и неуклюжим.
3. Bugzilla
Список ошибок в Bugzilla
Система работает на MySQL, PostgreSQL и Oracle и требует установки Perl.
4. MantisBT
Сводка панели в MantisBT
MantisBT построен на PHP и совместим с базами данных MySQL и PostgreSQL. Он обычно используется в качестве отслеживания ошибок, но его можно настроить для управления более крупными проектами.
MantisBT предлагает управление доступом, которое можно изменить для каждого проекта; настраиваемые поля проблем, уведомления и рабочие процессы, надстройку с оптимизированным мобильным интерфейсом, если команде нужен мобильный доступ.
Пользователи обнаружили, что MantisBT достаточно прост для опытного программиста, но отметили, что менее опытному разработчику может потребоваться некоторое обучение. Они также отметили, что, хотя интерфейс MantisBT устарел, он по-прежнему предлагает все основные функции, которые команда разработчиков программного обеспечения должна отслеживать и иметь возможность исправлять ошибки.
Основной инструмент при поиске ошибок в коде
Данная статья рассчитана на начинающих, однако, определённый опыт программирования уже надо иметь. И мне хотелось бы рассказать об одном потрясающем инструменте поиска ошибок. Имееются ввиду те ошибки, которые связаны с алгоритмом, а не с синтаксисом (забыли точку с запятой, не закрыли кавычки, скобки и так далее). Вот в этой статье я расскажу о своём (да и любого другого, кто уже давно программирует) основном инструменте поиска ошибок в коде.
Итак, давайте определимся, какие же ошибки мы будем искать. Допустим, мы написали функцию, цель которой складывать два числа и возвращать результат. Давайте её напишем (в коде специально сделана ошибка):
В результате, мы видим, что у нас вывелось 5, хотя мы хотели увидеть 9 (5 + 4). Данный код очень простой, поэтому, конечно, здесь Вы легко сразу обнаружите ошибку. Однако, данный пример является не более, чем примером. Его задача рассказать о механизме поиска ошибок в алгоритме. Так вот, мы должны выяснить, на каком шаге происходит ошибка. И это делается с помощью просмотра значения переменных на каждом шаге. Вот пример того, что нужно делать, чтобы найти ошибку:
Далее мы анализируем каждый вывод переменной:
Дальше идёт return, следовательно, ошибка именно в этой строке. До неё всё шло прекрасно, следовательно, внимательно приглядываемся к этой строке и видим, что вместо того, чтобы возвращать значение переменной sum, мы возвращаем переменную x.
Итак, подведём итог. Основным инструментом поиска ошибок является оператор echo (либо функция print_r(), если переменная является массивом). Всё, что нужно, это просто смотреть на необходимую переменную на каждом шаге алгоритма. И понять, на каком моменте возникает ошибка. Если, допустим, ничего вообще не выводится, то это значит, что функция даже не вызывается. Следовательно, ищем ошибку там, где она должна была вызваться.
Данный подход к устранению ошибок в алгоритме я использую постоянно, нет ни одной программы (скрипта), разве что совсем простого, где я бы данный подход не использовал. Более того, данный подход является универсальным и подходит для других языков тоже. Поэтому его надо освоить Вам в самые кратчайщие сроки, чего я Вам искренне и желаю.
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Комментарии ( 0 ):
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Copyright © 2010-2021 Русаков Михаил Юрьевич. Все права защищены.
Последовательность поиска ошибки в программе ПЛК
Введение
Достаточно часто в литературе мне попадались описания ошибок и даже классификации их по типам.
Хотя, признаться, у меня не получается толком вспомнить ни одного случая, когда мне бы помогло знание того, к какому именно типу относится конкретная ошибка. Разве что уже после выяснения причин, для обьяснения их окружающим.
А вот как люди вычисляли место и докапывались до сути ошибки — мне всегда было интересно.
Сведения о системе и ошибке
С компьютера на ПЛК подаются уставки (времена, флаги режимов) и команды на устройство.
Из ПЛК на компьютер выдаются сигналы статуса устройства и времени до конца команды на это устройство. Сигналы пакуются в слова, для минимизации объемов приема и передачи.
Из ПЛК на устройство выдаются команды.
Устройство выдает на ПЛК свои статусы.
Изначально все работало, но через какое-то время при подаче команд, статусы на компьютере в SCADA начали моргать не по делу и вообще вести себя крайне недружелюбно. Причем только в одном месте, на одном объекте.
Но «танцы с саблями» появлялись стабильно, при каждой команде, что очень порадовало.
Поиск
Цифрами в круглых скобках показаны места проверок, соответствующие цифрам на схеме ниже.
Принципов и зависимостей моргания понять сходу не удается. Возможно из-за усталости, возможно по причине отсутствия таковых.
Было установлено, что ошибка присутствует не только в SCADA (1) (там, где она собственно была обнаружена), но и в OPC сервере (2).
Дальнейший разбор показал, что ошибка присутствует и в ПЛК, как минимум в слове, формируемом для компьютера (3).
Проверка наличия ошибки в статусе, приходящем от устройства – отметает устройство, как возможный источник проблемы.
Изменения статуса от устройства вручную ничего не меняют. При изменении статуса от устройства форсированием (принудительно, постоянно) ошибка все равно сохраняется.
Соответственно это и не импульсы, которых не видно при мониторинге (4).
Сравнение с кодами других объектов, на которых этой ошибки нет – различий не выдает. Полная идентичность. Вероятность ошибки в программе ПЛК уменьшается (5).
Отключается компьютер, как возможный источник ошибки, записывающий что-то в данную область памяти. Ошибка сохраняется. Вероятность ошибки из-за компьютера стремится к нулю. Соответственно, не смотря ни на что, проблема все-таки в ПЛК (6).
Ремарка: Также можно было, отключив ПЛК, руками менять статусы в OPC. Но такой вариант был сложнее технически, а в целом эти две проверки практически равнозначны.
Перенесение слова статуса, передаваемого из ПЛК на компьютер, в другую область памяти ПЛК ничего не дает. Ошибка сохраняется.
Перенесение куска кода с ошибкой в другой блок (условно функцию) тоже не влияет на ошибку. Соответственно вероятность того, что это влияет какая-то еще посторонняя команда, пишущая туда-же что-то свое – незначительна. Дело в этом куске.
Удаляется таймер. Команда не сбрасывается, но ошибка пропадает и статусы перестают прыгать.
Взамен вставляется новый таймер. Тщательно осматривается на предмет нелепостей. Таймер самый заурядный, ничего необычного. Таких в программе еще штук 200. Но ошибка появляется (8)
Вроде ничего необычного, причем полностью идентичная система работает с десятками идентичных устройств вокруг. Мозг скрипит и отказывается помогать.
После разбора — ситуация становится окончательно понятной.
Причина ошибки:
Операторы увеличили стандартное время таймаута с 1,5 до 10 минут.
И если 1,5 минуты это 90 секунд, то 10 минут это 600 секунд.
600 секунд не влезали в младший байт (максимум 256), и часть времени писалась в старший.
Суть последней проверки:
При записи сначала времени, и лишь затем статуса – статус забивал биты переполнения, приходившие от значения времени. А при обратной последовательности команд, время наоборот забивало своими битами статус.
Решение:
Время и статусы были разбиты на 2 слова. Местным инженерам было предложено провести техобслуживание или заменить устройство с таймаутом, превышающим стандартное время более чем в 5 раз.
И они работали они долго и счастливо, и сломались в один день.
Выводы
Описанная ошибка не особо сложна, но по-моему довольно симпатична с точки зрения показательности.
По сути не очень важно, где именно ищется ошибка — в электронике, в ПЛК, на компьютере или где-то еще. Общие принципы всегда примерно одинаковы:
Хотя разумеется рецепты для одних ситуаций могут быть совершенно бесполезны по отношению другим.
Но у всех ошибок есть конкретная причина, и эту причину всегда можно выяснить.
Например как-то причиной был тракторист с бороной, проехавшийся над кабелем. И хотя сложностей в ее устранении не возникло, их хватило в процессе написания рекомендации, для избежания повторов…
Извиняюсь за вероятную сложность чтения.
Тема не очень художественная, плюс к этому попытался сократить, пропуская не очень существенные моменты, вроде вынужденного отказа от BreakPoint’ов, из-за цикличности выполнения программы в ПЛК и наличия таймера.