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