классный видос. Спасибо. Круто что в контексте чистой архитектуры рассмотрели тестирование. Но хочется дальше. Самое интересное же. Тестирование АПИ и E2E тесты. Буду ждать следующий видос )
Спасибо за видео! Очень полезно было узнать что-то новое и получить ещё большую мотивацию их писать) P.S. Очень хотелось бы видео по чистой архитектуре с примерами (я её использую, но боюсь что не совсем правильно).
плюсую, сам хотел только что коммент на эту тему оставить. И если можно, то хочется прояснить тему внутрисервисных транзакций. Хотелось бы на уровне бизнес логики диктовать, нужна ли транзакция.
Видео супер! в юнит тестах actual и expected ошибки надо местами поменять. У вас в expected реальная ошибка (должно быть ожидаемая), а в actual ожидаемая (должно быть настоящая)
Спасибо за труд! Доходчиво, качественно... правда, были моменты, когда кода не видно было... С тестами только знакомлюсь... хотелось бы побольше узнать по 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 тесты. Буду ждать следующий видос )
Спасибо за видео!
Очень полезно было узнать что-то новое и получить ещё большую мотивацию их писать)
P.S. Очень хотелось бы видео по чистой архитектуре с примерами (я её использую, но боюсь что не совсем правильно).
плюсую, сам хотел только что коммент на эту тему оставить. И если можно, то хочется прояснить тему внутрисервисных транзакций. Хотелось бы на уровне бизнес логики диктовать, нужна ли транзакция.
Видео очень полезное, иногда возвращаюсь к нему, чтобы что-то вспомнить.
Спасибо! Было интересно. Надеюсь будет продолжение.
Видео супер!
в юнит тестах actual и expected ошибки надо местами поменять. У вас в expected реальная ошибка (должно быть ожидаемая), а в actual ожидаемая (должно быть настоящая)
Большое спасибо, очень полезно. Буду рад продолжению
Просто, понятно, полезно! Круто, что материал дан в контексте архитектуры! Спасибо!
Да, тема тестирования и рефакторинга очень интересная
Респект автору! Было интересно.
Большое спасибо за видео, сделайте еще продолжение!!!
Спасибо за труд! Доходчиво, качественно... правда, были моменты, когда кода не видно было... С тестами только знакомлюсь... хотелось бы побольше узнать по fake, stub и mock, причем с примерами пожестче... без библиотек.
Очень круто!! Спасибо за большую работу! Я пишу на руби и интересно как работают в других языках, в рубях очень крутой rspec )
Спасибо. Очень крутой урок
Спасибо, все очень лаконично, полезно и по делу!
В целом := очень интересно. Но звучат странные фразы, например := "Мы не можем всё время держать базу чтобы гонять тесты". Ну блин если в озоне на это ресурсов нет, то я хз, надо из айти уходить наверное panic("Remowe all work"). Достаточно просто вроде собрать docker-compose. И делать up -d а потом down -v. Вот мы и стали мочь гонять тесты с поднятой рядом СУБД. А если учесть, что - это всё МС архитектура. Так в докер-композе у нас одна БД и максимум сверху + кафка/кролик, редис, s3, sso, nginx и gateway. И вроде бы мы не на расбери пай код кодим то. Чё нет то?
А я уже знаю чё нет то - схема := бублик и каноны. А возможность
Спасибо за видео!
Люди которые пользуются белой темой оказываются существуют.
Меня за это часто подъё, но я на темной вообще ничего не вижу, могу пользоваться только светлой, так что да, мы существуем)
Спасибо. Сделайте пожалуйста обучалку по чистой архитектуре в контексе языка Golang
Пишу в комментариях. Посмотрел 2 видео, отличный материал.
Спасибо очень полезно было.
Повезло мне с вашим каналом ❤
Ждём следующую часть
Очень полезный контент! Спасибо! Было классно если будет продолжение данного видео. Хотелось бы очень капнуть глубже. Все тесты, которые мы сегодня писали являются Unit Tests, правильно я понял ?
Да, в этот раз только юнит тесты, Сейчас вышло второе видео с интеграционными тестами.
Спасибо
спасибо большое
Там что, GET с телом запроса? 🤔 PS. Спасибо!
полезно. спасибо
Как тема называется в вскоде?
что за клавиатура? звук просто офигенный!
Тема в vs code какая?
Доброго дня!
Почему в валидации стоимость и юзер айди не проверяем на отрицательные значения, а только на ноль?
мб потому что это написанный на коленке простой пример?
Для user_id, amount использовал uint64, на json.Unmarshal сломается, и вернет ошибку, даже не дойдя до валидации:
```bad json: json: cannot unmarshal number -1 into Go struct field OrderIn.user_id of type uint64```
кайф
Сложно понять что такое entities :)
Чем больше я вникаю в тему юнит-тестирования, тем больше убеждаюсь что это хлопотная суета и практически бесполезная. Чтобы в базу мусор не попал нужно констрейны в базе делать. И они гарантируют отсутствие в базе мусора, не только предотвращают в будущем, но и гарантируют, что он не попал туда в прошлом.
Ошибок в тестах у вас было на порядок больше чем в коде. И это были настоящие ошибки, а не намеренно допущенные для примера. От реальных багов, то есть не предусмотренных программистом ситуаций, тесты, написанные им же не могут спасти по определению. И только ради тестов нагромождение абстракций, интерфейсов моков. Проект уровня бумажный самолетик превращается боинг по сложности, срокам и цене.
можете привести пример ошибок в тестах?
Awesome
почему вЁб? :)
Это все интересно конечно)) А как в GO с зарплатами ручников?))
каво? какие ручники)
Саш, у тебя полка книжная сломалась :-)))
Гошечка, ideшечка,кейсик, табличка, ошибочка, слайсик, idшечка, тестики, юзкейсик.
Боже, что с го разрабами не так, объясните плз откуда это пришло)
Стоило немножко подготовиться к презентации, диаграмма приведенная из чистой архитектуры представлена очень малым набором признаков. То есть - не понятно что автор имеет ввиду под астрацией бизнес логики и что под абстракцией контроллеров. Entity так вообще не объяснено ничем, кроме как - ну это сущности... Очевидная ошибка логики.
А что бы быть golang разработчиком обязательно быть хипстером? Спасибо за видео.
11:30 мои глаза
люди со светлым стилем IDE, ЗАЧЕМ?!
Чтоб читать лучше было на ютубе, нет? Не у всех какой-нибудь там олед экран. На дешёвых экранах вообще ничего не видно на тёмном фоне
Когда работаешь в светлой, хорошо освещенной комнате, тогда удобней работать со светлой темой IDE.
А тупо так привычнее!
И ещё темы меняются под освещение, настроение, тип экрана…
ну затем, что не только ночью люди работают. а видео с темными темами невозможно смотреть, плохо видно код.
тестик в слайсик
заказик, апишечка, дежйсончик - это московский сленг?
Ещё интересно, что такое ручка? Неужели это хендлер?
@@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.