Что такое дебажить код

17 выражений, которые понимают только айтишники

Означает всего лишь «поручить задание». Фраза произошла от английских слов to assign — назначать, поручать и task — задача. В ИТ‑сфере речь обычно идёт о распределении рабочих дел между сотрудниками в специальной программе‑менеджере.

• Пример употребления:Коллеги, на меня ничего не асайнить, уже вагон тасков в работе.

2. Дебажить код

Дебажить — это антоним к слову «бодяжить». Шутка! «Дебажить» значит проверять программный код на ошибки. Разработчик запускает режим отладки и ищет «баги», от английского bug — технический дефект. Кстати, ещё bug означает «жук» и «жучок» (для прослушивания). Соответственно, глагол to debug — избавиться от дефектов.

• Пример употребления:Если в том таске надо ещё и дебажить — на меня точно не асайнить!

Даже если вы не разбираетесь во всех этих тасках и багах, но знаете английский, сможете интуитивно понимать, о чём идёт речь. Ну а если хотите работать в ИТ — без языка точно никак. Быстро улучшить свой английский можно в онлайн‑школе Skyeng. Там вы работаете один на один с преподавателем и разговариваете в два раза больше него — 60% урока. Заниматься можно с телефона в любое время дня и ночи.

3. Зарелизить/задеплоить

Термины происходят от английских слов to release — выпускать и to deploy — приводить в действие, разворачивать. В ИТ‑сфере эти слова часто употребляются как синонимы и означают выпуск новой версии программы. Но некоторые специалисты их различают: «зарелизить» применяется, когда программа начинает быть доступна пользователям, а «задеплоить» — когда она переходит в любую другую среду, например переносится в тестовую систему или на другой сервер.

• Пример употребления:
  — Уже зарелизили новую программу?
  — Ещё нет, пока только задеплоили в тест и ждём ответа.

4. Зааджастить прогу

«Прога» говорят не только айтишники, но на всякий случай уточним, что это сокращение от слова «программа». «Зааджастить» возникло от глагола to adjust — приводить в порядок, регулировать. Айтишники говорят так, когда нужно немного поменять логику программы, слегка что‑то донастроить.

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

5. Зафейлить/зафакапить

Fail и fuck up — это что‑то типа русского слова «косяк» разной степени интенсивности. Зафейлить — не справиться с чем‑то, совершить ошибку. Зафакапить — полностью провалить что‑то, например вообще не прислать выполненную задачу к сроку.

• Пример употребления:Мы уже профакапили все сроки, а в проге ещё куча багов!

6. Черрипикнуть хотфикс

Хотфикс — это прямая транслитерация слова hotfix. Hot — горячий или горящий по срокам, fix — исправление, починка. Например, когда в программе обнаружился баг, который сильно всё ломает, — нужно его молниеносно починить, то есть сделать хотфикс. Чтобы применить только новые изменения, не трогая остальных частей программы, есть операция cherry pick — что‑то типа выборочного переноса.

• Пример употребления:Черрипикните уже этот хотфикс, иначе нас всех уволят!

Чтобы быстрее справляться с хотфиксами и черрипиками, учите английский. Тогда не придётся ломать голову над непонятными словами в коде и всё мучительно гуглить. Чтобы записывать новую лексику в личный словарик прямо с экрана, установите расширение для браузера Vimbox Translate. Оно синхронизируется с мобильным приложением Skyeng и помогает вам быстрее запоминать слова.

7. Тэдэшка

Это милое слово происходит от аббревиатуры TD, которая расшифровывается как technical documentation. Это документ, где описаны логика и функциональность программы. Неудивительно, что айтишники сократили название: было бы жутко неудобно каждый раз говорить «техническая документация».

• Пример употребления:Мы не виноваты, что клиенту не нравится. Этих требований не было в тэдэшке.

8. Отревьюить доку/код

