Отслеживать релизы стало сложнее, чем следить за мемами.
Попахивает...джаваскриптом?))
Почему все статьи которые восхваляют ИИ отдают какой-то инфоцыганщиной. Куча каких-то прогревов, революций. А пока революция в том что везде эти нейросети сами компании пихают в надежде отбить их разработку. В гугле дак вообще сноска висит что не стоит полностью доверять ответу ИИ
Вы не говорите что неправильное понимание MVC приводит к этому. Вы что в статье, что в комментариях заявлете что MVC по умолчанию и своему определению это медленно и плохо, еще и проблемы с многопоточностью...это конечно тоже классно выглядит при вашем сеньерстве. По своей сути все паттерны архитектуры приложения сводятся к одному - разделения кода на зоны ответственности. Вы конечно сеньер, и должны такие вещи понимать, как я считаю, но давайте я вам скажу - код необходимо разделять потому-что для логики бизнеса и например подключение и работе к БД вы используете один и тот же язык с одним и тем же кодом плюс минус. Дак вот архитектурный паттерн и нужен что-бы разделить эти зоны ответственности, если вы все это раскидали как попало то проблема не в MVC, тут даже луковичная/гексогональная/"чистая" архитектура не поможет))
Я если честно почти каждый день что-то новое (для себя) открываю в html и css, уже мысль подходит что надо за жизнь хотя-бы раз всю спецификацию прочитать, чтобы не ловить инсайды)
Про размыв границ - по ощущениям это все профессии в ИТ, программисту уже не достаточно писать только код, надо архитектуру развернуть у себя локально (понять почему существующая дока устарела например)
А технической подкованности от менеджмента ждут, как я думаю, для лучшей оценки затрат на задачи, соответственно экономии бюджета. Чем подробнее менеджер знает и видит что надо сделать, тем подробнее и точнее будет оценка от него.
При хорошей архитектуре внутри приложения тоже все хорошо мокается и тестируется. Тесты на всю систему и не надо делать, если вы хотите проверить нотификатор.
Как по мне с базами данных самый большой минус этих микросервисов, если принято что надо под каждый сервис свою базу данных, с нетерпением жду обратной волны, когда люди начнут рассказывать что микросервис это не так и круто, в монолите база данных как-то поконсистентней и бизнес логику можно базой данных защищать и покрывать, а не только кодом) как было с NoSQL и SQL например.
Я думаю микросервис называется не в плане размера или значимости кода который он хранит и выполняет, а то что для деплоя этих сервисов используется минимально необходимая инфраструктура для его работы (минимальный набор инструментов в ОС и тп.)
Про базы данных прикольно конечно, в монолите бывает взглянешь на базу из 200 таблиц и только унынием наполняешься, а тут ещё по базам бегай собирай все логику во едино. И получается что на уровне базы (баз данных?) сложнее настраивать бизнес процессы (если это вообще реально, внешние ключи на базу к другому микросервису?:))
Как по мне микросервис это местячковое решение для вывода какого-то общего функционала и возможности докидывать или убавить мощности на лету (но с базами данных конечно беда)
Я не знаю что такое распределенный монолит. Как по мне история монолит/микросервис полуинфоциганская. До появления докеров никто не называл приложение монолитом, а решение его проблем микросервисом, это веение моды (как и JS везде, но тут не только мода, продвижение языка тоже играет большую роль).
Например у нас есть микросервис рассылки уведомлений, которым пользуется множество других доменов (чаты, маркетинг, сохраненные поиски и др.)
Да, это хороший пример для выделения функционала в отдельный какой-то сервис. Но я это делал на условном рэбите и до повсеместного продвижения микросервисов. Но с другой стороны рассылку можно отделить в отдельный программный модуль рядом с приложением. По сути изменится взаимодействие (был условный gRPC, станет межпроцессным). Мне кажется тут только в вопросе масштабирования и адаптации под нагрузку выигрывает микросервис, а так те же яйца только в профиль.
Скажите, а как на микросервисах с подключением к базе данных? Каждый сервис которому нужна БД пишет свое? (Слышал и про такое) или есть микросервис базы данных в который все ходят?
Это все так, но MVC сам по себе не является "антипатерном" или каким-то не тем руководством к действию, как вам уже неоднократно подметили в комментариях. Ваши примеры кода, мягко говоря, притянуты за уши, от MVC у вас просто постфикс Controller и вся логика в нем, но это ваше желание и ваша (нейросети?) реализация контроллера, а не так написано в условном учебнике. Красота архитектуры в руках ее создающего.
Дело не в размере (я надеюсь). А в попытке уйти от монолита на кучу монолитов поменьше (что якобы позволяет меньше внимание уделять архитектуре кода), ещё и их все надо связать между собой
Творческая составляющая точно есть в работе, пишешь код и всегда есть ощущение что можно сделать лучше, тебе всегда надо придумывать алгоритмы и выражать их в коде. На самом деле с той статьёй автора я согласен (очень похоже на то что видел сам). Но в комментариях он и правда дал жару, я даже удивился что в статье и что в комментариях) Взять хотя-бы что человека не повышают в статье, но в комментариях он пишет что 400к через 2-3 года это почти каждый может.
Попахивает...джаваскриптом?))
Почему все статьи которые восхваляют ИИ отдают какой-то инфоцыганщиной. Куча каких-то прогревов, революций. А пока революция в том что везде эти нейросети сами компании пихают в надежде отбить их разработку. В гугле дак вообще сноска висит что не стоит полностью доверять ответу ИИ
Надо баланс искать, а про продуктивность да, больше всех кричат те, кто за счет чужой продуктивности бабосы поднимает )
Ну вы и сказанули
За превью лайк сразу, казалось бы, причему тут вайбкодинг и курсор.
Ну и опять же, узнал что-то новое, можно до бесконечности))
Вот, опять узнал что-то новое))
Интересная идея, классный стартап, прикольно)
Вы не говорите что неправильное понимание MVC приводит к этому. Вы что в статье, что в комментариях заявлете что MVC по умолчанию и своему определению это медленно и плохо, еще и проблемы с многопоточностью...это конечно тоже классно выглядит при вашем сеньерстве. По своей сути все паттерны архитектуры приложения сводятся к одному - разделения кода на зоны ответственности. Вы конечно сеньер, и должны такие вещи понимать, как я считаю, но давайте я вам скажу - код необходимо разделять потому-что для логики бизнеса и например подключение и работе к БД вы используете один и тот же язык с одним и тем же кодом плюс минус. Дак вот архитектурный паттерн и нужен что-бы разделить эти зоны ответственности, если вы все это раскидали как попало то проблема не в MVC, тут даже луковичная/гексогональная/"чистая" архитектура не поможет))
Я если честно почти каждый день что-то новое (для себя) открываю в html и css, уже мысль подходит что надо за жизнь хотя-бы раз всю спецификацию прочитать, чтобы не ловить инсайды)
Это конкретная реализация, а не правила MVC поймите уже.
Вы ещё и сеньор разработчик...
Про размыв границ - по ощущениям это все профессии в ИТ, программисту уже не достаточно писать только код, надо архитектуру развернуть у себя локально (понять почему существующая дока устарела например)
А технической подкованности от менеджмента ждут, как я думаю, для лучшей оценки затрат на задачи, соответственно экономии бюджета. Чем подробнее менеджер знает и видит что надо сделать, тем подробнее и точнее будет оценка от него.
Про либы я говорю "и тому подобное" после ОС :)
При хорошей архитектуре внутри приложения тоже все хорошо мокается и тестируется. Тесты на всю систему и не надо делать, если вы хотите проверить нотификатор.
Как по мне с базами данных самый большой минус этих микросервисов, если принято что надо под каждый сервис свою базу данных, с нетерпением жду обратной волны, когда люди начнут рассказывать что микросервис это не так и круто, в монолите база данных как-то поконсистентней и бизнес логику можно базой данных защищать и покрывать, а не только кодом) как было с NoSQL и SQL например.
Я думаю микросервис называется не в плане размера или значимости кода который он хранит и выполняет, а то что для деплоя этих сервисов используется минимально необходимая инфраструктура для его работы (минимальный набор инструментов в ОС и тп.)
Про базы данных прикольно конечно, в монолите бывает взглянешь на базу из 200 таблиц и только унынием наполняешься, а тут ещё по базам бегай собирай все логику во едино. И получается что на уровне базы (баз данных?) сложнее настраивать бизнес процессы (если это вообще реально, внешние ключи на базу к другому микросервису?:))
Как по мне микросервис это местячковое решение для вывода какого-то общего функционала и возможности докидывать или убавить мощности на лету (но с базами данных конечно беда)
Я не знаю что такое распределенный монолит. Как по мне история монолит/микросервис полуинфоциганская. До появления докеров никто не называл приложение монолитом, а решение его проблем микросервисом, это веение моды (как и JS везде, но тут не только мода, продвижение языка тоже играет большую роль).
Да, это хороший пример для выделения функционала в отдельный какой-то сервис. Но я это делал на условном рэбите и до повсеместного продвижения микросервисов. Но с другой стороны рассылку можно отделить в отдельный программный модуль рядом с приложением. По сути изменится взаимодействие (был условный gRPC, станет межпроцессным). Мне кажется тут только в вопросе масштабирования и адаптации под нагрузку выигрывает микросервис, а так те же яйца только в профиль.
Скажите, а как на микросервисах с подключением к базе данных? Каждый сервис которому нужна БД пишет свое? (Слышал и про такое) или есть микросервис базы данных в который все ходят?
Это все так, но MVC сам по себе не является "антипатерном" или каким-то не тем руководством к действию, как вам уже неоднократно подметили в комментариях. Ваши примеры кода, мягко говоря, притянуты за уши, от MVC у вас просто постфикс Controller и вся логика в нем, но это ваше желание и ваша (нейросети?) реализация контроллера, а не так написано в условном учебнике. Красота архитектуры в руках ее создающего.
Дело не в размере (я надеюсь). А в попытке уйти от монолита на кучу монолитов поменьше (что якобы позволяет меньше внимание уделять архитектуре кода), ещё и их все надо связать между собой
???? Тут точно речь про DDD и чисто луковичную архитектуру?)
Микросервис всему голова... Только вот ходят легенды что это обычно куча маленьких монолитов.
Зашёл в профиль автора, может он конкурентов по тг каналам дотапливает или надеется что в тг через профиль попадут)
Творческая составляющая точно есть в работе, пишешь код и всегда есть ощущение что можно сделать лучше, тебе всегда надо придумывать алгоритмы и выражать их в коде. На самом деле с той статьёй автора я согласен (очень похоже на то что видел сам). Но в комментариях он и правда дал жару, я даже удивился что в статье и что в комментариях) Взять хотя-бы что человека не повышают в статье, но в комментариях он пишет что 400к через 2-3 года это почти каждый может.
Надо пробовать мягкое управление, далеко на галере не уплывешь)