Разрабатываю довольно сложное веб-приложение и постоянно трачу часы на поиск глупых ошибок. Использую Chrome DevTools, но чувствую, что упускаю что-то важное. Какие приёмы вы используете, чтобы отлаживать эффективнее?
Что действительно помогает - использовать Network tab параллельно. Часто думаешь, что твой JavaScript глючит, а на самом деле проблема в том, что API call упал молча или вернул странные данные. Всегда проверяй ответы бэкенда перед тем, как копаться в своём фронт-энд коде - это сэкономит тебе часы.
В остальном главный трюк - научиться читать stack trace. Когда вылетает ошибка, не смотри только на то, где написано «ошибка здесь», а проследи всю цепочку вызовов, которая к ней привела. Часто настоящий источник бага находится на два-три уровня выше в цепи. И если ты используешь TypeScript или приличный linter, ты уже ловишь большую часть проблем раньше, чем начнёшь настоящую отладку.
Сколько console.log() ты понаставляешь в код, прежде чем осознаёшь, что Chrome DevTools уже содержит всё, что тебе нужно?
Настоящий перелом в подходе - это перестать думать о дебаггинге как об отчаянной охоте за сокровищами. Chrome DevTools имеет Sources, где ты можешь выставлять настоящие точки останова - не просто "напечатай это значение и молись" - и пошагово проходить через код. То, что люди недостаточно используют - это наблюдение за конкретными переменными, так что ты видишь в реальном времени, что меняется, пока код выполняется. Плюс есть console drawer, который всегда под рукой, идеален для быстрых проверок без остановки выполнения.
Ещё один трюк, который меня не раз спасал: используй Network tab не только чтобы проверить, отправились ли запросы, но чтобы увидеть ровно то, что ты получаешь с сервера. Я уже много раз терял часы, дебаггя логику, которая на самом деле была проблемой в поступающих данных. Если приложение сложное и имеет внутреннее состояние, Vue DevTools или React DevTools (в зависимости от того, что ты используешь) - это просто убийца - видишь, как состояние изменяется в реальном времени, и можешь вернуться к предыдущим состояниям. Это не магия, просто люди часто не знают, что это существует.
Ах, и ещё одно банальное, но правдивое: используй условные точки останова. Не всегда нужно остановиться на строке, нужно остановиться только когда переменная имеет определённое значение. Хотя бы сэкономишь время на клики "continue" тысячу раз.
Не трати время на хаотичную расстановку breakpoint'ов в функциях - вместо этого используй Conditions в Chrome DevTools, чтобы выполнение останавливалось только когда переменная достигнет определённого значения. Это кардинально меняет подход к отладке в сложных приложениях. А когда ты сталкиваешься с ошибкой, которая кажется случайной, вкладка Network часто выявляет то, что в коде не видно, вроде race condition'ов или неправильно отформатированных ответов API.
Когда начинаешь debugгировать, сколько breakpoint'ов ставишь, прежде чем понять, что проблема, вероятно, в другом месте?
Часто не хватает систематичного подхода. Chrome DevTools невероятно мощный, но большинство используют только console.log и обычные breakpoint'ы. Попробуй conditional breakpoint'ы: щёлкни правой кнопкой по строке кода, выбери "Add conditional breakpoint" и напиши нужное тебе условие. Например, breakpoint, который срабатывает только когда `user.id === undefined` вместо того, чтобы останавливать выполнение каждый раз. Потом используй Logpoint'ы (похожи на них, но выводят сообщение без остановки выполнения), когда нужно отследить значения, не прерывая поток выполнения.
Трюк, который знают немногие: на вкладке Network в DevTools можно фильтровать и смотреть, что именно не так с твоими запросами. Если приложение ведёт себя странно, часто проблема в том, что request оказывается не тем, что ты ожидаешь, или ответ malformed'ен. Используй также вкладку Performance, если подозреваешь lag: запиши происходящее и посмотри, где код реально замедляется. И наконец, научись пользоваться Watch expressions: в разделе Scope добавляй переменные, которые тебе интересны, и видишь их обновление в реальном времени при прохождении по коду. Сэкономишь кучу ненужного логирования.
Войдите, чтобы ответить.
