Согласен. Но, кажется, к врапанью надо было как-то специально идти лет 7 назад. Сейчас, когда есть %w и вкусняшки типа As, Is и даже errors.Join, - сам язык и стандартная библиотека тебя толкает к врапанью.
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 | Финал и ответы на вопросы в чате
Прикольно смотреть, как меняется подходы к разработке. Ранее вот эти примеры использовались, чтоб на собеседовании спрашивать какие SOLID принципы здесь нарушаются. Очень много вопросов возникает после просмотра, жаль не удалось посмотреть в прямом эфире. - Почему логгер(интерфейсный слой) знает о какой-то бизнес логике? Если проблема лишь в том что какой-то программист захочет назвать поле по другому, что мешает этому программисту создать другую структуру данных? П.С. Из ваших слов в авито вы прокидываете мапу, тогда не понятно зачем пример с структурами... - Зачем засорять контекст данными? Я думаю вытекающие проблемы понятны - Почему выбрали именно slog? Честно ожидал что будет как "Jaeger для трассировки в микросервисной архитектуре", а вышла на аудиторию, которая только начинает работать с golang
Из 7-го глупого примера! В самом верху логировать ошибку, чтобы не забыть залогировать ошибку, вообще-то ошибки еще нужно обрабатывать и в какую архитектуру это влезет(имею в виду все эти 100500 враперов)?
Не возникает делима где логировать 27:05 ошибку, она всегда должна логироваться, она должна логироваться там где происходит. Это бред какой-то логировать её где-то на нижних уровнях. Представь, что ты используешь стороннюю библиотеку и она вместо того чтобы залогировать какую-то ошибку в себе, прокалывание её наверх, чтобы ты сам решал логировать её или нет. Такого я ни разу не видел в жизни. Да и логируется всегда весь контекс и стектрейс, который есть только в месте возникновения ошибки. Я посмотрел лекцию до конца и видел вариант с добавлением в специально созданную структуру контекста, но это лютая дичь! Вернёмся к моему другому примеру с 5000 логов, тебе нужно будет сделать 5000 обвёрток и чуть меньше структур для прокидывания контекста наверх? А сколько принципов программирования и проектирования это нарушает? +-10 штук. А если у тебя часть кода будет лежать в одном модуле, а часть в другом, нужно будет в вызывающем модуле всё логировать? А если его начнут использовать ещё кто-то? Да и бред про устоявшуюся команду меня паразил. А что если ваш сторожила уволится? Да и возвращать ошибку на каждом уровне это ещё тот спагетти. Уже давно выработан подход к обработке ошибок, почитайте книгу Чистый код, главу про обработку ошибок, когда возникает ошибка, она сразу логируется и возвращается исключение, которое перехватывается где-то на верхнем уровне. Да, в го нет исключений, но есть паники, которыми можно реализовать тот же самый подход. Такой бы код (даже с учётом примеров) у меня никогда бы не прошёл ревью. В общем, лекция хорошая для новичков, кто вообще не знает о структурировании легировании, но для опытных она будет бесполезной.
Представь, что ты используешь стороннюю библиотеку и она вместо того чтобы прокинуть ошибку наверх, чтобы ты сам решал логировать её или нет, логирует её в себе. Такого я ни разу не видел в жизни.
Смешно говорит, что код безупречен, а в нём десяток функций которые просто логируют. Так, если в приложении будет 10000 файлов и 5000 комментариев, нужно будет сделать 5000 функций обвёрток для лога?
