От автора: добавление в код console.log(), вероятно, является одной из наиболее распространенных практик среди разработчиков. Тем не менее, я потратил много времени своей жизни, чтобы убедить начинающих (а иногда и опытных кодировщиков) перестать использовать его для отладки JavaScript, и вот почему.
Во-первых, я должен признать, что я все еще использую инструкцию console.log() в своем коде, старые привычки умеют тяжело! Я не одинок, около ¾ разработчиков Node.js использовали ее (в 2016 году) для поиска ошибок в приложениях. В ряде ситуаций это либо самое простое решение, потому что вы точно знаете, что сохраняет информацию, либо вы ограничены производственной / встроенной средой и не имеете другого инструмента. Тем не менее, это не повод делать исключение и вводить эту технику в свою повседневную практику. Действительно, как правило, console log не работает, так как является ненадежным и подверженным ошибкам способом — в то время как нам доступны другие более надежные решения.
Отсутствует контекстная информация
console.log() заставляет вас сознательно выбирать, какая информация должна регистрироваться до отладки. И то, что вы отображаете в первую очередь, недостаточно или даже совершенно не имеет значения, потому что вы, как правило, еще не знаете, что происходит. Каждый раз, когда вы запускаете приложение, вы делаете шаг вперед, понимая, что вы по-прежнему не уверены, что регистрируете нужную информацию в нужное время — вы теряете время, изменяя операторы снова и снова, чтобы отображать новую информацию и скрывать нерелевантную.
Контр-аргументы инструмента отладки:
отображение / просмотр любой переменной JS внутренне во время отладки (аргументы функции, локальные переменные, глобальные переменные и т. д.);
исследовать стек вызовов, чтобы получить полный контекст, в котором появляется проблема.
Слишком много информации
Алгоритмы обычно предназначены для автоматизации большого количества малых задач, циклов и рекурсий, являющихся фундаментальными блоками. Вместе с console.log() это приводит к большому количеству отображаемых строк. Т.е., вам трудно найти подходящую информацию.
Контр-аргументы инструмента отладки:
создавать условные контрольные точки для приостановки выполнения, когда выполняется конкретное условие, чтобы вы могли заняться анализом происходящего;
отслеживать пользовательские выражения JS (переменные, условия и т. д.), чтобы вы не тратили время на то, чтобы выводить одно и то же выражение на каждом этапе цикла;
создать журнал отладки для классификации в дополнение к стандартным журналам приложений, чтобы активировать отладочные сообщения по запросу для интересующего «домена» (например, файла, службы, класса и т. д.).
Недостоверная информация
Вы не всегда можете доверять информации, сообщаемой console.log(), потому что для него не существует стандартизированного поведения. Вы действительно не знаете, что происходит под капотом. Большую часть времени вызов console.log(), когда консоль еще не активна, приводит только к ссылке на объект, находящийся в очереди, а не на результат, который будет содержать консоль. В качестве обходного решения вам нужно будет либо клонировать информацию, либо сериализовать ее снэпшоты. Визуализация выполняется асинхронно (с дросселированием частоты обновление), так как будущие взаимодействия с зарегистрированными объектами похожи на расширение свойств объекта в консоли браузера.
Контр-аргументы инструмента отладки:
асинхронные трассировки стека (теперь по умолчанию в Chrome) позволяют проверять вызовы функций за пределами текущего цикла событий, точно так же, как контекстно-зависимые по времени к инициаторам ваших асинхронных callback-ов.
Измененное поведение кода
«Стандартный» способ отладки асинхронного кода — это консольные журналы «1», «2», «3», «4» и т. д. Т. е. все выполненные шаги перед ожидаемым результатом, пока вы не получите правильный порядок. Как следствие, вы модифицируете код и, таким образом, способ его запуска, что может привести к очень трудному отслеживанию нестандартного поведения. После завершения отладки вы также должны не забыть удалить все журналы консоли в коде.
Контр-аргументы инструмента отладки:
когда нам нужно действительно разобраться в потоке приложения, пошаговый процесс является обязательным;
когда нам нужно действительно разобраться в тайминге асинхронных обратных вызовов, контрольные точки приходят вам на помощь (выберите тип, который лучше всего подходит вашей проблемы).
Инструментарий для отладки для JavaScript
Существует несколько инструментов, которые помогут вам в отладке приложений полного стека JS:
Chrome DevTools, теперь он поддерживает отладку Node.js в дополнение к JS-коду, запущенному на локальном или удаленном браузере (т. е. на мобильном устройстве);
Отладочный модуль Node.js.
Можно упомянуть также winston или loglevel, как довольно полезные настраиваемые регистраторы, но я предпочитаю использовать их для производственных журналов (информации, предупреждений, ошибок и т. д.).
И если вы чувствуете, что еще не в состоянии использовать отладчик при запуске тестов, прочитайте эту статью и другие подобные ресурсы, которые вы можете легко найти в Интернете.
Автор: Luc Claustres
Источник: https://hackernoon.com/
Редакция: Команда webformyself.