JavaScript почему не рекомендуется использовать console.log

JavaScript почему не рекомендуется использовать console.log

 

Добавление console.log () в наш код, является одной из наиболее распространенных практик среди разработчиков. Тем не менее, я потратил много времени, чтобы убедить начинающих (а иногда и опытных программистов) прекратить использовать его для отладки JavaScript, вот почему.

Во-первых, я должен признать, что я все еще делаю инструкции console.log () в своем коде, от старых привычек тяжело избавится 🙂 и в этом я не одинок, около ¾ разработчиков Node.js сообщают об использовании его (в 2016 году) для поиска ошибок в своих приложениях. В нескольких ситуациях это самый простой вариант, потому что вы точно знаете, как работает ваш код. Тем не менее, это не повод сделать исключение привести хорошую практику в вашу повседневную практику. Действительно, как правило, console.log ()   подвержен ошибкам, как вы увидите ниже, в то время как доступны очень сложные решения.

 

Отсутствие контекстной информации

console.log () обязывает вас сознательно выбирать, какая информация должна регистрироваться до отладки. Кода в консоли отображается отладочная информация, как правило вы на самом деле не знаете, что происходит.  Каждый раз, когда вы запускаете свое приложение, вы делаете еще один шаг вперед, понимая, что вы по-прежнему не регистрируете правильную информацию, а только отображаете какой от кусочек информации, запуская и запуская приложение вновь.

 

Инструменты отладки

 

Слишком много информации

Алгоритмы обычно предназначены для автоматизации большого количества небольших задач, циклов и рекурсии, являющихся фундаментальными строительными блоками для этого. Наряду с console.log () это приводит к большому количеству строк, отображаемых перед вами, т. Е. Трудно найти подходящую информацию.

 

Инструменты отладки

  • создавать условные точки для приостановки выполнения кода, когда выполняется конкретное условие, чтобы вы могли проанализировать происходящее;
  • наблюдать пользовательские выражения JS (переменные, условия и т. д.), чтобы вы не тратили время на то, чтобы вывести одно и то же выражение на каждом шаге цикла;
  • создайте отладочную классификацию в дополнение к стандартным журналам приложений, чтобы активировать сообщения отладки по запросу для интересующего «домена» (например файла, службы, класса и т. д.).

 

Недостоверная информация

Вы не всегда можете доверять информации, сообщаемой console.log (), потому что нет стандартизированного поведения. Вы действительно не знаете, что происходит под капотом. Зачастую когда вы вызываете console.log (),  консоль еще не активна, и это приводит только к ссылке на объект, находящийся в очереди, а не на вывод данных, которые будет содержать консоль. В качестве обходного пути вам потребуется либо клонировать информацию, либо сериализовать снимки. Реализация выполняется асинхронно, так как в будущем взаимодействует с зарегистрированными объектами, расширяемыми как свойства объекта.

 

Инструменты отладки

 

Измененное поведение кода

«Стандартный» способ отладки асинхронного кода – это условные точки входа в коде и вывод их в консоль, в каком то порядке «1», «2», «3», «4» и т. Появление или выполнение всех шагов, покажет вам порядок работы функций/кода. Как следствие, вы модифицируете код , что может привести к очень трудному отслеживанию нестандартного поведения кода. После завершения отладки требуется почистить код от отладочных функций.

 

 

 

 

 

 

Инструменты отладки

  • когда приходит время, чтобы понять поток выполнения кода, шаг за шагом;
  • когда приходит время, чтобы действительно понять время выполнения асинхронных обратных вызовов, точки останова – ваши лучшие друзья (выберите тип, который лучше всего подходит вашей проблеме).

 

Инструменты отладки JavaScript

Чтобы помочь вам отладить приложение JS, вам понадобиться несколько инструментов:

Можно упомянуть winston или loglevel как довольно хорошие настраиваемые отладчики, но я предпочитаю использовать их для журналирования производственной или общей оценки приложения (information, warnings, errors).

 

Оригинал статьи

eCommerce/Magento Developer, PHP architect, based in Ukraine