Глагол to review значит «оставлять рецензию», а загадочная «дока» — это всего лишь документ. «Отревьюить доку» может значить оставить комментарии в общем документе или просто дать своё мнение по поводу него. Ещё айтишники часто говорят «отревьюить код». Это когда опытные программеры смотрят разработки новичков.

• Пример употребления:Я жутко нервничаю, завтра мой код будет ревьюить вся команда.

9. Дрова полетели

Речь идёт не о летающих досках, а о сломавшихся программах. «Дрова» — это drivers, или драйверы. В корне слова английский глагол to drive, что, помимо известного всем «водить», означает ещё и «управлять». Так называют программное обеспечение, которое управляет другими устройствами. Например, чтобы ваш компьютер мог работать с принтером, нужно установить специальные драйверы. Но если вдруг они «полетят» — всё перестанет работать.

• Пример употребления:У меня весь экран в битых пикселях, похоже, дрова видеокарты полетели.

10. Апликуха

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

• Пример употребления:После последнего релиза апликуха стала работать в два раза медленнее.

11. Забэкапить

Жизнь этому слову дал английский глагол to back up — делать резервную копию. Кстати, это не только удел айтишников, вы и сами наверняка много раз бэкапили информацию. Например, когда записывали важные фотографии на внешний жёсткий диск, боясь, что они пропадут, если компьютер сломается.

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

12. Кракозябры

Нечитаемый набор символов. Например, когда при запуске программы на экран выводится какая‑то бессмыслица из математических знаков и случайных букв. Есть мнение, что на это слово повлияло английское crack — разлом, трещина. Другие говорят, что это смесь «крокодила» и «зебры».

• Пример употребления:Открываю твою программу, а там кракозябры. Проверь кодировку.

13. Имплементить

Произошло от английского to implement — внедрять, осуществлять. Так программисты говорят о реализации какого‑то функционала. По сути, это всего лишь синоним глагола «делать».

• Пример употребления:Сегодня не успею всё заимплементить, доделаю завтра.

14. Пушить

И снова английский глагол. To push означает не только «толкать», но и «заставлять, принуждать». Так говорят, когда на кого‑то давят, чтобы, например, ускорить работу.

• Пример употребления:
  — Программа уже готова? Время идёт!
  — Вот только не надо меня пушить!

Мы не хотим вас пушить, но попробуйте позаниматься в Skyeng, чтобы лучше ориентироваться в английском и понимать сленг. Онлайн‑школа даже имплементнула специальное предложение для читателей Лайфхакера. По промокоду PUSHME у вас будет целых четыре бесплатных урока при покупке любого курса Skyeng. Промокод действует до 15.10.2019.

15. Дропнуть базу

To drop — уронить или прекратить что‑то делать. Но в ИТ‑сленге речь обычно идёт об удалении. Если слышите выражение «дропнуть базу», знайте, что эти люди собираются удалить базу данных.

• Пример употребления:Давайте дропнем старую базу, что она зря место занимает.

16. Забукать

Никак не связано с запоем. Слово происходит от to book — бронировать. Айтишники букают комнаты для переговоров или авиабилеты. Кстати, программисты из немецких компаний говорят «забухать» (с ударением на «у»). Это от немецкого глагола buchen (бухен), который тоже значит «бронировать».

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

17. Батон/батончик

Спросите обычного человечка, какие бывают батоны, и он скажет: столичный, нарезной, к завтраку. Спросите айтишника, и, скорее всего, в первую очередь он подумает про радиобатоны и пуш‑батоны. Дело в том, что на ИТ‑сленге батонами называют кнопки. Разумеется, от английского button — кнопка. Некоторые говорят ближе к оригиналу — «б а ттон», а другие попросту называют кнопки батончиками.

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

Мы тут зашифровали ещё парочку фраз из сленга программистов на обложке��. Угадывайте и пишите в комментариях. Знаете другие айтишные словечки? Добавляйте их тоже!

Как дебажить фронтенд и бекенд: пошаговая инструкция

