00:00 | Заставка 05:50 | Вступление 06:50 | Как выглядели логи раньше, и что сейчас 08:18 | Go 1.21: log/slog 09:35 | Пример 1: используем slog 11:19 | Пример 2: структурированные логи 13:46 | Пример 3: дидактический 20:12 | Пример 4: развиваем интерфейс 22:21 | Пример 5: перемены в логировании 23:40 | Пример 6: совершенствуем идею 25:38 | Пример 7: ошибка при отправке sms 31:36 | Пример 8: кастомная ошибка 44:31 | Вопрос от зрителей: нормально ли писать в логи номера телефонов? 46:40 | Финал и ответы на вопросы в чате

крутой доклад, респект, больше такого контента

Отличный доклад, спасибо!

Спасибо, очень полезно!

Интересно, спасибо)

думаю userId это всё же второстепенный аргумент. Первостепенным должен быть traceId. А так живенько, полезно. Спасибо.

@MichurinTube

Ай бұрын

TraceId точно надо добавлять, если он есть. Но главное, иметь в логах информацию, которую сообщают пользователи/тестировщики.

спасибо, было интересно

Thanks and Good Luck!

Видео огонь, спасибо Алексей, поделитесь, пожалуйста, своим конфигом для vim 🙏

Леша мой герой!)

Прикольно смотреть, как меняется подходы к разработке. Ранее вот эти примеры использовались, чтоб на собеседовании спрашивать какие SOLID принципы здесь нарушаются. Очень много вопросов возникает после просмотра, жаль не удалось посмотреть в прямом эфире. - Почему логгер(интерфейсный слой) знает о какой-то бизнес логике? Если проблема лишь в том что какой-то программист захочет назвать поле по другому, что мешает этому программисту создать другую структуру данных? П.С. Из ваших слов в авито вы прокидываете мапу, тогда не понятно зачем пример с структурами... - Зачем засорять контекст данными? Я думаю вытекающие проблемы понятны - Почему выбрали именно slog? Честно ожидал что будет как "Jaeger для трассировки в микросервисной архитектуре", а вышла на аудиторию, которая только начинает работать с golang

Не возникает делима где логировать 27:05 ошибку, она всегда должна логироваться, она должна логироваться там где происходит. Это бред какой-то логировать её где-то на нижних уровнях. Представь, что ты используешь стороннюю библиотеку и она вместо того чтобы залогировать какую-то ошибку в себе, прокалывание её наверх, чтобы ты сам решал логировать её или нет. Такого я ни разу не видел в жизни. Да и логируется всегда весь контекс и стектрейс, который есть только в месте возникновения ошибки. Я посмотрел лекцию до конца и видел вариант с добавлением в специально созданную структуру контекста, но это лютая дичь! Вернёмся к моему другому примеру с 5000 логов, тебе нужно будет сделать 5000 обвёрток и чуть меньше структур для прокидывания контекста наверх? А сколько принципов программирования и проектирования это нарушает? +-10 штук. А если у тебя часть кода будет лежать в одном модуле, а часть в другом, нужно будет в вызывающем модуле всё логировать? А если его начнут использовать ещё кто-то? Да и бред про устоявшуюся команду меня паразил. А что если ваш сторожила уволится? Да и возвращать ошибку на каждом уровне это ещё тот спагетти. Уже давно выработан подход к обработке ошибок, почитайте книгу Чистый код, главу про обработку ошибок, когда возникает ошибка, она сразу логируется и возвращается исключение, которое перехватывается где-то на верхнем уровне. Да, в го нет исключений, но есть паники, которыми можно реализовать тот же самый подход. Такой бы код (даже с учётом примеров) у меня никогда бы не прошёл ревью. В общем, лекция хорошая для новичков, кто вообще не знает о структурировании легировании, но для опытных она будет бесполезной.

@sergeykosovsky7005

25 күн бұрын

паниками реализовывать исключение - ты чего)) это очень дорого, поэтому бессмысленно

Зачем 15 минут заставок?

cfbr

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

@MichurinTube

Ай бұрын

Привет, не совсем так. Одна функция на ключ, а не на файл )

Thanks and Good Luck!