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