Очень много сервисов сейчас позволяют дебажить код над фронтенде. Chrome DevTools и Firefox Developer Tools среди них самые популярные, но и в других браузерах тоже есть свои тулзы. Мы будем использовать Chrome DevTools для примеров.

Дебажим JavaScript

Откровенно говоря, отладка кода может занимать много времени. Особенно, если использовать такие простые команды как console.log() или window.alert().

Нужно писать, а потом удалять дополнительный код, а иногда эти команды все равно попадают в коммит (даже если вы думали, что все их забрали). А если при этом использовать линты (статические отладчики), то команды console или alert будут подсвечиваться в коде.

И на этом моменте в игру вступает Chrome DevTools, позволяя нам дебажить код без утомительных команд. Среди фишек этой тулзы, редактирование CSS и HTML, тестирование сети и проверка скорости сайта — наши любимые.

Чтобы на практике познакомиться с этой тулзой, давайте создадим простенькую страничку на JavaScript с getData() методом. Этот метод будет просто собирать данные с поля ввода, создавать DOM элемент с dataSpan ID и добавлять значение с поля ввода в этот элемент.

Вот как наша страничка будет выглядеть:

В JavaScript:

Сохраним ее как app.js.

Вот как наша страничка будет выглядеть в браузере:

Чтобы проверить как метод работает до того, как сохранять данные в dataSpan, можно использовать старомодные console.log(data) или window.alert(data). Вот что мы увидим запустив файл в VS Code:

Это самый примитивный подход.

Вместо этого, мы используем брейкпоинты (точки останова) вChrome DevTools чтобы убедиться, что все работает как надо.

Брейкпоинт — это строка кода, на которой мы хотим приостановить прогонку кода, чтобы изучить как он работает (или не работает).

Возвращаясь к примеру, давайте запустим страницу в Google Chrome и сделаем следующее:

1. Чтобы открыть Chrome Developer Tools, в правом верхнем углу браузера, кликнем чтобы открыть меню настроек.
2. В этом меню, выберем Дополнительные инструменты (в английском меню — More tools), а потом Инструменты разработчика (Developer tools).

Открыв панель инструментов разработчика, давайте приостановим код на брейкпоинте:

1. Выберите вкладку Sources.
2. В Sources, в панели Page, выберите app.js (который мы создали чуть раньше).
3. В редакторе кода, кликните на номер строки let data =document.getElementById(‘name’).value;

Управление интервалами выполнения кода

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

Первая кнопка, Resume script execution () продолжит выполнение кода до конца или до следующего брейкпоинта.

Давайте введем hello world в поле ввода. В строку добавится data = “hello world”. Теперь давайте кликнем на кнопку Step over next function call ().

Выбранная строка с брейкпоинтом будет выполнена и дебаггер выберет следующую. Откройте вкладку Scope чтобы посмотреть значение переменной data. Оно изменилось на “hello world”, которое мы ввели ранее и просто показывает значение нашей переменной на конкретной строке кода. Кликните Step over next function call еще раз чтобы выполнить выбранный метод и перейти на следующую строку.

Если обновить страницу, значение переменной out также обновится в DOM элементе. Чтобы посмотреть значение переменной, можно кликнуть на Expand () слева от нее. Если же еще раз кликнуть Step over next function call, то текст “hello world” еще раз добавится в dataSpan.

Более сложная отладка

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

Для этого мы обновим код app.js как на скриншоте выше. Обновляем страницу и приступаем непосредственно к дебаггингу.

1. Кликните 3 (номер строки of let data = document.getElementById(‘name’).value;) чтобы поставить брейкпоинт.
2. Введите 23 24 е в строке ввода в браузере.
3. Кликните Step over next function call.

Как еще можно поставить брейкпоинты

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

Для этого в DevTools есть классный инструмент для установки брейкпоинтов на разные типы интеракции с браузером. На панели JavaScript Debugging, кликните Event Listener Breakpoints чтобы посмотреть доступные категории.

