Зачем нужна отладка программы

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

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

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

Варварская отладка

Самый примитивный вариант отладки — добавить в код на JavaScript метод console.log(), поместив в скобки нужные данные для отладки. Console.log() — это просто способ вывести в консоль какой-нибудь текст.

Например, внутри функции можно сказать: console.log(‘Вызвана такая-то функция’) — и в нужный момент мы увидим, что функция вызвалась (или нет).

Минус этого подхода в том, что в коде появляется много отладочного мусора. А ещё, если мы не предусмотрели логирование для какой-то функции, то мы не поймаем в ней ошибку.

21. Отладка программ [Универсальный программист]

К счастью, помимо console.log() человечество изобрело много удобных инструментов отладки.

Что нужно для отладки

Для несложных проектов на JavaScript проще всего использовать встроенный отладчик в браузере Google Chrome. Единственное ограничение — он работает только с файлами скриптов, а не со встроенным в страницу кодом. Это значит, что если код скрипта находится внутри HTML-файла внутри тега , то отладка не сработает.

Чтобы открыть панель отладки в Chrome, нажимаем ⌘+⌥+I и переходим на вкладку Sources (Источники):

Открываем скрипт

Допустим, мы хотим посмотреть, как работает скрипт из задачи про выпечку и как он перебирает все варианты.

Всё, что у нас есть, — это код. Чтобы мы смогли его отладить, его нужно положить в отдельный файл скрипта, присоединить к HTML-документу и запустить в браузере.

Открываем любой текстовый редактор, например Sublime Text, вставляем код скрипта и сохраняем файл как temp.js. Имя может быть любым, а после точки всегда должно стоять js — так браузер поймёт, что перед нами скрипт.

После этого в новом файле вставляем шаблон пустой HTML-страницы и подключаем наш скрипт — добавляем в раздел такую строку:

Получиться должно что-то вроде такого:

Сохраняем этот код как HTML-файл, например index.html, и кладём в ту же папку, что и скрипт. Теперь заходим в папку и дважды щёлкаем по HTML-файлу, чтобы открыть эту страницу в браузере:

На странице ничего нет, но нам нужна не страница, а скрипт, поэтому находим слева наш файл temp.js и нажимаем на него — откроется код скрипта. Теперь можно начинать отладку:

Зачем нужна отладка по USB в Андроид? Как включить отладку по USB в Андроид?

Добавляем точки остановки

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

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

Брейкпоинт нужен для того, чтобы выполнить скрипт по шагам, начиная с первой команды. Чтобы его установить, нажимаем на номер строки с первой командой — в нашем случае это строка 2:

Обновим страницу и увидим, что скрипт начал работу и остановился. Но он остановился не на второй строке, а на шестой — всё потому, что это первая строка в скрипте, где происходит какое-то действие. Дело в том, что просто объявление новых переменных не влияет на работу скрипта, поэтому он ищет первую команду с действием. В нашем случае — это цикл for:

Пошаговая отладка

Чтобы посмотреть на работу скрипта по шагам, надо нажимать F9 или стрелку вправо с точкой на панели отладки:

Каждый раз, как мы будем нажимать F9 или эту кнопку, скрипт будет переходить к следующей команде, выполнять её и снова становиться на паузу:

Добавляем переменные для отслеживания

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

Чтобы добавить переменную и видеть её значение во время выполнения, в панели отладки в разделе Watch нажимаем плюсик, вводим имя переменной, выбираем её из списка и нажимаем энтер:

Теперь видно, что на этом шаге значение переменной a равно нулю:

Точно так же добавим остальные переменные: i, b, c. Так мы увидим, что первые два цикла только начались, а внутренний прошёл уже три итерации:

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

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

Отладка брейкпойнтами

Допустим, нам важно понять, в какой момент скрипт находит и выдаёт решение. Глядя в код, мы понимаем, что как только скрипт дошёл до команды console.log() — он нашёл очередное решение. Это значит, что мы можем поставить брейкпоинт только на эту строчку и не прогонять вручную весь скрипт: он сам остановится, когда дойдёт до неё, а мы сможем посмотреть значения переменных в этот момент.

