Как работать с багами для новичков

04d351db60165a5da7456606a42b5fa7.jpg

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

Начнем с самого очевидного, а именно IDE.

Ищите ошибки с помощью вашей IDE — это не просто продвинутый текстовый редактор, а ваша первая линия обороны против багов.

TypeScript, например, помогает находить ошибки на раннем этапе благодаря проверке типов.

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

Пример:

let age: number = 'twenty';

TypeScript будет недоволен и сообщит вам, что 'twenty' не является числом. Это как иметь личного консультанта для вашего кода.

Попробуйте выделить область

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

Скрывается ли ошибка в бэкэнде, спрятана ли во фронтэнде, заговорщики ли сидят в базе данных или в инфраструктуре?

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

Пример: Допустим, вы отправляете запрос на GET /users и получаете статус 500. Это сервер говорит вам: «Парень, у меня проблемы». Это проблема бэкэнда. Но если вызов вернул статус 200, а ваш интерфейс все еще играет в прятки с данными, то ошибка устроила вечеринку в вашем фронтэнде. Вкладка сети только что подсказала вам адрес.

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

Смотрите на ошибки в консоли браузера

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

Пример: Ваше приложение React не загружает данные. Быстрый взгляд на вкладку консоли показывает ошибку "undefined" и номер строки. И вот где ваша проблема. Элементарно, дорогой Ватсон!

Добавьте console.log() в разные функции

Скромный console.log(), этот оператор вывода, который может многое. Когда сомневаетесь, выводите. Это как оставлять крошки хлеба через ваш код, чтобы посмотреть, как далеко дойдет Красная Шапочка, пока не встретит Большого Плохого Бага.

Пример:

Не уверены, получает ли ваша функция ожидаемые данные? console.log('Данные:', данные) в начале функции. Нет данных? Теперь вы знаете, где начинается проблема.

Использование блоков try-catch

Блоки try-catch — это ваше страхование, позволяющее вашему коду смело выполнять смелые финты без краха вашего приложения. Они позволяют вам красиво обрабатывать ошибки, перехватывая их до того, как они нанесут вред. Кроме того, они позволяют вам указать собственные пользовательские сообщения об ошибках для определенного блока кода, помогая вам найти область проблемы.

Пример: Оберните ваш вызов API в блок try-catch. Если вызов завершится неудачно, блок catch поймает ошибку, позволяя вам вывести ее в консоль или отобразить дружественное сообщение пользователю.

try {
  // Попробуйте выполнить опасный код
  riskyFunction();
} catch (error) {
  // Перехватываем ошибку, если что-то пошло не так
  console.error('Произошла ошибка:', error);
}

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

Застряли на сообщении об ошибке? Google и ChatGPT

Google и ChatGPT это ваша библиотека и библиотекарь. Просто скопируйте и вставьте ошибку в строку поиска, и вы увидите множество решений. Это как обратиться к мудрости толпы: кто-то, где-то, сталкивался с вашей проблемой раньше.

Пример: Получаете сообщение об ошибке "TypeError: Cannot read property 'map' of undefined"? Быстрый поиск показывает, что вы, возможно, пытаетесь использовать .map () на чем-то, что не является массивом.

Тестирование регулярно

Лозунг «test early, test often» сэкономит вам кучу времени. Тестирование небольших фрагментов кода по мере работы поможет вам обнаруживать ошибки на ранних этапах, когда их легче исправить. Это как уборка во время готовки — это делает окончательную уборку намного проще.

Пример: Только что добавили новую функцию? Проверьте ее перед тем, как продолжить. Работает ли она как ожидалось? Отлично! Нет? Пора отлаживать, пока код еще свеж в вашей памяти.

Попробуйте другой подход


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

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

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

Давайте возьмем реальный сценарий. У меня есть приложение на React, Node и Postgres, которое отображает пользователей в браузере. Код, насколько я знаю, должен работать, но я не вижу пользователей на фронтенде.

Шаг 1 — Проверьте консоль

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

7bfee844d02b8d1cccc0f7189cbebc93.PNG

Ах, сюжет «Почему это не работает?». Давайте погрузимся в драму, разворачивающуюся в вашей консоли, и разберем крошки, оставленные нашим шаловливым другом, багом.

Первым нашим ключевым уликой является:

GET http://localhost:3000/api/users 500 (Внутренняя ошибка сервера). Эта строка — эквивалент крика в ночи в нашем детективном рассказе. Она говорит нам, что наш бэкэнд в беде, возможно, связан с коварным SQL-запросом или взбалмошной логикой в нашем маршруте API.

Крик сервера о помощи звучит громко и четко: «Внутренняя ошибка сервера». Действительно, классический ход бэкэнда.

Теперь наша вспомогательная группа вступает на сцену с ошибкой

ResponseError: Response returned an error code. Это важное открытие. Проблема не просто в том, что сервер плохо себя ведет — это ошибка ResponseError, пойманная с поличным в UsersApi.request, и даже говорит нам, где строка ошибки (UserApi.ts:83).

Шаг 2 — Проверьте терминал бэкэнда

Наше путешествие в расследование бага привело нас к бэкэнду, где нас встречает следующее:

9aeb65cbc449f2a829856bcac18ee292.PNG

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

Когда происходит ошибка бэкэнда, это называется стеком вызовов — по сути, это все ошибки, информация, номера строк и так далее, с которыми столкнулся компилятор, объединенные в один большой текстовый блок. Спасибо, компилятор!

То, что мы делаем здесь, — ищем ключевые слова, узнаваемые файлы или что-то, что может быть прочитано человеком. Заметили что-то? Давайте копнем глубже:

642f3c1a0f2cdc7115a74558725960a6.PNG

Выделенные части текста желтого цвета указывают на ошибку в файле userController.ts, конкретно в функции getAllUsers(). Если мы прочтем дальше, то выделенные части красного цвета указывают на сообщение об ошибке:

Authentication failed against database server at `dpg-cn9kr28l6cac73a1a7eg-a.frankfurt-postgres.render.com`, 
the provided database credentials for `dmin` are not valid.\n\nPlease make sure to provide valid database credentials for the database server 

Ура! Теперь мы знаем ошибку. Мы неправильно написали «admin» в строке подключения к базе данных, что привело к сбою подключения. Ой! После исправления этой ошибки проблема решена:

ошибка решена

ошибка решена

Шаг 3: Проверка исправления

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

Заключение

Надеюсь, этот материал пролила свет на то, как вы можете отлаживать свои проекты.

© Habrahabr.ru