Как вы видите, можно поставить брейкпоинт на событие Mouse > click (клик мышкой) в любом месте нашего кода. Это означает, что, если кликнуть Get Input Data, выполнение кода остановится на событии onclick. И не нужно вручную ничего добавлять.

Клик на Step over next function call будет последовательно вести нас через код, используемый чтобы обработать клики.

Используя Event Listener Breakpoints, можно поставить брейкпоинты на кучу разных типов событий, таких как Keyboard, Touch, и XHR.

Ключевое слово “debugger”

Если ввести debugger в любом месте кода, Chrome DevTools приостановит выполнение кода на этой строке и подсветит ее также, как и брейкпоинты. Можно использовать этот инструмент чтобы дебажить JavaScript в Chrome или других браузерах. Только не забудьте удалить его, когда закончите отладку.

Код на скриншоте выше остановится на строке, которая содержит ключевое слово ​debugger и автоматически запустит Chrome DevTools. По сути, это то же самое, что и поставить брейкпоинт на эту строку. Также выполнением кода можно управлять с помощью кнопок ​Step into next function call и Step over next function call.

Выжимка

В начале мы рассмотрели команды console.log() и window.alert() и поняли, что они не слишком удобны. Нужно было их часто использовать по всему коду, что могло сделать код «тяжелее» и медленнее, если бы мы забыли их удалить перед коммитом.

Когда количество строк растет, Chrome Developer Tools намного более эффективен для отлова багов и оценки работы в целом.

Дебажим Angular

Легче всего отладить код Angular — использовать Visual Studio Code (VS Code). Чтобы начать дебаггинг, вам нужно будет установить расширение Debugger для Chrome:

1. Запустите проект на VS Code и откройте вкладку Extensions. Или нажмите Ctrl+Shift+X на клаве.
2. В строке поиска введите Chrome.
3. Выберите Debugger for Chrome и кликните Install.
4. После того как установите расширение, появится кнопка Reload. Кликните ее, чтобы завершить инсталляцию и активировать Debugger.

Точно так же, как и в DevTools, кликните на номер строки в app.component.ts. Строка с брейкпоинтом подсветится красным кружком (слева от номера строки).

Настраиваем дебаггер

Для начала, нам нужно будет настроить дебаггер:

1. С File Explorer перейдите на Debug вкладку.
Также можно использовать для этого Ctrl+Shift+D.

2. Кликните на иконку Settings чтобы создать launch.json.
Это файл с настройками, который мы будем использовать.

3. С выпадающего меню Select Environment выберите Chrome.
Это создаст новую папку .vscode и файл launch.json для вашего проекта.

4. Запустите этот файл.

5. Чтобы использовать этот файл для наших целей, в методе url замените localhost порт с 8080 на 4200.

6. Сохраните изменения.

Вот как должен выглядеть файл:

7. Нажмите F5 или кликните кнопку Start Debugging чтобы запустить Debugger.

8. Запустите Chrome.

9. Чтобы приостановить выполнение кода на брейкпоинте, обновите страницу.

Чтобы последовательно просмотреть выполнение кода и как меняются переменные, используйте клавишу F10.

README

В расширении Debugger для Chrome есть множество дополнительных конфигураций, работа з source maps и устранений всяческих неполадок. Чтобы просмотреть их прямо в VS Code, кликните на расширение и выберите вкладку Details.

Отладка бекенда (Node.js)

Здесь вы узнаете как дебажить код на Node.js. Вот самые распространённые подходы:

• Используя Chrome DevTools
На даный момент, это наш любимый подход.

• Используя IDE-шки типаVisual Studio Code, Visual Studio, WebStorm, и т.д.

Для примеров мы будем использовать VS Code и Chrome DevTools.

Chrome и Node.js используют тот же JavaScript-движок, Google V8, и это значит, что для бекенда мы будем использовать те же инструменты, что и для фронта.

1. Запустите свой проект в VS Code.

2. Перейдите на вкладку Console.

3. Введите команду npm start —inspect и нажмите Enter.

