Многие front-end инженеры не знают, почему для отладки используется отладчик, не может console.log? Кроме того, как отлаживать сложный исходный код, когда есть еще много кода, который вы не можете прочитать, даже если вы можете использовать отладчик? В этой статье мы поговорим о том, почему нам нужно использовать эти инструменты отладки.

console.log против отладчика

Я считаю, что большинство студентов используют console.log для отладки и вывода значений переменных, которые они хотят видеть в консоли. Это прекрасно работает, но не когда дело доходит до печати объектов. Например, если я хочу увидеть значение объекта компиляции в исходном коде веб-пакета, я печатаю следующее:

Но вы обнаружите, что значение объекта также является объектом, который не будет расширен, а будет напечатан в виде строки, например [Object] [Array]. Что более фатально, так это то, что слишком долгая печать превысит размер буфера, и терминал не отобразит все это целиком.

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

Некоторые учащиеся могут сказать, что по-прежнему удобно использовать console.log при выводе простого значения. Действительно? Тогда лучше использовать logpoint.

И не загрязняя код, если вы используете console.log, разве вам не нужно удалять консоль после отладки?
Но logpoint не нужен, это настройка точки останова, а не в коде.
Конечно, самое главное, что отладчик отладчика может видеть стек вызовов и область видимости! Во-первых, это стек вызовов, который является маршрутом выполнения кода. Например, функциональный компонент этого приложения, вы можете видеть, что рендеринг этого функционального компонента будет проходить через процессы workLoop, beginWork, renderWithHooks.

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

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

С помощью отладчика вы можете увидеть путь выполнения кода, информацию о области действия каждого шага. А вы используете console.log? Вы можете видеть только значение переменной. Разница в количестве информации, которую вы получаете, не так уж и мала. После долгой отладки поток кода будет становиться все яснее и понятнее, а вы используете console.log? Это все то же самое, потому что вы не можете видеть путь выполнения кода. Таким образом, независимо от отладки исходного кода библиотеки или бизнес-кода, независимо от отладки Node.js или веб-страниц, рекомендуется использовать отладчик для достижения точек останова, а не console.log, даже если вы хотите распечатать журналы, вы можете использовать LogPoint .
А при устранении неполадок можно добавить точку останова исключения, если вы используете отладчик, поэтому код остановится, когда достигнет места, где возникает исключение.

Вы можете увидеть стек вызовов, чтобы выяснить, какой код был до ошибки, и вы можете увидеть значение каждой переменной по области. С помощью этих вещей легко устранять ошибки! А вы используете console.log? Ничего, ты должен угадать.

Производительность

Отладчик Debugger может видеть путь выполнения фрагмента кода, но путь выполнения кода часто довольно запутан. Например, React обрабатывает каждый узел волокна, вызывая beginWork для каждого узла, а затем обрабатывает следующий узел, снова вызывая beginWork.

Точно так же, как если бы вы взяли трейл, а затем вернулись к основному трейлу, а затем выбрали другой трейл, с помощью отладчика вы можете видеть только путь выполнения текущего трейла, а не пути других трейлов.

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

Исходная карта

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

Например, с исходной картой, связанной с vue, мы можем напрямую отлаживать исходный код ts.

гнездо.js:

Если вы не используете исходную карту, вы хотите понять исходный код, но вы отлаживаете скомпилированный код, как вы можете его прочитать?

Прочитайте одну строку

Debugger, Performance, SourceMap, упомянутые ранее, это просто инструмент для отладки кода, который будет отладчиком, все еще не может прочитать код, как это сделать? Я думаю, что это невозможно. Почему ты так говоришь? Возьмите исходный код реакции, чтобы сказать.

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

Краткое содержание

В этой статье рассказывается о том, почему вы должны использовать инструменты отладки и как читать сложный код. Слишком много недостатков у console.log, не печатаются большие объекты, превышен буфер терминала, нельзя расширить свойства объекта и т.д. Не рекомендуется его использовать. Даже если вы хотите печатать, вы можете использовать LogPoint. Отладчик может видеть стек вызовов, то есть путь выполнения кода, область действия каждого кадра стека, вы можете знать, через что прошел код с начала выполнения до сих пор, в то время как console.log может знать только значение переменной. Кроме того, когда сообщается об ошибке, путь выполнения кода можно отсортировать по контрольным точкам исключений, чтобы определить причину ошибки. Но отладчик может видеть только один путь выполнения, поэтому вы можете использовать Performance для записи всего потока выполнения кода, а затем объединить его с отладчиком, чтобы перейти к подробностям выполнения одного из путей. Кроме того, имеет смысл отлаживать только исходный код, иначе отладка скомпилированного кода будет гораздо менее информативной. Вы можете использовать SourceMap для связи с исходным кодом, будь то исходный код Vue, React или Nest.js, Babel и т. д. После отладки вы можете отлаживать все виды кода, нет исходного кода, который вы не могли бы прочитать, потому что каждая строка кода является основным синтаксисом, умеете читать, если не умеете читать, возможно только слишком много кода, вам нужно больше терпения, чтобы прочитать строку кода, функцию, чтобы понять реализацию функции, медленно накапливать, это хорошо.
После освоения отладочного кода на основе Debugger, Performance, SourceMap и т. д. можно отлаживать все виды веб-страниц и кода Node.js, а также все виды исходного кода. прочитал и понял!

Добро пожаловать в Twitter, LinkedIn и GitHub!

Писать всегда было моей страстью, и мне доставляет удовольствие помогать людям и вдохновлять их. Если у вас есть какие-либо вопросы, обращайтесь!

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .

Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.