В то же время я был напуган идеей писать о программировании в течение долгого времени и испытывал чувство авантюрности. Я должен сказать, что это довольно ошеломляюще, и так должно быть - вокруг так много талантливых и знающих людей, что легко запугать. И, конечно же, всегда есть кто-то, кто знает больше, чем вы. Итак, я решил написать о том, чего я не знаю и как живу с незнанием. Потому что мой любимый персонаж или мой личный тренер, если можно, говорит: «Чувак, отстой в сумме - это первый шаг к тому, чтобы в чем-то преуспеть». © Собака Джейк

Итак, без лишних слов.

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

Я уверен, что есть много полезных статей (я читал некоторые из них) об этом, и многие люди пишут сверхэффективные журналы. Их журналы следуют одному четкому руководству по стилю, никогда не забрасываются, а также каким-то образом заставляют ваше приложение работать со скоростью света с меньшими затратами ресурсов. Мы все знаем этих людей. Те, кто «я написал немного Haskel перед обедом для решения некоторой теоретической задачи CS». И, честно говоря, я рада за них. Я уверен, что это было нелегко, и они приложили некоторые усилия, чтобы сделать свои журналы шедевром, но лично я иногда оказываюсь в положении, когда мне действительно нужно писать КОД, и у меня нет времени размышлять » если моя система регистрации достаточно устойчива »- тот факт, что у меня уже есть настроенная система регистрации, является большим плюсом. Знаете, все дело в приоритетах.

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

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

Для меня ответ будет примерно таким:

  1. Отладка
  2. Мониторинг
  3. Объясняя «будущему мне», что, черт возьми, происходит

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

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

I. Отладка

Журналы отладки должны помочь вам найти и исправить проблемы в коде. Прохладный. Итак, как же тогда их записать?

Прежде всего, важно отметить, что все мы знаем, что:

 console.log(“did it get here?”)

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

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

  • Вы должны указать, что журнал является ошибкой ether, используя уровень вашего регистратора или простой текст внутри журналов, который доступен для поиска («ERROR» должен делать) или что-то еще, и сериализовать ошибку, где это возможно, чтобы у вас была трассировка стека для фактической отладки.
  • Это сложная концепция, но важно улавливать неудачи. Например: у вас есть приложение, которое принимает такие платежи:
const takePaymentFromUser = (user) => {
   if(!user){
      throw new Error(“No user provided”)
   }
   //TODO take that sweet money
}
const main = () => {
  try {
     takePaymentFromUser()
  }catch (e){
     console.error(e.message)
  }
}
main()

Результатом будет:

No user provided

Это здорово, но никому не помогает. Я думаю, что есть две вещи, которые могли бы сделать его лучше: 1. Он должен иметь трассировку стека, чтобы вы знали, где искать (спорно, применяйте суждение) 2. Он должен давать больше контекста о том, каковы последствия этой ошибки.

Существует как минимум 1538 способов переписать этот пример для выполнения обоих требований, я добавлю один:

const takePaymentFromUser = (user) => {
   if(!user){
      throw new Error(“Unable to take payment. No user provided”)
   }
   //TODO take that sweet money
}
const main = () => {
   try {
      takePaymentFromUser()
   }catch (e){
      console.error(e)
   }
}
main()

Вывод:

Error: Unable to take payment. No user provided
at takePaymentFromUser (/home/runner/OurTameChapters/index.js:3:13)
at main (/home/runner/OurTameChapters/index.js:10:5)
.... etc

В порядке! Теперь мы говорим! Посмотрев на этот журнал, вы сразу поймете, что что-то важное (деньги, деньги, деньги) не так, и также узнаете, где это не так. Это подводит меня к следующему разделу

II. Мониторинг

Еще одна вещь, которую вы хотите, чтобы ваши журналы делали, - это чтобы вы знали, что ваше приложение действительно в порядке, даже если вы не смотрите в консоль, и если это не так, вы об этом узнаете. Эта тема слишком велика, чтобы ее можно было охватить за один присест, поэтому я даже не буду пытаться. Однако есть пара вещей, которые стоит упомянуть, например, зачем вообще контролировать? Вот почему:

  1. Позволяет как можно скорее убедиться, что приложение работает стабильно и предсказуемо, а если и не узнает об этом.
  2. Мониторинг полезен для вас.
  3. Серьезно, это то, что делают все крутые ребята.
  4. Вы можете создавать статистику и оповещения и пытаться всегда знать, что происходит в вашем приложении, а затем строить интересные диаграммы и графики и хвастаться на собраниях команды.

Пара вещей, на которые следует обратить внимание, когда вы регистрируете информацию, которую планируете отслеживать.

  • Если вы планируете отслеживать что-то с течением времени, например, количество входов в систему в день, частоту ошибок или другие вещи, вы, вероятно, не захотите изменять отслеживаемый журнал после его настройки. Так что лучше подумать над составлением этих журналов. В нем должно быть достаточно контекста, чтобы спустя 3 месяца вы все еще понимали, что это значит, и находили его элегантным.
  • Вы, вероятно, собираетесь использовать для этого какой-то сервис, и они, вероятно, будут пропускать / экранировать некоторые символы, скорее всего, журнал «This: /// {не} идея g00d»,. & »Не будет хорошей идеей , сначала проверьте документы.
  • С другой стороны, вы вполне можете захотеть разобрать свои простые журналы на что-то похожее на json или, по крайней мере, использовать пользовательские переменные. В этом случае было бы неплохо иметь разделение между фактическими значениями и обычным текстом, например: «Теперь мы находимся в =‹ имя функции ›= функция. Может упростить работу с regExp.

III. Археология, я имею в виду информацию

Это странная комбинация отладки и мониторинга, которая в основном необходима для предоставления контекста другим журналам и, как правило, их понимания. Сначала это может показаться глупым, но в каждом приложении есть некоторые важные события, которые следует регистрировать, даже если это утомительно. Большая часть этих журналов должна отражать некоторые события жизненного цикла, такие как «приложение запущено» или «приложение остановлено» или «сколько чего-то доступно», вы знаете, что в основном является основой вашего приложения и что в случае «sh * t пошел вниз », будут оставшиеся руины вашего приложения, так что будущим археологам придется повернуть кое-какие камни.

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

Кто-то может сказать здесь: «Ну, я регистрирую свои ошибки, так зачем же регистрировать успех?» - то, что я хотел бы сказать, - это то, что когда дело доходит до расследования места преступления, гораздо лучше знать, что определенно произошло, хорошее или плохое, а затем угадывать, что могло произойти без каких-либо доказательств © Me.

Вывод:

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

Конец… пока.

PS

Чуть не забыл, если ты, мой друг, полный ботаник и хочешь узнать еще больше (!), То по журналам есть масса материалов! Конечно, я бы порекомендовал ознакомиться с классической главой дяди Боба «Чистый код» о журналах. Кроме того, я настоятельно рекомендую ознакомиться с рекомендациями по использованию журналов JSON и платформ журналирования. И давай! Прокомментируйте свою любимую статью с практическими рекомендациями в журналах, и я обижусь, если она не эта!

Ваше здоровье!

#logs #begginersfriendly