4. Проигнорируйте предлагаемый “chrome-devtools://…” URL (существует метод получше).

5. Запустите Chrome и введите “about:inspect”.

Это перенаправит вас на вкладку Devices на DevTools.

6. Кликните линк Open dedicated DevTools for Node.

Процесс отладки такой же, как и для фронтенда, то есть с использованием брейкпоинтов. На самом деле, очень удобно то, что не нужно переключаться на IDE. Таким образом, можно дебажить и фронт- и бекенд на одном интерфейсе.

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

Как дебажить программу

3+) Если не работает, то дебажить, пока не заработает на всех тестах.

1. Потестировать в тестирующей системе

4+) Если не работает, то придумывать тест, на котором не работает на своем компьютере. Если не находится — напишите стресс-тестирование

4++) Если все работает — внимательно читать код, добавить проверки в опасные места, перечитывать условие задачи, пока не найдете место, где либо вы не поняли задачу, либо ваша программа работает по-разному у вас и на сервере

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

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

Про первый пункт советов не будет 🙁 Разве что совет, что придумать решение необходимо ДО того, как писать код.

Что делать, пока пишешь код

Проследите путь каждой переменной и каждого цикла

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

Также и для каждого цикла нужно понимать * какая будет первая итерация * в какой момент он закончится * сколько всего будет итераций * нет ли где-то выхода за границы массива

Пишите по кодстайлу

• ставьте отступы
• ставьте пробелы вокруг арифметических знаков
• пишите понятные, и главное, мало похожие друг на друга названия переменных
• делите программу на логические части (про это подробнее следующий совет)
• Изучите подробности общепринятого кодстайл: TODO: ВСТАВИТЬ ССЫЛКУ НА КАКОЙ-НИБУДЬ КОДСТАЙЛ

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

Делите код на функции как можно более сильно

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

Вот пример, когда в программе без функций найти ошибку тяжело: (код Сережи Карпышева)

Если ты — не Сережа Карпышев в октябре 2017 года, то этот код тебе отдебажить будет очень тяжело. Что здесь можно сделать для увеличения понятности кода: * Структура Point вместо пары чисел x1, y1 * Cчитывание точки происходит 4 раза, удобно сделать для этого функцию или переопределить оператор >> * Вектор разности двух точек считается где-то 6 раз, удобно сделать для этого функцию * Векторное произведение двух векторо считается 6 раз, удобно сделать для этого функцию * Проверку на параллельность двух векторов удобно вынести в отдельную функцию * Координаты прямой a, b, c удобно вынести в отдельную функцию, считающую их по двум точкам * Возможно даже структура Line вместо тройки чисел a, b, c * Координаты пересечения двух прямых удобно считать через функцию от двух прямых, и работать там только с их координатами

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

Как дебажить, если знаешь тест, на котором не работает

TODO описать процесс и виды дебага

Самые частые ошибки, если у вас все работает, а в тестирующей системе нет

Выход за границы массива

Если у вас ошибка, особенно на C++ — это почти всегда выход за границы массива. Когда вы обращаетесь на C++ к элементу в массиве/векторе, которого не существует, ваша программа по стандарту C++ может сделать все, что угодно (хоть отформатировать диск, но вряд ли такое будет :D). Такая штука называется undefined behaviour.

Обычно при запросе к несуществующему элементу массива просто возвращается число из тех битов, которые лежат на том месте в памяти. У вас на компьютере там может быть 0, а на informatics — какое угодно другое число.

Поэтому: * C++ чаще всего не видит эту ошибку и работает дальше. * Ваша программа может работать по-разному у вас и на сервере.

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

Слишком маленький тип данных

Нужно знать, что * int содержит числа примерно от \(-2 * 10^9\) до \(2 * 10^9\) * unsigned int содержит числа примерно от \(0\) до \(4 * 10^9\) * long long содержит числа примерно от \(-9 * 10^18\) до \(9 * 10^18\) * unsigned long long содержит числа примерно от \(0\) до \(18 * 10^18\)

