Перевод статьи «How to Debug Coding Problems When Building Your Own Projects».
Ах, радость кодинга! Вы работаете над своим проектом, и вдруг — бац! — обнаруживаете ошибку. Это все равно что уткнуться в стену в лабиринте.
Но не бойтесь, друзья-разработчики: я предлагаю вам надежную карту для навигации по коварным водам программирования, кишащим ошибками. Будь вы самоучкой, стремящимся получить работу мечты в сфере технологий, или просто занимаетесь программированием ради удовольствия, из этой статьи вы узнаете, как стать ниндзя отладки.
Ищите ошибки в вашей IDE
Ваша интегрированная среда разработки (IDE) — это не просто модный текстовый редактор. Это ваша первая линия защиты от ошибок.
TypeScript, например, напоминает друга, предупреждающего о яме, в которую вы собираетесь шагнуть. Он помогает обнаружить ошибки на ранней стадии благодаря своей способности проверять типы.
Представьте, что вы случайно пытаетесь добавить число к строке. TypeScript взмахнет большим красным флажком, спасая вас от последующего фейспалма. Это одна из многих причин, по которым мы обожаем TS.
Пример. Вы объявляете let age: number = 'twenty';. TypeScript неодобрительно насупится и скажет, что 'twenty' — это не число. Он как ангел-хранитель для вашего кода.
Попробуйте изолировать область
Прежде чем начать рвать на себе волосы, попробуйте поиграть в детектива и определить, где находится место преступления.
Затаилась ли ошибка в бэкенде, прячется ли во фронтенде, прошмыгнула ли в базу данных или прохлаждается в инфраструктуре?
Если вы работаете локально, то обычно это один из первых трех подозреваемых. И вот вам совет: вкладка «Network» в инструментах разработчика вашего браузера — это как полицейский сканер, который поможет вам определить местоположение сигнала бедствия.
Пример. Допустим, вы отправляете запрос GET /users, а он возвращает статус 500. Это сервер говорит вам: «Приятель, у меня проблемы». Это проблема бэкэнда. Но если запрос возвращается со статусом 200, а ваш пользовательский интерфейс все еще играет в прятки с данными, значит, ошибка устроила вечеринку во фронтенде. Вкладка «Network» только что вручила вам адрес.
Отладка кода будет гораздо эффективнее, когда вам удастся сузить зону поиска. Это как знать, куда идти: в замок, в логово дракона или в темный лес. Счастливой охоты!
Ищите ошибки в консоли браузера
Консоль браузера — это увеличительное стекло Шерлока Холмса для веб-проектов. Она обнаруживает улики, спрятанные на виду. А вкладка консоли — это как отслеживание того, где побывал злодей. Она помогает обнаружить досадные осечки в коде.
Пример. Ваше React-приложение не получает данные. Быстрый взгляд на вкладку консоли — и вы увидели ошибку «undefined» и номер строки. Вот где кроется ваша проблема. Элементарно, мой дорогой Ватсон!
Добавляйте console.log() в различные функции
Ах, скромный console.log()! Если сомневаетесь, выводите лог. Это все равно, что рассыпать хлебные крошки по всему коду, чтобы посмотреть, как далеко зайдет Красная Шапочка, прежде чем встретит Злой и Страшный Баг.
Пример. Не уверены, что ваша функция получает ожидаемые данные? console.log('Data:', data) в начале функции. Нет данных? Теперь вы знаете, где начинается проблема.
Используйте блоки Try-Catch
Блоки Try-Catch — это ваша защитная сетка, позволяющая вашему коду совершать смелые подвиги без сбоев в работе приложения. Благодаря им мы можем изящно справляться с ошибками, отлавливая их до того, как они принесут хаос. Эти блоки также позволяют задавать собственные сообщения об ошибках, помогая найти проблемную область.
Пример. Оберните вызов API в try-catch. Если вызов не удался, блок catch перехватывает ошибку, позволяя вам вывести ее в консоль (console.log) или отобразить пользователю дружественное сообщение.
Вот как выглядит блок try-catch в JS:
function displayUsers() {
try {
const users = getUsers();
} catch (error) {
console.log("oh crap");
}
}
Ищите сообщения об ошибках в Google или используйте ChatGPT
Застряли на сообщении об ошибке? Google и ChatGPT — это ваша библиотека и библиотекарь. Просто скопируйте и вставьте сообщение в строку поиска и наблюдайте, как появляется множество решений. Это как спросить у коллективного разума: кто-то где-то уже точно сталкивался с такой проблемой.
Пример. Получили ошибку «TypeError: Cannot read property ‘map’ of undefined»? Быстрый поиск показывает, что вы, возможно, пытаетесь использовать .map() для чего-то, что не является массивом. Упс!
Тестируйте часто
Мантра «тестируй рано, тестируй часто» сэкономит вам кучу времени. Тестируя небольшие фрагменты кода по ходу работы, вы отлавливаете ошибки на ранней стадии, когда их легче устранить. Это похоже на мытье посуды по ходу готовки — сильно облегчает уборку по окончании стряпни.
Пример. Только что добавили новую функцию? Протестируйте ее, прежде чем двигаться дальше. Она работает так, как ожидалось? Отлично! Нет? Пора отлаживать, пока код еще свеж в памяти.
Попробуйте другой подход
Не можете распутать узел? Возможно, его стоит разрубить! Не привязывайтесь к своему коду слишком сильно. Будьте готовы к рефакторингу или даже к тому, чтобы начать с нуля, если это означает более чистое и элегантное решение.
Пример. Если ваш код запутался сильнее, чем спагетти в кастрюле, отступите назад и переосмыслите свой подход: возможно, вы найдете более простой и эффективный путь.
Отладка — это частично искусство, частично наука и целиком — испытание терпения. Но благодаря приведенным стратегиям вы сможете более эффективно бороться с багами в своем коде. Счастливого кодинга, и пусть ваши поиски ошибок будут короткими, а ваш код — чистым!
Сценарий из реальной жизни
Давайте рассмотрим реальный сценарий. У меня есть приложение на React, Node и Postgres, которое отображает пользователей в браузере. Код, насколько я знаю, должен работать, но я не вижу пользователей на фронтенде.
Шаг 1. Проверьте консоль
Давайте заглянем в консоль в инструментах разработчика Chrome и посмотрим, что там происходит.
В саге «Почему эта штука не работает?» сюжет закручивается. Давайте погрузимся в драму, разворачивающуюся в вашей консоли, и разберемся с хлебными крошками, оставленными нашим озорным другом — багом.
Во-первых, у нас есть главная подсказка: GET http://localhost:3000/api/users 500 (Internal Server Error). Эта строка в нашей детективной истории — будто крик в ночи. Она говорит нам о том, что наш бэкенд попал в беду, возможно, связанную с недобросовестным SQL-запросом или нестандартной логикой в нашем API-маршруте.
Крик сервера о помощи звучит громко и четко: «Внутренняя ошибка сервера». Классический ход со стороны бэкенда, на самом деле.
Теперь входит наш вспомогательный состав: ResponseError: Response returned an error code. Вот это и есть главное открытие. Проблема не просто в том, что у сервера денек не задался — это ошибка ResponseError, пойманная с поличным в UsersApi.request, и даже указывающая нам, где находится строка ошибки (UserApi.ts:83).
Шаг 2. Проверяем терминал бэкенда
Наши поиски бага привели нас к бэкенду, где нас встречает следующее:
Если вы видите это и ваш первый инстинкт — убежать и спрятаться, не волнуйтесь: у меня тоже так было. Но не бойтесь! Есть множество подсказок, которые указывают нам на проблему.
Это так называемая трассировка стека — все ошибки, информация, номера строк и так далее, с которыми столкнулся компилятор, в одном большом блоке текста. Спасибо компилятору!
Здесь мы ищем ключевые слова, узнаваемые файлы или все, что может быть прочитано человеком. Нашли что-нибудь? Давайте погрузимся глубже:
Выделенные желтым цветом части указывают на то, что в файле 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).
Заключение
Надеюсь, эта статья пролила свет на то, как проводится отладка личных проектов.
Если вы хотите узнать больше об отладке, можете заглянуть на наш YouTube-канал, где мы создаем и развертываем приложения полного стека, используя React, Node и другие крутые технологии. Надеемся увидеть вас там!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]