Джун, Мидл, Сеньор - бессвязный набор слов, если их использовать без спецификации.
К тому же я написал, что наиболее сравнимое, а не точь-в-точь. Как минимум, IT до сих пор развивается, а медицина — уже развитая отрасль. И стоит смотреть не только на текущее положение дел, но и на весь путь развития других отраслей.
Джун, Мидл, Сеньор - бессвязный набор слов, если их использовать без спецификации.
В жизни нужно быть проще, а не меряться лычками, т.к. иной раз "Джун" может принести больше пользы, чем "Сеньор". Как минимум "Джун" в одной области может оказаться гораздо смышленее в другой, которая как раз и будет полезнее в конкретной ситуации.
Опыт это не просто про время. Смысл сравнивать разработчика лендингов со стажем 10 лет, и, допустим, разработчика бд? Это разные весовые категории, но они все нужны (Все профессии важны, все профессии нужны). Даже если брать двух разработчиков с одинаковым стэком, то окажется, что опыт за года у них был разный.
Я не понимаю зачем унифицировать друг-друга, если это не даёт бенефитов. Ещё до недавнего времени "разработчики" и "программисты" в глаза общественности были гиками, которые могут починить утюг. А при помощи таких унификаций создаётся только иллюзия. Т.к. упрощение сложного (комплексного) не ведёт ни к чему хорошему.
Для меня наиболее сравнимое с IT это система здравоохранения. Есть терапевты, хирурги, медсестры, бухгалтера, администраторы и т.д., которые в этих больших группах делятся на ещё мельче (кардиохирург, нейрохирург и т.д.). Да, есть в медицине что-то смежное, что-то базовое, что знают вне зависимости от конкретной профессии. И каждая профессия важна. А в IT будто решили изобрести велосипед и пройтись по всем граблям, вместо того, чтобы взять и использовать лучшие практики из других отраслей.
Вообщем весь коммент сводится к тому, что упрощение всего опыта человека до банальных "Джун", "Мидл", "Сеньор" не даст ничего, кроме какой-то иллюзии.
Я не говорю, что системный подход не нужен, Я говорю про то, что учебная программа для 5 летних и 12 летних будет разной. И если в 5 лет обучать чему-то более общему, нежели конкретно программированию, то это не означает, что более общее не относится к обучению программированию.
Так же как и в программировании важно не только уметь программировать, но и уметь обучаться, т.к. каждый день появляются новые технологии которые окажут влияние через год-два-три и т.д., игнорирование которых поставит в слабую позицию.
Вообщем мой тезис сводится к тому, что обучение программированию это не только про сам код/анализ/проектирование.
Смотря что понимать под обучением. Есть комп игры, которые обучают логике в игровой форме. Да, это развивающие игры более общего плана, а не конкретно программированию, но всё же помогут и в изучении программированию в дальнейшем.
До сих пор помню бесящий уровень с рыболовной сетью из Медвежонка Плюма... Эту игру мне дали, когда было 5-6 лет.
Он нужен только для оптимизации запроса данных из других сервисов, только тогда выигрыш производительности нивелирует проблемы безопасности.
Если вы в JWT храните недостаточно данных (id пользователя и, допустим, роль) и затем запрашиваете все остальные данные в бд, то совокупного выигрыша нет.
Тут скорее вопрос о том, в каких конкретных случаях использовать jwt выгодно. Т.к. в подавляющем большинстве случаев в jwt просто хранится id текущего пользователя (и ещё какие-то идшники), что не решает проблему с запросами к бд.
Я нашел только один случай, когда в jwt есть смысл - кэширование не секретных данных, чтобы разгрузить бд. Но это не нужно, либо хранится только id в 99%.
Как по мне, указанный вами пример с монолитом/распределенной системой не является аргументом за jwt, т.к. описанный случай решается гейтвеем.
Тот же вопрос и про jwt. Как по мне, jwt самая переоцененная вещь. Если мы хотим меньше делать запросов к бд, то возникают проблемы с принудительной инвалидацией токенов. Или как в данном случае общение происходит в доверенной сети и непонятно для чего jwt в принципе пихать...
Это приложение не для знакомств (в плане отношений), а чисто для мужской дружбы. Как я это понял?
Прошёл тесты, в совпадениях чуть больше десяти девушек возрастом 35-52 и совпадением в районе 73%. Поменял пол на Ж, сменил поиск на М, появилось куча парней 25-35 с совпадением 85% =)
По поводу "опыта" и "проекта в породе". Можно же новичкам наработать опыт и получить проект в портфолио на фрилансе. Помимо фриланс платформ есть форумы с заказами (они ещё живы).
Оплата скорее всего будет не велика, ровно как и нет 100% вероятности что вы найдете проект под свой стэк, но всё же для веба (в т.ч. и бэка) найти не сложно. А с учётом, что на бэке можно использовать любой ЯП (не приходит на ум ЯП, который бы нельзя было использовать на бэке), то велика вероятность, что у вас появится проект в портфолио.
Насколько знаю, сейчас относятся скептически к фрилансе в резюме, но всё же если речь про джуна, тем более с прикрепленным проектом, то пойдёт только в плюс.
То, что вы написали никак не отменят моего высказывания.
Почему вы думаете, что использую микросервисы, вы получаете гарантии? Как только вы перестанете за этим следить, сразу всё пойдёт "естественным путем".
Где вы увидели, что я писал про легаси?
Где вы увидели несколько поколений, если сами писали про 3 года?
Мой коммент был направлен именно на утверждение, что для переписывания частями не нужны микросервисы, для возможности переписывать частями нужна нормальная архитектура.
Чтобы переписывать частями нужны микросервисы?
Как по мне (и исходя из опыта), если нормальная архитектура, то и монолит можно переписывать частями без проблем
Две пиццы это на какой срок?
Какие именно пиццы? Диаметр? Вес? Калорийность?
Если это был сарказм, то я не понял)
А так… Смешивать техническое и человеческий фактор прожорливости — не самая лучшая идея.
Две пиццы 35-40см в диаметре я могу легко съесть за часов 5, хотя я не такой и большой (около 85кг).
Контроллер — это Interface Adapter. Таким образом, если библиотека выступает в роли Interface Adapter, то это не означает, что вы не используете данный слой.
Проблемы нет, если вы делегируете обязанности контроллера библиотеке, но будут проблемы, если вы будете писать бизнес логику в контроллерах.
Так много книг было написано по архитектуре.
Почему нельзя было взять аргументы, которые голосуют за разделение из книг от Макконелла, Фаулера, Дяди Боба или из статей на том же хабре и сказать почему те методики, которые описаны в книгах и статьях хуже, чем предлагает автор данной статьи? Тогда бы статья получилась не настолько однобокой.
Только из-за того, что автор ничего не написал про аргументы противоположной стороны, я считаю, что автор и не пытался узнать аргументы за разделение.
Автор пытался рассуждать про плюсы разделения, но это были его мысли, которые навряд ли были подкреплены информацией из книг или статей.
Иначе не было бы вот такого:
Чтобы переиспользовать код? — Нет, флоу перевода денег не подойдет для флоу начисления бонусов.
К тому-же если вы даже найдете возможность совместить 2 фичи, вы рискуете сломав одну — автоматически сломать другую
Все авторы писали, что есть "мнимое повторение", а есть реальное. В таком случае мнимое повторение лишь повторяет алгоритм, но используется совсем другой бизнес логикой. К примеру, если отчет по зп необходимо в двух местах (бухгалтерия и начальство), то вначале алгоритм подсчета может быть одинаковым, и будет соблазн вынести подсчет в единое место, но SRP нам подскажет, что в этом нет необходимости.
Если у вас изменения в одной части приводят к неожиданным неприятностям в других местах, то, скорее всего, у вас не всё в порядке с архитектурой.
Возможно, мы с вами говорим о разных вещах. Я не могу понять о чем именно вы говорите, т.к. ваш пример очень абстрактен и не дает понятия какие практики вы использовали, а так же мне не совсем понятно что вы имеете ввиду под моделью данных (это затрагивает сразу несколько аспектов).
Мне не понятно почему вы написали про объем данных, т.к. я говорил про реализацию абстракции доступа к данным, а не про конкретные бд.
Если решение миграции было принято "просто потому что", то мне жаль, что вам пришлось иметь дело с таким требованием.
Да, заменим в DI контейнере, и другие части этого не заметят.
Если вы захотите использовать оба — то пожалуйста, можете в одном датасурсе это реализовать, либо в разных, а доступ к ним осуществлять через репозиторий.
На случай "А вдруг вернуться захотим" есть инструменты контроля версий
см первый абзац.
К тому же я написал, что наиболее сравнимое, а не точь-в-точь. Как минимум, IT до сих пор развивается, а медицина — уже развитая отрасль. И стоит смотреть не только на текущее положение дел, но и на весь путь развития других отраслей.
Джун, Мидл, Сеньор - бессвязный набор слов, если их использовать без спецификации.
В жизни нужно быть проще, а не меряться лычками, т.к. иной раз "Джун" может принести больше пользы, чем "Сеньор". Как минимум "Джун" в одной области может оказаться гораздо смышленее в другой, которая как раз и будет полезнее в конкретной ситуации.
Опыт это не просто про время. Смысл сравнивать разработчика лендингов со стажем 10 лет, и, допустим, разработчика бд? Это разные весовые категории, но они все нужны (Все профессии важны, все профессии нужны). Даже если брать двух разработчиков с одинаковым стэком, то окажется, что опыт за года у них был разный.
Я не понимаю зачем унифицировать друг-друга, если это не даёт бенефитов. Ещё до недавнего времени "разработчики" и "программисты" в глаза общественности были гиками, которые могут починить утюг. А при помощи таких унификаций создаётся только иллюзия. Т.к. упрощение сложного (комплексного) не ведёт ни к чему хорошему.
Для меня наиболее сравнимое с IT это система здравоохранения. Есть терапевты, хирурги, медсестры, бухгалтера, администраторы и т.д., которые в этих больших группах делятся на ещё мельче (кардиохирург, нейрохирург и т.д.). Да, есть в медицине что-то смежное, что-то базовое, что знают вне зависимости от конкретной профессии. И каждая профессия важна. А в IT будто решили изобрести велосипед и пройтись по всем граблям, вместо того, чтобы взять и использовать лучшие практики из других отраслей.
Вообщем весь коммент сводится к тому, что упрощение всего опыта человека до банальных "Джун", "Мидл", "Сеньор" не даст ничего, кроме какой-то иллюзии.
Я говорил именно про обучение с 5-6 лет.
Я не говорю, что системный подход не нужен, Я говорю про то, что учебная программа для 5 летних и 12 летних будет разной. И если в 5 лет обучать чему-то более общему, нежели конкретно программированию, то это не означает, что более общее не относится к обучению программированию.
Так же как и в программировании важно не только уметь программировать, но и уметь обучаться, т.к. каждый день появляются новые технологии которые окажут влияние через год-два-три и т.д., игнорирование которых поставит в слабую позицию.
Вообщем мой тезис сводится к тому, что обучение программированию это не только про сам код/анализ/проектирование.
Смотря что понимать под обучением. Есть комп игры, которые обучают логике в игровой форме. Да, это развивающие игры более общего плана, а не конкретно программированию, но всё же помогут и в изучении программированию в дальнейшем.
До сих пор помню бесящий уровень с рыболовной сетью из Медвежонка Плюма... Эту игру мне дали, когда было 5-6 лет.
От JWT нет пользы в большинстве проектов.
Он нужен только для оптимизации запроса данных из других сервисов, только тогда выигрыш производительности нивелирует проблемы безопасности.
Если вы в JWT храните недостаточно данных (id пользователя и, допустим, роль) и затем запрашиваете все остальные данные в бд, то совокупного выигрыша нет.
Ну и зачем тогда jwt? Чтобы лишний раз парсить и валидировать?
А чёрное где хранить? А нельзя ли было там просто хранить строковую сессию?
https://habr.com/ru/articles/502702/comments/#comment_21636220
Кто жалуется на технологию? Я написал, что она переоценена, разве это не правда?
Тут скорее вопрос о том, в каких конкретных случаях использовать jwt выгодно. Т.к. в подавляющем большинстве случаев в jwt просто хранится id текущего пользователя (и ещё какие-то идшники), что не решает проблему с запросами к бд.
Я нашел только один случай, когда в jwt есть смысл - кэширование не секретных данных, чтобы разгрузить бд. Но это не нужно, либо хранится только id в 99%.
Как по мне, указанный вами пример с монолитом/распределенной системой не является аргументом за jwt, т.к. описанный случай решается гейтвеем.
Тот же вопрос и про jwt.
Как по мне, jwt самая переоцененная вещь. Если мы хотим меньше делать запросов к бд, то возникают проблемы с принудительной инвалидацией токенов. Или как в данном случае общение происходит в доверенной сети и непонятно для чего jwt в принципе пихать...
Вот даже откопал:
https://habr.com/ru/articles/502702/comments/#comment_21636220
Это приложение не для знакомств (в плане отношений), а чисто для мужской дружбы.
Как я это понял?
Прошёл тесты, в совпадениях чуть больше десяти девушек возрастом 35-52 и совпадением в районе 73%.
Поменял пол на Ж, сменил поиск на М, появилось куча парней 25-35 с совпадением 85% =)
По поводу "опыта" и "проекта в породе".
Можно же новичкам наработать опыт и получить проект в портфолио на фрилансе. Помимо фриланс платформ есть форумы с заказами (они ещё живы).
Оплата скорее всего будет не велика, ровно как и нет 100% вероятности что вы найдете проект под свой стэк, но всё же для веба (в т.ч. и бэка) найти не сложно. А с учётом, что на бэке можно использовать любой ЯП (не приходит на ум ЯП, который бы нельзя было использовать на бэке), то велика вероятность, что у вас появится проект в портфолио.
Насколько знаю, сейчас относятся скептически к фрилансе в резюме, но всё же если речь про джуна, тем более с прикрепленным проектом, то пойдёт только в плюс.
Видимо, вы работали только с умными людьми)
На моей практике было такое, что человек вместо написания пары строк кода пишет отдельный класс костылей
То, что вы написали никак не отменят моего высказывания.
Почему вы думаете, что использую микросервисы, вы получаете гарантии? Как только вы перестанете за этим следить, сразу всё пойдёт "естественным путем".
Где вы увидели, что я писал про легаси?
Где вы увидели несколько поколений, если сами писали про 3 года?
Мой коммент был направлен именно на утверждение, что для переписывания частями не нужны микросервисы, для возможности переписывать частями нужна нормальная архитектура.
Не понимаю почему вы пишите оффтоп
Чтобы переписывать частями нужны микросервисы?
Как по мне (и исходя из опыта), если нормальная архитектура, то и монолит можно переписывать частями без проблем
Две пиццы это на какой срок?
Какие именно пиццы? Диаметр? Вес? Калорийность?
Если это был сарказм, то я не понял)
А так… Смешивать техническое и человеческий фактор прожорливости — не самая лучшая идея.
Две пиццы 35-40см в диаметре я могу легко съесть за часов 5, хотя я не такой и большой (около 85кг).
Контроллер — это Interface Adapter. Таким образом, если библиотека выступает в роли Interface Adapter, то это не означает, что вы не используете данный слой.
Проблемы нет, если вы делегируете обязанности контроллера библиотеке, но будут проблемы, если вы будете писать бизнес логику в контроллерах.
Так много книг было написано по архитектуре.
Почему нельзя было взять аргументы, которые голосуют за разделение из книг от Макконелла, Фаулера, Дяди Боба или из статей на том же хабре и сказать почему те методики, которые описаны в книгах и статьях хуже, чем предлагает автор данной статьи? Тогда бы статья получилась не настолько однобокой.
Только из-за того, что автор ничего не написал про аргументы противоположной стороны, я считаю, что автор и не пытался узнать аргументы за разделение.
Автор пытался рассуждать про плюсы разделения, но это были его мысли, которые навряд ли были подкреплены информацией из книг или статей.
Иначе не было бы вот такого:
Все авторы писали, что есть "мнимое повторение", а есть реальное. В таком случае мнимое повторение лишь повторяет алгоритм, но используется совсем другой бизнес логикой. К примеру, если отчет по зп необходимо в двух местах (бухгалтерия и начальство), то вначале алгоритм подсчета может быть одинаковым, и будет соблазн вынести подсчет в единое место, но SRP нам подскажет, что в этом нет необходимости.
Если у вас изменения в одной части приводят к неожиданным неприятностям в других местах, то, скорее всего, у вас не всё в порядке с архитектурой.
Возможно, мы с вами говорим о разных вещах. Я не могу понять о чем именно вы говорите, т.к. ваш пример очень абстрактен и не дает понятия какие практики вы использовали, а так же мне не совсем понятно что вы имеете ввиду под моделью данных (это затрагивает сразу несколько аспектов).
Мне не понятно почему вы написали про объем данных, т.к. я говорил про реализацию абстракции доступа к данным, а не про конкретные бд.
Если решение миграции было принято "просто потому что", то мне жаль, что вам пришлось иметь дело с таким требованием.
Да, заменим в DI контейнере, и другие части этого не заметят.
Если вы захотите использовать оба — то пожалуйста, можете в одном датасурсе это реализовать, либо в разных, а доступ к ним осуществлять через репозиторий.
На случай "А вдруг вернуться захотим" есть инструменты контроля версий