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

Разработка программного обеспечения как таковая основана на предположении, что программное обеспечение выйдет из строя. При этом основное различие между новичком и опытным разработчиком заключается в том, как они готовятся и планируют указанные ошибки.

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

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

Советы во время цикла разработки

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

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

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

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

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

Опробуйте ошибку, предупреждение и информацию (многоуровневые уровни журнала)

По умолчанию console.log (param) будет регистрироваться на уровне INFO. С другой стороны, у вас также есть три других уровня, которые вы можете использовать. Это consoles.debug (), console.warn () и console.error (). Помимо различий в форматировании, консоль разработчика браузера также позволяет фильтровать журналы на разных уровнях.

Для списков и элементов используйте console.table ()

Стоит ли говорить больше? Если вы когда-нибудь окажетесь в ситуации, когда вам нужно зарегистрировать список или элемент, попробуйте эту команду.

Примите отладчик

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

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

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

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

Используйте console.count () для подсчета помеченных выполнений

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

Ведение журнала с помощью CSS

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

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

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

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

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

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

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

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

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

Попросите серверную часть установить уровень вашего журнала, чтобы защитить ваши журналы

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

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

Установить в представлении Ruby on Rails:

const logLevel: number = ‹% = @ app.get_log_level_for_user%›

И в классе Logger:

class Logger {

статическая информация (…) {

shouldLog (Level.INFO) && console.log (…);

}

}

Регистрировать возможные ошибки (и также уведомлять)

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

class Logger {

static error (e) {

if (shouldLog (Level.ERROR)) {

console.error (е);

}

appsignal.sendError (е);

}

}

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

Заключительные мысли

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

Первоначально опубликовано на https://www.popwebdesign.net 30 марта 2021 г.