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