1. Нажимаем снова на строку 2 и убираем предыдущую точку остановки.
2. Ставим брейкпоинт на строку 20 — там, где происходит вывод решения в консоль.
3. Нажимаем F8.

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

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

Зачем это всё

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

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

Веб-разработка — это новый чёрный

На базе веб-технологий делают всё — от сложного софта до высокобюджетных игр. Изучите технологии и начните карьеру в ИТ. Старт бесплатно. Попробуйте, вдруг вам понравится.

Источник: thecode.media

Как отладка поможет вам стать лучшим разработчиком

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

• Все, что может пойти не так, пойдет не так.
• Code smells (прим.ред. термин, обозначающий код с признаками (запахами) проблем в системе).

И единственное, что сможет противостоять этим горьким реалиям — это отладка.

Да, именно отладка. В начале своей карьеры никто (или почти никто) не питает особой любви к отладке. Зачастую она вызывает лишь разочарование и страх. Мы бы предпочли и дальше создавать крутые штуки (А кто не любит создавать крутые штуки!?), вместо того, чтобы часами корпеть над исправлением одной-единственной ошибки.

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

Истинная проблема отладки заключается в том, что она не поддается временным промежуткам. Вы можете примерно рассчитать, сколько времени уйдет на проектирование, разработку и т.д, но отладка “сделана из другого теста”. На процесс отладки может уйти час, день или даже неделя, но вы и на шаг не приблизитесь к обнаружению и устранению проблемы.

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

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

Сначала разберитесь с тем, как устроена система

Очень часто мы, первым делом, “понимаем как устроена проблема” и только потом “понимаем как устроена система”. Однако все должно быть наоборот.

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

Я заметил, что форма одновременно вызывается из двух мест в коде. При дальнейшем анализе я обнаружил, что проблема заключалась в вызывающем коде (calling code), а не в форме. Я решил проблему в один миг. Всего-то требовалось подправить одну незначительную деталь в другом месте.

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

Устраняйте каждую проблему по отдельности

Некоторое время назад я работал над большим SAP проектом по переносу данных (data migration). Дедлайн был на носу, работы было по горло, и в этот критический момент я столкнулся с проблемой под названием “Повреждение данных”.

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

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

Суть заключается в сужении поиска.

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

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

У “изоляции проблемы” есть множество преимуществ: вы можете сосредоточиться на вопросах, имеющих непосредственное отношение к проблеме; вы быстро справитесь с проблемой, потому что работаете с минимальным количеством кода.

Помните, что жуку (багу) трудно спрятаться, когда его убежище разрезают напополам.

За один раз изменяйте в коде только одну часть

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

Как вы будете себя чувствовать в такой ситуации? Думаю, вы будете задавать себе такой вопрос: “Что, черт возьми, происходит? Этот парень вообще знает, что делает?”

Плохая отладка работает точно так же.

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

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

Проверьте, действительно ли ваши действия исправили ошибку

Золотое правило отладки заключается в том, что, если вы не исправили проблему, она никуда не исчезла.

Все хотят верить в то, что ошибка просто исчезла. Человек несколько раз терпел неудачу, но потом что-то случилось и все его злоключения закончились. И, конечно, отсюда следует вывод: “Может этого больше никогда не повторится”. Повторится.

Извините, что разочаровываю, но в реальном мире не бывает чудес.

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

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

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

И наконец, ведите журнал технических решений

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

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

· Инициатор (кто зарегистрировал вызов)

· Номер телефона или добавочный номер инициатора #

· Текущее состояние (открыто, в процессе, закрыто)

· Дата следующего шага

· Дата окончания работы

· Запрос на разрешение проблемы, разработку #

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

Как сказал Ричард Паттис:

“При отладке новички добавляют код для исправления положения, а профессионалы удаляют неисправный код.”

• ТЭГИ
• Life Lessons
• Self Improvement

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