классный видос. Спасибо. Круто что в контексте чистой архитектуры рассмотрели тестирование. Но хочется дальше. Самое интересное же. Тестирование АПИ и E2E тесты. Буду ждать следующий видос )
Видео супер! в юнит тестах actual и expected ошибки надо местами поменять. У вас в expected реальная ошибка (должно быть ожидаемая), а в actual ожидаемая (должно быть настоящая)
Спасибо за видео! Очень полезно было узнать что-то новое и получить ещё большую мотивацию их писать) P.S. Очень хотелось бы видео по чистой архитектуре с примерами (я её использую, но боюсь что не совсем правильно).
плюсую, сам хотел только что коммент на эту тему оставить. И если можно, то хочется прояснить тему внутрисервисных транзакций. Хотелось бы на уровне бизнес логики диктовать, нужна ли транзакция.
Спасибо за труд! Доходчиво, качественно... правда, были моменты, когда кода не видно было... С тестами только знакомлюсь... хотелось бы побольше узнать по fake, stub и mock, причем с примерами пожестче... без библиотек.
В целом := очень интересно. Но звучат странные фразы, например := "Мы не можем всё время держать базу чтобы гонять тесты". Ну блин если в озоне на это ресурсов нет, то я хз, надо из айти уходить наверное panic("Remowe all work"). Достаточно просто вроде собрать docker-compose. И делать up -d а потом down -v. Вот мы и стали мочь гонять тесты с поднятой рядом СУБД. А если учесть, что - это всё МС архитектура. Так в докер-композе у нас одна БД и максимум сверху + кафка/кролик, редис, s3, sso, nginx и gateway. И вроде бы мы не на расбери пай код кодим то. Чё нет то? А я уже знаю чё нет то - схема := бублик и каноны. А возможность
Очень полезный контент! Спасибо! Было классно если будет продолжение данного видео. Хотелось бы очень капнуть глубже. Все тесты, которые мы сегодня писали являются Unit Tests, правильно я понял ?
Для user_id, amount использовал uint64, на json.Unmarshal сломается, и вернет ошибку, даже не дойдя до валидации: ```bad json: json: cannot unmarshal number -1 into Go struct field OrderIn.user_id of type uint64```
Чем больше я вникаю в тему юнит-тестирования, тем больше убеждаюсь что это хлопотная суета и практически бесполезная. Чтобы в базу мусор не попал нужно констрейны в базе делать. И они гарантируют отсутствие в базе мусора, не только предотвращают в будущем, но и гарантируют, что он не попал туда в прошлом. Ошибок в тестах у вас было на порядок больше чем в коде. И это были настоящие ошибки, а не намеренно допущенные для примера. От реальных багов, то есть не предусмотренных программистом ситуаций, тесты, написанные им же не могут спасти по определению. И только ради тестов нагромождение абстракций, интерфейсов моков. Проект уровня бумажный самолетик превращается боинг по сложности, срокам и цене.
Стоило немножко подготовиться к презентации, диаграмма приведенная из чистой архитектуры представлена очень малым набором признаков. То есть - не понятно что автор имеет ввиду под астрацией бизнес логики и что под абстракцией контроллеров. Entity так вообще не объяснено ничем, кроме как - ну это сущности... Очевидная ошибка логики.
@@Аудиокниги-г8д может и знает. Использование понятия ручка я встречал во многих компаниях, в том числе в Озоне и Яндексе, начал даже считать что все продвинутые компании в России пользуются этим словом. Тогда как более мелкие и простые компании оперируют понятиями endpoint, handler
@@OOOJohnJ это просто показывает безграмотность. Да черт с ней с ручкой, но что за новопи-рский сленг, вроде бы программисты должны быть интеллигенцией, но не могут нормально даже говорить.
@@Аудиокниги-г8д мне кажется больше дело привычки. Мне вот "ручка" тоже ухо режет, хотя постепенно привыкаю. На мой взгляд, если и называть по-русски, то более подходящее слово лучше найти.
Всё конечно классно... Но как pkg попал в internal ??? Со структурой проекта вообще ахтунг какой-то... У папки Internal есть чёткий смысл - она выполняет ещё один вид инкапсуляции в случае если находится внутри вложенного пакета. У меня кровь из глаз... а я джун... не надо так ((( Структура проекта нарушает Standart Layout и вообще не пойми чем обусловлена. Договорились же видеть 3 папки: cmd, internal, pkg. И pkg - общие пакеты, возможные для использования в других проектах... Куда какой тест пихать в такой структуре? Где доменная область, где транспортная, где репо... Убейте меня! А ещё под слоем UseCase обычно есть слой Service, тогда сервис работает с сущностью, а UseCase работает с методами сущностей....
Project layout о pkg в internal: Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).
@@SecretSecret-c7o именно, Сашенька) code shared for those apps ) но у нас тут нет apps ) папка pkg на одном уровне с cmd - общий код для программ в cmd. А папка pkg в интернал - общий код для програм в интернал ) В данном случае, во-первых, это вообще аццкий лейаут, который я вообще за год никогда не видел, а во-вторых - он не логичный с точки зрения слоёв.
@@SecretSecret-c7o ты бы сам понял в таком наборе папок где какая сущность и сервис? Как они связаны? Как отделены? Смысл вообще не в стандарт лейаут, хотя и он не зря сделан, а в том, что тут вообще логика потеряна. Почему main.go лучше класть в папку вложенную в cmd знаешь? А почему usecase лучше держать на том же уровне, что и app? Когда ты видишь слоистость в уровне и месте вложенности папок, тебе на много проще программировать и любому другому, кто придёт после тебя.
ты же в курсе, что "project standard layout" - не стандартный layout? Даже rsc создал issue в этом репозитории, потому что люди ошибочно считают это каким-то стандартном. Это во-первых. А во-вторых, структура проекта - очень субъективно. Мне кажется, в go сообществе недостаточно *официальных* руководств по наименованию пакетов и оформлению структур проекта, поэтому каждый оформляет как он хочет. Я к тому, что это общая проблема, и пока не будет действий от разработчиков языка, то придётся видеть разные реализации структур. Кмк, спорить на эту тему лишено смысла.
В смысле вы не увидели репо, транспорт и домен? Я не знаю как вы смотрели, но там же прямо написано "repository", "user case" "handlers". Может оно названо чуть по другому, но смысл выполняют тот же. Не верите мне - посмотрите доклад по структуре проекта от evrone.
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
экстримЦодовец
классный видос. Спасибо. Круто что в контексте чистой архитектуры рассмотрели тестирование. Но хочется дальше. Самое интересное же. Тестирование АПИ и E2E тесты. Буду ждать следующий видос )
Видео супер!
в юнит тестах actual и expected ошибки надо местами поменять. У вас в expected реальная ошибка (должно быть ожидаемая), а в actual ожидаемая (должно быть настоящая)
Видео очень полезное, иногда возвращаюсь к нему, чтобы что-то вспомнить.
Спасибо! Было интересно. Надеюсь будет продолжение.
Спасибо за видео!
Очень полезно было узнать что-то новое и получить ещё большую мотивацию их писать)
P.S. Очень хотелось бы видео по чистой архитектуре с примерами (я её использую, но боюсь что не совсем правильно).
плюсую, сам хотел только что коммент на эту тему оставить. И если можно, то хочется прояснить тему внутрисервисных транзакций. Хотелось бы на уровне бизнес логики диктовать, нужна ли транзакция.
Большое спасибо, очень полезно. Буду рад продолжению
Да, тема тестирования и рефакторинга очень интересная
Спасибо. Сделайте пожалуйста обучалку по чистой архитектуре в контексе языка Golang
Просто, понятно, полезно! Круто, что материал дан в контексте архитектуры! Спасибо!
Очень круто!! Спасибо за большую работу! Я пишу на руби и интересно как работают в других языках, в рубях очень крутой rspec )
Респект автору! Было интересно.
Большое спасибо за видео, сделайте еще продолжение!!!
Люди которые пользуются белой темой оказываются существуют.
Меня за это часто подъё, но я на темной вообще ничего не вижу, могу пользоваться только светлой, так что да, мы существуем)
Спасибо за труд! Доходчиво, качественно... правда, были моменты, когда кода не видно было... С тестами только знакомлюсь... хотелось бы побольше узнать по fake, stub и mock, причем с примерами пожестче... без библиотек.
В целом := очень интересно. Но звучат странные фразы, например := "Мы не можем всё время держать базу чтобы гонять тесты". Ну блин если в озоне на это ресурсов нет, то я хз, надо из айти уходить наверное panic("Remowe all work"). Достаточно просто вроде собрать docker-compose. И делать up -d а потом down -v. Вот мы и стали мочь гонять тесты с поднятой рядом СУБД. А если учесть, что - это всё МС архитектура. Так в докер-композе у нас одна БД и максимум сверху + кафка/кролик, редис, s3, sso, nginx и gateway. И вроде бы мы не на расбери пай код кодим то. Чё нет то?
А я уже знаю чё нет то - схема := бублик и каноны. А возможность
Спасибо, все очень лаконично, полезно и по делу!
Спасибо. Очень крутой урок
Пишу в комментариях. Посмотрел 2 видео, отличный материал.
Спасибо за видео!
Спасибо очень полезно было.
Повезло мне с вашим каналом ❤
Ждём следующую часть
Очень полезный контент! Спасибо! Было классно если будет продолжение данного видео. Хотелось бы очень капнуть глубже. Все тесты, которые мы сегодня писали являются Unit Tests, правильно я понял ?
Да, в этот раз только юнит тесты, Сейчас вышло второе видео с интеграционными тестами.
Спасибо
полезно. спасибо
спасибо большое
Там что, GET с телом запроса? 🤔 PS. Спасибо!
что за клавиатура? звук просто офигенный!
Как тема называется в вскоде?
Тема в vs code какая?
Сложно понять что такое entities :)
кайф
Awesome
Доброго дня!
Почему в валидации стоимость и юзер айди не проверяем на отрицательные значения, а только на ноль?
мб потому что это написанный на коленке простой пример?
Для user_id, amount использовал uint64, на json.Unmarshal сломается, и вернет ошибку, даже не дойдя до валидации:
```bad json: json: cannot unmarshal number -1 into Go struct field OrderIn.user_id of type uint64```
Саш, у тебя полка книжная сломалась :-)))
почему вЁб? :)
Чем больше я вникаю в тему юнит-тестирования, тем больше убеждаюсь что это хлопотная суета и практически бесполезная. Чтобы в базу мусор не попал нужно констрейны в базе делать. И они гарантируют отсутствие в базе мусора, не только предотвращают в будущем, но и гарантируют, что он не попал туда в прошлом.
Ошибок в тестах у вас было на порядок больше чем в коде. И это были настоящие ошибки, а не намеренно допущенные для примера. От реальных багов, то есть не предусмотренных программистом ситуаций, тесты, написанные им же не могут спасти по определению. И только ради тестов нагромождение абстракций, интерфейсов моков. Проект уровня бумажный самолетик превращается боинг по сложности, срокам и цене.
можете привести пример ошибок в тестах?
Это все интересно конечно)) А как в GO с зарплатами ручников?))
каво? какие ручники)
Гошечка, ideшечка,кейсик, табличка, ошибочка, слайсик, idшечка, тестики, юзкейсик.
Боже, что с го разрабами не так, объясните плз откуда это пришло)
Стоило немножко подготовиться к презентации, диаграмма приведенная из чистой архитектуры представлена очень малым набором признаков. То есть - не понятно что автор имеет ввиду под астрацией бизнес логики и что под абстракцией контроллеров. Entity так вообще не объяснено ничем, кроме как - ну это сущности... Очевидная ошибка логики.
11:30 мои глаза
люди со светлым стилем IDE, ЗАЧЕМ?!
Чтоб читать лучше было на ютубе, нет? Не у всех какой-нибудь там олед экран. На дешёвых экранах вообще ничего не видно на тёмном фоне
Когда работаешь в светлой, хорошо освещенной комнате, тогда удобней работать со светлой темой IDE.
А тупо так привычнее!
И ещё темы меняются под освещение, настроение, тип экрана…
ну затем, что не только ночью люди работают. а видео с темными темами невозможно смотреть, плохо видно код.
А что бы быть golang разработчиком обязательно быть хипстером? Спасибо за видео.
тестик в слайсик
заказик, апишечка, дежйсончик - это московский сленг?
Ещё интересно, что такое ручка? Неужели это хендлер?
@@artemkas4191 да, это хендлер. Автор не знает нормального названия.
@@Аудиокниги-г8д может и знает. Использование понятия ручка я встречал во многих компаниях, в том числе в Озоне и Яндексе, начал даже считать что все продвинутые компании в России пользуются этим словом. Тогда как более мелкие и простые компании оперируют понятиями endpoint, handler
@@OOOJohnJ это просто показывает безграмотность. Да черт с ней с ручкой, но что за новопи-рский сленг, вроде бы программисты должны быть интеллигенцией, но не могут нормально даже говорить.
@@Аудиокниги-г8д мне кажется больше дело привычки. Мне вот "ручка" тоже ухо режет, хотя постепенно привыкаю. На мой взгляд, если и называть по-русски, то более подходящее слово лучше найти.
Всё конечно классно... Но как pkg попал в internal ??? Со структурой проекта вообще ахтунг какой-то... У папки Internal есть чёткий смысл - она выполняет ещё один вид инкапсуляции в случае если находится внутри вложенного пакета.
У меня кровь из глаз... а я джун... не надо так ((( Структура проекта нарушает Standart Layout и вообще не пойми чем обусловлена. Договорились же видеть 3 папки: cmd, internal, pkg. И pkg - общие пакеты, возможные для использования в других проектах...
Куда какой тест пихать в такой структуре? Где доменная область, где транспортная, где репо... Убейте меня!
А ещё под слоем UseCase обычно есть слой Service, тогда сервис работает с сущностью, а UseCase работает с методами сущностей....
Project layout о pkg в internal: Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).
@@SecretSecret-c7o именно, Сашенька) code shared for those apps ) но у нас тут нет apps )
папка pkg на одном уровне с cmd - общий код для программ в cmd. А папка pkg в интернал - общий код для програм в интернал )
В данном случае, во-первых, это вообще аццкий лейаут, который я вообще за год никогда не видел, а во-вторых - он не логичный с точки зрения слоёв.
@@SecretSecret-c7o ты бы сам понял в таком наборе папок где какая сущность и сервис? Как они связаны? Как отделены?
Смысл вообще не в стандарт лейаут, хотя и он не зря сделан, а в том, что тут вообще логика потеряна. Почему main.go лучше класть в папку вложенную в cmd знаешь? А почему usecase лучше держать на том же уровне, что и app?
Когда ты видишь слоистость в уровне и месте вложенности папок, тебе на много проще программировать и любому другому, кто придёт после тебя.
ты же в курсе, что "project standard layout" - не стандартный layout? Даже rsc создал issue в этом репозитории, потому что люди ошибочно считают это каким-то стандартном. Это во-первых. А во-вторых, структура проекта - очень субъективно.
Мне кажется, в go сообществе недостаточно *официальных* руководств по наименованию пакетов и оформлению структур проекта, поэтому каждый оформляет как он хочет. Я к тому, что это общая проблема, и пока не будет действий от разработчиков языка, то придётся видеть разные реализации структур. Кмк, спорить на эту тему лишено смысла.
В смысле вы не увидели репо, транспорт и домен? Я не знаю как вы смотрели, но там же прямо написано "repository", "user case" "handlers". Может оно названо чуть по другому, но смысл выполняют тот же. Не верите мне - посмотрите доклад по структуре проекта от evrone.