Каждый разработчик сталкивается с ситуацией, когда что-то идёт не так, и нужно понять, где зарыта ошибка. У всех есть свои инструменты и подходы, многие используют только console.log, некоторые дебажат в IDE. Сегодня я поделюсь с вами тем, что лучше всего работает для меня. Возможно, это поможет вам улучшить процесс отладки.
Использование Chrome DevTools
Удобнее всего использовать Chrome DevTools. Вот мой алгоритм:
- Открываю вкладку Sources.
- Использую поиск файлов через Ctrl+P (или Cmd+P на macOS).
- Если доступны source maps, нахожу нужный файл и выставляю брейкпоинты.
Когда срабатывают брейкпоинты, я внимательно изучаю стек вызовов.
Использование вкладки Search
Если мне не удается найти нужный файл через Ctrl+P, тогда я использую вкладку Search - о ней я писал тут (https://t.me/c/2239466109/11) 🔗
Когда выручает console.log
console.log — это как швейцарский нож 🗡 для быстрого понимания происходящего, но не стоит использовать его, как единственный инструмент для отладки. Вот несколько ситуаций, где я им пользуюсь:
- Чтобы увидеть динамику данных: например, содержимое массива на каждом шаге.
- Для проверки порядка вызова методов или событийных обработчиков.
Условные брейкпоинты
Если у вас есть массив с сотнями элементов, а ошибка происходит только при определённых условиях, можно использовать условные брейкпоинты. Это спасает от бесконечного нажатия F8. Просто нажмите правой кнопкой мыши на брейкпоинт и добавьте условие.
Когда нужна вкладка Performance
Если не ясно, какие методы вызывает библиотека, я открываю вкладку Performance: просмотр графика и анализа Bottom-Up требует навыков интерпретации профилей производительности, но он помогает увидеть, какие функции вызываются и как они связаны друг с другом.
- Запускаю запись.
- Выполняю действия, которые нужно отладить.
- Останавливаю запись и изучаю вызовы: смотрю график и Bottom-Up, чтобы понять, какие функции были вызваны.
Этот подход не гарантирует, что мы поймем, какие методы были вызваны, но если больше ничего не помогает - может нам повезет.
Firefox для манипуляции запросами
Хотя Chrome — мой основной инструмент, иногда я перехожу в Firefox. Там удобнее повторять запросы, меняя значения параметров. Это упрощает отладку серверных ошибок.
- Находим нужный запрос
- Вызываем контекстное меню и выбираем "Изменить и снова отправить"
- Правим запрос и отправляем
Ошибки в продакшне: нет source maps
Когда ошибка прилетает с продакшена, но у вас нет source maps, придётся работать с минифицированным бандлом: это может быть сложно для анализа, поэтому важно уметь находить ключевые участки логики, которые помогут понять, что происходит.
- Скачиваю файл с продакшена.
- Открываю его в IDE.
- Ищу нужную строку по номеру (например, 1:25000).
- Анализирую код: ищу цепочки вызовов (.trim().toLowerCase()), строковые константы или другие подсказки.
Это сложный процесс, но с опытом начинаешь распознавать такие ситуации быстрее.
Ошибки в сторонних библиотеках
Сначала это может пугать. Помню свои первые случаи, когда понимал, что ошибка в сторонней библиотеке. Но со временем я освоил подход:
- Анализирую стек вызовов, чтобы понять, где инициализировались данные.
- Проверяю параметры, которые передаются в библиотеку.
Так удавалось даже понять, что в проекте одновременно используются две несовместимые версии одной и той же библиотеки (здравствуйте, ProseMirror👋).
С опытом такие проблемы начинают решаться быстрее. Главное — не сдаваться и разбирать всё по частям.
⚙️ Дебаггинг — это важный навык для любого программиста. Чем больше вы пробуете разных подходов, тем лучше начинаете понимать, что работает именно для вас. А какие методы используете вы? Поделитесь своим опытом в комментариях 💬
Больше лайфхаков и полезных материалов вы найдете в моем Telegram-канале Frontmind. Присоединяйтесь!
#debugger #frontend #chromeDevTools