И всегда проверять, что когда вы * складываете * умножаете * вычитаете

числа, они все еще помещаются в выбранный вами тип.

Например, в задаче про быстрое возведение в степень, по условию гарантируется, что \(x, N, P \leq 2 * 10^9.\) Это значит, что в тип int они влезут.

НО! В ходе алгоритма вы иногда умножаете два числа. При этом, если вы все делаете правильно, вы работаете всегда только с ОСТАТКАМИ по модулю \(P\) , а значит с числами до \(2 * 10^9\) . Чтобы ПЕРЕМНОЖИТЬ два таких числа, они должны быть типа long long, иначе произведение двух int-ов будет до \(4 * 10^18\) , что в int не влезает, произойдет переполнение. Поэтому в этой задаче обязательно нужно использовать long long, и не забывать брать после каждого действия по модулю.

Крайние случаи

Если вам дана задача и ограчение \(0 <= N <= 10^6\) , и вы убедились, что программа работает верно для каких-нибудь \(3, 5, 20\) , то это может значить, что программа работает, но не на всех \(N\) . Например, для \(N = 0\) может быть какой-то отдельный случай, когда решение не работает. То же самое и для \(N = 1, 2\) . А для \(N = 10^6\) может быть проблема с тем, что она не влезает в память или что-нибудь переполняется (как в пункте 2). Если у вас WA на каком-то тесте, а у вас “на компе все работает”, то начинайте искать тест, на котором и у вас не работает. И в первую очередь смотрите на крайние значения. Если в задаче не одно \(N\) , а много сложных входных данных, то придумайте самую стрёмную ситуацию, которую сможете, и проверьте, работает ли ваша программа на ней. Если вам повезет — вы найдете тест, на котором она не работает.

Вы решаете не ту задачу

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

Стресс-тестирование

Но если вы достаточно много тестировали свою задачу, то вам может помочь стресс-тестирование

Debug в Intellij IDEA: гайд для новичков

Всем привет, JavaRush сообщество. Сегодня поговорим о дебаге: что это такое и как дебажить в Intellij IDEA. Статья рассчитана на людей, у которых есть уже минимальные знания Java Core. Здесь не будет ни фреймворков, ни сложных процессов публикации библиотек. Легкая прогулка. Так что располагайтесь поудобнее — начнем!

Почему Debug тебе необходим

Давайте сразу проясним для себя: кода без багов не бывает… Так устроена жизнь. Поэтому не стоит сразу раскисать и бросать все, если код работает не так, как мы ожидали. Но что же делать? Конечно, можно наставить System.out.println везде, где только можно и потом разгребать вывод в терминале в надежде на то, что получится найти ошибку. Все-таки можно… и это делают, и делают аккуратно при помощи логирования (можно почитать об этом здесь). Но если есть возможность запустить на локальной машине код, лучше использовать Debug . Сразу хочу заметить, что в этой статье мы будем рассматривать дебаг проекта внутри Intellij IDEA. Если интересно почитать об удаленном дебаге — вот, пожалуйста, статья из нашего ресурса.

Что такое Debug

Debug — это процесс отладки (проверки) кода, когда в процессе его выполнения можно остановиться в обозначенном месте и посмотреть за ходом выполнения. Понять, в каком состоянии находится программа в определенном месте. Это точно так же, как если бы можно было остановить жизнь и посмотреть на всё со стороны. Круто, правда? Наша задача состоит в том, чтобы быстро и просто научиться проводить отладку приложений при помощи всеми нами любимой среды разработки Intellij IDEA.

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

1. Среда разработки Intellij IDEA версии 2019.3.1 и выше. На случай, если у кого-то её нет, вот ссылка, где можно скачать. Скачивайте Community Edition, так как я буду использовать именно ее.
2. Клонировать проект из GitHub и импортировать его через IDEA.

Немного теории… обещаю 😀

если в выражении есть лямбда, то IDEA предлагает вам выбор — поставить на всю линию или конкретно в лямбда выражение: