Перевод: Ackshaey – Level up your JavaScript browser logs with these console.log() tips

Я считаю себя инженером-программистом, и, как подтвердит любой инженер-разработчик, большая часть нашей жизни тратится на мониторинг, устранение неполадок и отладку наших приложений. Фундаментальное правило разработки программного обеспечения заключается в том, что программное обеспечение всегда содержит ошибки. Новых разработчиков от опытных отличает то, как они планируют работу над ошибками. Надежное и эффективное ведение журнала – важная часть планирования сбоев и их устранения. Как и при разработке серверной части, ведение журнала может быть полезно для разработки фронтенда, но оно идет гораздо дальше, чем просто устранение неполадок и отладка. Эффективное ведение журнала внешнего интерфейса также может сделать процесс разработки продуктивным, быстрым и увлекательным.

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

Мне нравится разделить эти советы на две большие категории – быстрое и грязное ведение журнала, когда вы активно создаете и отлаживаете свое приложение, и надежное ведение журнала производства, чтобы знать, когда ваше приложение работает должным образом, а когда нет.

Советы по быстрому и грязному ведению журнала разработки с помощью console.log()

Не используйте console.log ().

Да все верно. Я не использую console.log(). Хорошо, хорошо, я пишу обертки, которые используют console.log() (подробнее об этом в разделе ведения журнала для производства), но если вы хотите что-то регистрировать в своем приложении, чтобы увидеть, что происходит, вместо этого используйте console.trace(). Помимо предоставления вам всего, что делает console.log(), он также выводит всю трассировку стека, чтобы вы знали, откуда именно было отправлено сообщение.

Используйте имена вычисленных свойств ES6, чтобы идентифицировать свои объекты и избежать путаницы в именах переменных.

Это просто – используйте синтаксис вычисляемых свойств ES6 и заключите объекты, которые вы хотите регистрировать, в фигурные скобки внутри console.log(), то есть используйте console.log({user}) а не console.log(user). Это сделает вывод более аккуратно связанными с именем переменной, установленным в качестве ключа, и значением в качестве самого объекта. Это особенно полезно, когда вы спешите и хотите зарегистрировать несколько объектов одной командой console.log().

Используйте многоуровневые уровни журнала – error, warn, info

console.log(param) по умолчанию ведет журнал на уровне INFO – однако в вашем распоряжении также есть 3 других уровня ведения журнала, которые вы должны использовать – console.debug(), console.warn() и console.error() . Помимо различий в форматировании (обратите внимание на разные цвета!), Консоль разработчика браузера также позволяет легко фильтровать журналы на разных уровнях с помощью удобного раскрывающегося списка, чтобы очистить журналы.

При регистрации списков элементов используйте console.table()

Эта функция не требует пояснений и является одной из моих любимых консольных функций – если вам когда-нибудь понадобится вывести список объектов, попробуйте console.table().

Быстрая отладка с помощью debugger

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

Детальное профилирование производительности с помощью console.profile() и console.time()

Хотите профилировать точный поток пользователей в своем приложении, чтобы найти горячие точки? Запустите console.profile(profileName) в начале действия и console.profileEnd(profileName) в конце, чтобы проверить профиль ЦП для потока.

В связи с этим вы можете точно измерить, сколько времени занимает поток, запустив console.time(id) в начале потока и console.timeEnd(id) в конце.

Считайте отмеченные executions с помощью console.count()

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

Сделайте ваш лог более красивым с помощью CSS

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

Вы также можете стилизовать несколько элементов, расширив строку формата, включив %s для строковых параметров.

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

Ведение журнала с помощью console.log()

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

Не используйте console.log()

Вместо этого напишите класс-оболочку, который включает логику для условного ведения журнала на основе уровня журнала, установленного серверной частью на основе глобальной переменной. Внимание! Впереди вы увидите фрагменты кода TypeScript. Если вы не знакомы с TypeScript, думайте о нем как о надмножестве JavaScript с добавленными типами (чрезмерное упрощение), то есть const str = «some string»; становится const str: string = «некоторая строка» – типы добавляются после переменной, за которой следует точка с запятой.

В случае Firecode.io я написал свой собственный интерфейсный фреймворк, который использует RxJS, но включает знакомые концепции, такие как компоненты из других популярных фреймворков, таких как React и Vue, при добавлении дополнительных концепций, таких как движки для блоков кода с большой нагрузкой на процессор, каналы для сообщений WebSocket и клиентов для HTTP-запросов. Визуализация совместной работы всех этих частей была критически важна, поэтому я реализовал настраиваемое форматирование в классе оболочки Logger, который форматирует и визуально различает журналы из каждой части приложения.

Вместо вызова console.log(“Cache SET to”, {value}) я вызываю Logger.debug(“Cache set to”, {value}, Framework.Cache). У класса Logger есть перечисление TypeScript, которое сопоставляет каждый компонент фреймворка используемому цвету:

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

Защитите свои журналы, установив уровень журнала на сервере

У меня Firecode.io настроен на включение регистрации уровня отладки по умолчанию для пользователей с правами администратора с переменной JavaScript, которая устанавливается бэкэндом. Хотя предприимчивые пользователи могут найти и установить эти флаги в консоли разработчика, чтобы включить детальное ведение журнала, это лучше, чем если бы все журналы были открыты для каждого пользователя вашего приложения по умолчанию, или если постпроцессор полностью удалил все журналы из вашего приложения. в производстве.

Установить во вьюхах Ruby on Rails:

const logLevel: number = <%= @app.get_log_level_for_user %>

И в классе Logger:

class Logger {
   ...
   ...
   static info(...) {
     shouldLog(Level.INFO) && console.log(...);
        ...
   }
}

Логирование и уведомление о возможных ошибках

И последнее, но не менее важное: вам нужно получать уведомления, когда пользователи сталкиваются с ошибками, без необходимости вывода журналов в консоль разработчика. Вы можете сделать это, включив вызов для передачи ваших ошибок сторонней службе APM, такой как AppSignal, в функцию обработки ошибок вашего Logger, например так:

class Logger {
   ...
   ...
   static error(e) {
     if (shouldLog(Level.ERROR)) {
       console.error(e);
     }
     appsignal.sendError(e);
   }
}

AppSignal включает в себя интеграции для передачи ваших ошибок в сервисы исходящих уведомлений, такие как Slack, PagerDuty и OpsGenie – вы даже можете подключить инструмент управления проектами, такой как JIRA или Trello, для автоматического создания тасков для вашей команды.

Заключение

Я очень надеюсь, что эти советы сделают вашу разработку более продуктивной и увлекательной! Я, очевидно, коснулся лишь поверхности логирования, поэтому, если у вас есть еще какие-то советы, я бы с удовольствием прочитал их в своем Twitter.