Тут согласен. Но разработка ведется прям оч активно
Касаемо рестарта сервисов - как раз в статье была ссылка - там ишью прям в приоритете сейчас разрабатывается, думаю в ближайшей версии добавят. Тут как раз таки круто, что т.к проект новый, можно набрасывать на официальную репу идеи, и если они годные, то их достаточно быстро будут реализовывать
Не используется данный по подход по простой причине - излишний оверинжиниринг и решение несуществующей проблемы. Слишком много минусов:
В случае подхода со спецификацией, вместо условного метода репозитория с sql запросом или ORM, мы получаем кучу новых классов, которые надо поддерживать, про которые надо знать, которые являются проектно специфичными (в отличие от sql или ORM'ов, API которых знают все), а значит и увеличивается стоимость поддержки, онбординга новых разработчиков в проект.
Предложенная вами система с спецификациями это создание новой абстракции поверх существующей (ОRM) поверх существующей (SQL). Но ради каких профитов? Ваши плюсы не являются плюсами перед существующим подходами:
> использование абстракций для доступа к данным – правильное решение;
Репозиторий как паттерн - это и есть абстракция для доступа к данным. Она инкапсулирует в себя низкоуровневые запросы к дравйверу бд и возвращает доменную модель.
> спецификация предлагает стандартизованный подход к созданию репозиториев, что облегчает разработку, сопровождение и масштабирование приложений;
Как будут выглядеть запросы с join? Кажется, как будто здесь также придется делать отдельные non-generic методы для сложных запросов, в итоге вся унификация теряется.
> Добавление разных вариаций запросов данных сводится к созданию одной строки кода;
В вашем же примере BadManRepository2 это делается точно также - вы меняете Request модель, и затем добавляете 1 строчку изменений в репозиторий (Where).
> изменение запросов производится на уровне пользовательского кода — нет необходимости менять код репозитория;
В вашем случае необходимости нет, потому что ответственность репозитория расслаивается по проекту на спецификации. Фактически, меняя спецификации вы напрямую аффектите генерируемые запросы, тем самым tight coupling как оставался так и продолжает оставаться
Кол-во оверхеда, как со стороны когнитивной нагрузки разработчиков, так и со стороны производительности просто напросто того не стоят.
Мне нравится блог пост Hayden James'а, у него на сайте есть пару статей про хоумлабы Если смотреть что-то русскоязычное, в тг есть вот этот чатик, думаю есть и другие если поискать
Основная проблема всех последних нововведений в С++ - это «замыленность» взгляда разработчиков, которые эти фичи пилят.
Для людей, которые пишут код на плюсах последние лет 20, фичи могут казаться простыми и нужными, просто из-за огромного количества опыта во всех аспектах языка.
При этом совершенно забываются потребности новых разработчиков, которые смотря на развитие языка, будут делать предпочтение в сторону Rust/C, и т.д
Мне кажется, вам скорее сильно не повезло. Вы правы, DevOps должны упрощать процессы, забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
У меня просто была обратная ситуация - во всех местах где я работал, были очень хорошо отлаженны DevOps процессы. Переусложнения не было, проблемы решались по мере их появления, становилось реально проще - мне как разработчику, надо было всего запушить код - и оно само развертывается где нужно, как нужно, на каких нужно серверах, с какими нужно конфигами, интеграцями и пр.
Согласен с вами в том плане, что веб разработка в последнее время сильно переусложняется новыми абстрактными технологиями, но проблема которую вы описали в статье, является проблемой не DevOps, а плохо настроенных процессов компании.
Серьезно?) Один из лучших языков для того чтобы шиппить в прод в 20 раз медленнее чем на любом другом япе
Тут согласен. Но разработка ведется прям оч активно
Касаемо рестарта сервисов - как раз в статье была ссылка - там ишью прям в приоритете сейчас разрабатывается, думаю в ближайшей версии добавят. Тут как раз таки круто, что т.к проект новый, можно набрасывать на официальную репу идеи, и если они годные, то их достаточно быстро будут реализовывать
Не используется данный по подход по простой причине - излишний оверинжиниринг и решение несуществующей проблемы. Слишком много минусов:
В случае подхода со спецификацией, вместо условного метода репозитория с sql запросом или ORM, мы получаем кучу новых классов, которые надо поддерживать, про которые надо знать, которые являются проектно специфичными (в отличие от sql или ORM'ов, API которых знают все), а значит и увеличивается стоимость поддержки, онбординга новых разработчиков в проект.
Предложенная вами система с спецификациями это создание новой абстракции поверх существующей (ОRM) поверх существующей (SQL). Но ради каких профитов? Ваши плюсы не являются плюсами перед существующим подходами:
> использование абстракций для доступа к данным – правильное решение;
Репозиторий как паттерн - это и есть абстракция для доступа к данным. Она инкапсулирует в себя низкоуровневые запросы к дравйверу бд и возвращает доменную модель.
> спецификация предлагает стандартизованный подход к созданию репозиториев, что облегчает разработку, сопровождение и масштабирование приложений;
Как будут выглядеть запросы с join? Кажется, как будто здесь также придется делать отдельные non-generic методы для сложных запросов, в итоге вся унификация теряется.
> Добавление разных вариаций запросов данных сводится к созданию одной строки кода;
В вашем же примере BadManRepository2 это делается точно также - вы меняете Request модель, и затем добавляете 1 строчку изменений в репозиторий (Where).
> изменение запросов производится на уровне пользовательского кода — нет необходимости менять код репозитория;
В вашем случае необходимости нет, потому что ответственность репозитория расслаивается по проекту на спецификации. Фактически, меняя спецификации вы напрямую аффектите генерируемые запросы, тем самым tight coupling как оставался так и продолжает оставаться
Кол-во оверхеда, как со стороны когнитивной нагрузки разработчиков, так и со стороны производительности просто напросто того не стоят.
Я не понимаю, ну вот сколько можно мусолить одну и ту же уже повсюду изученную, заезженную и скучную тему?
Говорю за себя - мне уже по горло достаточно однотипного контента про solid.
А самое отвратительное в этом, что вы даже не старались - просто сделали перевод статьи тупо чтобы вставить рекламу курсов
Мне нравится блог пост Hayden James'а, у него на сайте есть пару статей про хоумлабы
Если смотреть что-то русскоязычное, в тг есть вот этот чатик, думаю есть и другие если поискать
Основная проблема всех последних нововведений в С++ - это «замыленность» взгляда разработчиков, которые эти фичи пилят.
Для людей, которые пишут код на плюсах последние лет 20, фичи могут казаться простыми и нужными, просто из-за огромного количества опыта во всех аспектах языка.
При этом совершенно забываются потребности новых разработчиков, которые смотря на развитие языка, будут делать предпочтение в сторону Rust/C, и т.д
Мне кажется, вам скорее сильно не повезло. Вы правы, DevOps должны упрощать процессы, забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
У меня просто была обратная ситуация - во всех местах где я работал, были очень хорошо отлаженны DevOps процессы. Переусложнения не было, проблемы решались по мере их появления, становилось реально проще - мне как разработчику, надо было всего запушить код - и оно само развертывается где нужно, как нужно, на каких нужно серверах, с какими нужно конфигами, интеграцями и пр.
Согласен с вами в том плане, что веб разработка в последнее время сильно переусложняется новыми абстрактными технологиями, но проблема которую вы описали в статье, является проблемой не DevOps, а плохо настроенных процессов компании.