Стиль изложения похож на тот, который используется для написания небольших художественных историй в интернетах. Обтекаемые / лощеные предложения. Поэтому подумалось, что это художественный рассказ, плюс длинные тире. Кстати заметка по новой ссылке - в более рубленном стиле, хотя и там тоже есть длинные тире.
Не надо холиварить. Лучшие продукты, которые я делал в лучших командах - это когда аналитик немного залезает в разработку и ориентируется там, а программист - в аналитику. Как бы с перехлестом.
Я однажды работал с крутым бизнес/системным аналитиком - у нее описания были такие, что 80% можно было просто кодить как написано. Но все равно по завершению разработки мы с ней сели, на одном экране открыли тз, на другом код и прошлись. Нашли несоответствия и поправили либо код, либо уточнили описание в тз
Статья и коменты, к сожалению, лишний раз подтверждают, что hr как риэлторы-вахтеры.
Плюс конфликт мышления, мужской / женской логики, iq и критического мышления (настроить ats и не удостоверится, что она правильно работает - это ж каким тупым надо быть?(
Одновременно с этим - такой риэлтор-вахтер имеет социоально-значимую роль - люди ищут работу, чтобы выживать.
В противовес могу сказать, что за 20 лет встретил несколько раз действительно крутых hr. С ними было приятно работать.
И хорошо, что ведется хоть какая-то работа по улучшению ситуации.
Потому что кубернетс сделали в Гугле, чтобы управлять своей флотилией серверов. Вряд ли автор работает в Гугле
Можно конечно настроить кубернетс для своих 1.5 микросервиса, но это как из пушки по воробьям. Кубернетс сам по себе - сложная штука. А даже простой переход на докеры - это кратный рост затрат на инфраструктуру и зарплаты дев опсов.
Интересно причем тут маркетолог? Это он типа решил в одно рыло сделать электромобиль и все его молча послушались? Или все же топ-менеджменту в голу пришла гениальная идея и назначили маркетолога козлом отпущения?
Так-то электромобиль и феррари с 6 литровыми атмосферными V12 - вызывает когнитивный диссонанс
Для баланса - однажды тоже довелось сделать поддержку двух бд - oracle и ms sql. Но был c# + nhibernate. Все прошло гладко, за 3 часа. Но было это 3000 лет назад.
И как я уже писал недавно в коментах - на том проекте еще был store procedure api (как rest api, только хранимки). Из-за того что следил, чтобы код держали близко к старому стандарту типа sql 92 - потребовались незначительные изменения.
Продукт был в банковской сфере, кодили его 5 программистов. Это чтоб примерно понимать сложность.
Хороший вопрос, так то DDD в принципе имеет проблемы с БД. Когда начинается борьба за производительность - и например логику начинают переносить в хранимки - это начинает нарушать DDD.
Конкретно у меня был опыт перехода на другую БД. Точнее задача стояла даже чуть по-другому - поддерживать ДВЕ БД одновременно. Но по правде сказать, ситуацию облегчало то, что обе были SQL. Но вместе с тем, усложняло то, что на том проекте был Store Procedure API, вот как REST API, только это на хранимках.
У меня были repository + nhibernate внутри репозиториев, наружу он не торчал. База была Oracle, а надо было MS SQL. Но ORM тут помогла в плане - она "переписала" за нас все SQL запросы. Ну то есть, если бы не было ORM - просто пришлось бы руками переписать, потратили бы больше времени. Бизнес слой и выше - не был затронут вообще.
И да, это было 3000 лет назад - там был банковско-содержащий продукт (в смысле это была не АБС, а попроще). У банков тогда был в основном oracle 10-ой версии, у некоторых 11-ый, а вот клиент, который пришел чуть позже - хотел MS SQL 2008.
А вот с Store Procedure API было чуть интересней. Так вышло, что я там заранее принял решение использовать в хранимках максимально старый и максимально общий SQL стандарт - ну типа 92 года и запретил использовать уникальные вещи конкретной БД (например в oracle 10 были интересные недокументированные функций по работе с иерархическими данными). И следил за этим.
В итоге мы отделили версию Store Procedure API для MS SQL, но там почти ничего не пришлось править, кроме вещей типа SELECT TOP N. И транзакции вроде сразу заработали, по крайней мере я не помню проблем. Даже если и были - решились легко значит.
но это противоречит принципам EF и приводит к неоптимальному коду
Ну на двух стульях не получится усидеть, либо классический репозиторий, где в потенциально можно абстрагироваться от хранилища (потому что репо возвращает бизнес объекты и DTO). Либо по максимуму использовать удобства конкретной ORM, в том числе, в мире C# - тот самый IQueryable.
Интересно, что народ в целом согласен, что IQueryable создает проблемы, но то что сама ORM тоже создает определенные проблемы - с этим типа мирятся. Ну хозяин барин.
Добавлю - пожалуй orm типа ef и репозиторий даже в какой то мере мешают друг другу.
Это хорошо видно на методе update. В классическом репозитории - туда приходит dto и внутри формируется sql запрос update. В случае с ef, если был включен трекинг - метод update вырождается до вызова save changes. А если еще есть транзакционная обвязка, то метод update вообще пустой, потому что save changes вызывается где-то выше по стеку, там где begin / commit transaction
А версия no sql была без ef? Как бы получается, что вопросы эти касаются именно ef. Грубо говоря, для get-by-id - если в первой реализации вы не трекали изменения, значит во второй используете as-no-tracking
Все же чистый репозиторий (в том числе без всяких дженериков) + unit of work дает больше гибкости, чем orm или связка репозиторий + orm внутри.
Стиль изложения похож на тот, который используется для написания небольших художественных историй в интернетах. Обтекаемые / лощеные предложения. Поэтому подумалось, что это художественный рассказ, плюс длинные тире. Кстати заметка по новой ссылке - в более рубленном стиле, хотя и там тоже есть длинные тире.
Не надо холиварить. Лучшие продукты, которые я делал в лучших командах - это когда аналитик немного залезает в разработку и ориентируется там, а программист - в аналитику. Как бы с перехлестом.
Я однажды работал с крутым бизнес/системным аналитиком - у нее описания были такие, что 80% можно было просто кодить как написано. Но все равно по завершению разработки мы с ней сели, на одном экране открыли тз, на другом код и прошлись. Нашли несоответствия и поправили либо код, либо уточнили описание в тз
Статья и коменты, к сожалению, лишний раз подтверждают, что hr как риэлторы-вахтеры.
Плюс конфликт мышления, мужской / женской логики, iq и критического мышления (настроить ats и не удостоверится, что она правильно работает - это ж каким тупым надо быть?(
Одновременно с этим - такой риэлтор-вахтер имеет социоально-значимую роль - люди ищут работу, чтобы выживать.
В противовес могу сказать, что за 20 лет встретил несколько раз действительно крутых hr. С ними было приятно работать.
И хорошо, что ведется хоть какая-то работа по улучшению ситуации.
Это художественный вымысел приправленный чатом гпт или все же реальная история? Слишком все идеально…
❌ Оптимизировать код, который открывает меню Пуск (оно же нормально работало на windows 95 c пнем 200 МГц)
✅ Реализовать особый режим перехвата клика мышки и повышать частоту CPU до 3 ГГц
Так-то, там вместо Васи должен быть Клод
Картинка
Потому что кубернетс сделали в Гугле, чтобы управлять своей флотилией серверов. Вряд ли автор работает в Гугле
Можно конечно настроить кубернетс для своих 1.5 микросервиса, но это как из пушки по воробьям. Кубернетс сам по себе - сложная штука. А даже простой переход на докеры - это кратный рост затрат на инфраструктуру и зарплаты дев опсов.
Короче, сначала надо провести бизнес-анализ законов и разгрести легаси там. Ну а потом уже можно взяться за разработку софта /s
Интересно причем тут маркетолог? Это он типа решил в одно рыло сделать электромобиль и все его молча послушались? Или все же топ-менеджменту в голу пришла гениальная идея и назначили маркетолога козлом отпущения?
Так-то электромобиль и феррари с 6 литровыми атмосферными V12 - вызывает когнитивный диссонанс
Для баланса - однажды тоже довелось сделать поддержку двух бд - oracle и ms sql. Но был c# + nhibernate. Все прошло гладко, за 3 часа. Но было это 3000 лет назад.
И как я уже писал недавно в коментах - на том проекте еще был store procedure api (как rest api, только хранимки). Из-за того что следил, чтобы код держали близко к старому стандарту типа sql 92 - потребовались незначительные изменения.
Продукт был в банковской сфере, кодили его 5 программистов. Это чтоб примерно понимать сложность.
Кубернетс для геологов? Звучит как оверинжиниринг.
Не успел)
Зумеры в Гнусмасе придумали Nokia 7280 😄
А под фоткой отметились миллениалы и старше
Хороший вопрос, так то DDD в принципе имеет проблемы с БД. Когда начинается борьба за производительность - и например логику начинают переносить в хранимки - это начинает нарушать DDD.
Конкретно у меня был опыт перехода на другую БД. Точнее задача стояла даже чуть по-другому - поддерживать ДВЕ БД одновременно. Но по правде сказать, ситуацию облегчало то, что обе были SQL. Но вместе с тем, усложняло то, что на том проекте был Store Procedure API, вот как REST API, только это на хранимках.
У меня были repository + nhibernate внутри репозиториев, наружу он не торчал. База была Oracle, а надо было MS SQL. Но ORM тут помогла в плане - она "переписала" за нас все SQL запросы. Ну то есть, если бы не было ORM - просто пришлось бы руками переписать, потратили бы больше времени. Бизнес слой и выше - не был затронут вообще.
И да, это было 3000 лет назад - там был банковско-содержащий продукт (в смысле это была не АБС, а попроще). У банков тогда был в основном oracle 10-ой версии, у некоторых 11-ый, а вот клиент, который пришел чуть позже - хотел MS SQL 2008.
А вот с Store Procedure API было чуть интересней. Так вышло, что я там заранее принял решение использовать в хранимках максимально старый и максимально общий SQL стандарт - ну типа 92 года и запретил использовать уникальные вещи конкретной БД (например в oracle 10 были интересные недокументированные функций по работе с иерархическими данными). И следил за этим.
В итоге мы отделили версию Store Procedure API для MS SQL, но там почти ничего не пришлось править, кроме вещей типа SELECT TOP N. И транзакции вроде сразу заработали, по крайней мере я не помню проблем. Даже если и были - решились легко значит.
Ну на двух стульях не получится усидеть, либо классический репозиторий, где в потенциально можно абстрагироваться от хранилища (потому что репо возвращает бизнес объекты и DTO). Либо по максимуму использовать удобства конкретной ORM, в том числе, в мире C# - тот самый IQueryable.
Интересно, что народ в целом согласен, что IQueryable создает проблемы, но то что сама ORM тоже создает определенные проблемы - с этим типа мирятся. Ну хозяин барин.
Добавлю - пожалуй orm типа ef и репозиторий даже в какой то мере мешают друг другу.
Это хорошо видно на методе update. В классическом репозитории - туда приходит dto и внутри формируется sql запрос update. В случае с ef, если был включен трекинг - метод update вырождается до вызова save changes. А если еще есть транзакционная обвязка, то метод update вообще пустой, потому что save changes вызывается где-то выше по стеку, там где begin / commit transaction
А версия no sql была без ef? Как бы получается, что вопросы эти касаются именно ef. Грубо говоря, для get-by-id - если в первой реализации вы не трекали изменения, значит во второй используете as-no-tracking
Все же чистый репозиторий (в том числе без всяких дженериков) + unit of work дает больше гибкости, чем orm или связка репозиторий + orm внутри.
Один раз случайность, два - совпадение, три - … 😀
Но в случае с flannery_gold там сильнее заметно, а тут только одна эта последовательность выдала
А как становятся таким людьми, а? Как они все это придумывают?
«В гости со своим самоваром не ходят» 😀
Кажется этот комент написан чатом гпт