У вас подавляющее большинство статей с ИИ обложкой, что меня лично сразу отталкивает. Часть статей полностью на английском, это даже забавно выглядит, но на русском ресурсе как будто не нужен такой контен)
Только из нескольких ваших названий я вообще примерно понял о чем статья.
Вы считаете себя не признанным гением?) Думаете если ВЫ что-то написали люди сразу ринутся это читать и обсуждать?)
Я не давал никакой оценки найму, только сказал про не мое и конкретно про ИТ.
Мне, как инженеру, не интересно бороться с человеческим эго, мне интересно создавать работающие оптимально информационные системы. За достаточно не малое количество попыток в найме, я так и не нашел места где бы это ценилось, а не игры во взрослые продукты. Мне не интересно быть участником группового мышления, учитывая что часто группу возглавляет человек давно не относящийся к разработке продуктов, да и вообще подводных камней слишком много в человеческих дрязгах, а все техническое уходит на задние планы. Отсюда и такая любовь к микросервисам, теперь вот ИИ на голову свалилось, думаю в плане качества софта нас ждут не самые лучшие времена)
Когда мужчине нужно обеспечить семью
А что, женщины в наши дни не работают?) Помойму тейк про мужчина - работа, женщина - кухня, уже покрывается пылью)
Понимаю вас, поработав в найме понял что это не моё, теперь ещё и в обнимку с ИИ заставляют работать поэтому либо свое в ИТ либо не ИТ) Страшно, но времена тяжёлые нынче
88% работодателей признают, что их ATS‑системы отсекают квалифицированных кандидатов, в том числе high‑skilled, не потому что они не могут выполнять работу, а потому что формально не совпадают с точными критериями вакансии
Это было и до всяких ИИ в найме. "У вас 5 лет опыта на чистом php? Извините, нам надо 2 года laravel/yii"
Ощущение что проблемы все как были так и остались, только добавились новые, например что теперь hr не справляются со своей работой, видать на всю страну не одной hr фирмы нету чтобы 200 человек на вакансию разгребсти...
Да и толку от этих hr сейчас, если даже до них добраться, то у большинства такое чсв (чем больше компания тем больше чсв) что хочется просто быстрее закончить диалог и не выходить из квартиры дня 3 что бы никого не видеть))
Смотрите, а вот вам пример который я нашел, без всякой ИИшницы, как думаете, можно на нем построить что-то типо интерфейса?) Еще и вот таким шлифануть)
По сути, instanceof выносит сигнатуру в тело функции)) что, наверное, просто минус языка js как мультипарадигменного, попытка уседеть на скольки-то стульях))
Грубо конечно, но мне тоже кажется что профессионализм яндексовских программистов под вопросом) Они с первого раза не могли удалить историю из аккаунта, только с 3 раза получилось все подчистить)) смешно и грустно)
Уже больше года как забыл про сервисы яндекса, теперь не смотрю по 5 реклам подряд в кинопоиске, меня не обдирают подписками на аккаунты которые я не создавал, вообщем стало жить чуточку спокойнее)
Вы сужаете целые главы книг до одной фразы и спрашиваете весь ли это смысл? Мне кажется очевидно что нет.
Я через день пишу на чистом js фронт, мне на нем не приходилось, пока, строить сложные вещи, но я уверен что если погрузиться в этот вопрос глубже, инверсия зависимости подругому реализуется, возможно напишу про это что-то))
Системный аналитик должен знать что такое инверсия зависимости?) Или, например, почему в луковичной архитектуре стрелочки зависимостей рисуют к домену? То есть более низкоуровневый код должен зависить от более высокого?) Ну это, как будто, должны программисты знать) Почему домен не должен зависить от базы данных))
Хотя мне в комментариях один тимлид ВК высказывал что им никакая инверсия не нужна и это все кодовое графоманство) Ну я хочу сказать что и приложение ВК не лучший пример для подражания)) Да и акции уже по 130 рублей или сколько там))
В языке где есть интерфейс достаточно написать implements (например php) и быть уверенным что ваши репозитории поддерживают контракт.
Я в примере обращал ваше внимание, что интерфейс зарождается в коде потребителя. Это справедливо для любого ЯП
Получается вы как веб разработчик считаете что для домена (бизнес логики) интерфейс задают потребители бизнес логики? Интересно как.
А так вам просто нужно место (файл), где описать какой-то интерфейс в том или ином виде, предусмотренным соответствующим ЯП, или в md- или txt-файле, если этот ЯП ещё менее развит, чем JS с его JSDoc
Поймите, для меня как программиста это просто не приемлемо. Сидеть и сверять программу с текстом, когда за выполнением контрактов должен отвечать компилятор/интерпретатор это явно два шага назад
Я вам и пытаюсь сказать что нету никакого контракта у вас.
Получается что ваши репозитории должны знать тело каждой функции и что в ней может быть вызванно. Ладно один пример, учебный, но на реальном проекте это сразу превратится в барьер
Даже наследование класса и переопределение метода выглядит лучше чем "просто знать" где там что вызывается
У вас подавляющее большинство статей с ИИ обложкой, что меня лично сразу отталкивает. Часть статей полностью на английском, это даже забавно выглядит, но на русском ресурсе как будто не нужен такой контен)
Только из нескольких ваших названий я вообще примерно понял о чем статья.
Вы считаете себя не признанным гением?) Думаете если ВЫ что-то написали люди сразу ринутся это читать и обсуждать?)
Только в бизнесе клиента волнует конечный продукт, а в найме тебе дают грабли и говорят копай)
Я не давал никакой оценки найму, только сказал про не мое и конкретно про ИТ.
Мне, как инженеру, не интересно бороться с человеческим эго, мне интересно создавать работающие оптимально информационные системы. За достаточно не малое количество попыток в найме, я так и не нашел места где бы это ценилось, а не игры во взрослые продукты. Мне не интересно быть участником группового мышления, учитывая что часто группу возглавляет человек давно не относящийся к разработке продуктов, да и вообще подводных камней слишком много в человеческих дрязгах, а все техническое уходит на задние планы. Отсюда и такая любовь к микросервисам, теперь вот ИИ на голову свалилось, думаю в плане качества софта нас ждут не самые лучшие времена)
А что, женщины в наши дни не работают?) Помойму тейк про мужчина - работа, женщина - кухня, уже покрывается пылью)
Понимаю вас, поработав в найме понял что это не моё, теперь ещё и в обнимку с ИИ заставляют работать поэтому либо свое в ИТ либо не ИТ) Страшно, но времена тяжёлые нынче
Ага, осталось дождаться пока бизнес наиграется в ИИ) Учитывая что он так и не наигрался в микросервисы, это может затянуться очень на долго)
Это было и до всяких ИИ в найме. "У вас 5 лет опыта на чистом php? Извините, нам надо 2 года laravel/yii"
Ощущение что проблемы все как были так и остались, только добавились новые, например что теперь hr не справляются со своей работой, видать на всю страну не одной hr фирмы нету чтобы 200 человек на вакансию разгребсти...
Да и толку от этих hr сейчас, если даже до них добраться, то у большинства такое чсв (чем больше компания тем больше чсв) что хочется просто быстрее закончить диалог и не выходить из квартиры дня 3 что бы никого не видеть))
Смотрите, а вот вам пример который я нашел, без всякой ИИшницы, как думаете, можно на нем построить что-то типо интерфейса?) Еще и вот таким шлифануть)
По сути, instanceof выносит сигнатуру в тело функции)) что, наверное, просто минус языка js как мультипарадигменного, попытка уседеть на скольки-то стульях))
Грубо конечно, но мне тоже кажется что профессионализм яндексовских программистов под вопросом) Они с первого раза не могли удалить историю из аккаунта, только с 3 раза получилось все подчистить)) смешно и грустно)
Уже больше года как забыл про сервисы яндекса, теперь не смотрю по 5 реклам подряд в кинопоиске, меня не обдирают подписками на аккаунты которые я не создавал, вообщем стало жить чуточку спокойнее)
У меня тоже не получается вам объяснить что сократить до одной фразы понятие из книги нельзя)) Не учитывая что и фразу вы приводите не ту))
Спасибо за мотивацию разобраться)
Если бы тс выполнялся в браузере, без проблем я бы лучше его взял.
А так, покрасить кнопочки, отправить ajax, мне хватает с лихвой. Бизнес логики никакой нет на фронте.
Серьёзность проекта показывает результат, а не библиотеки
Вы сужаете целые главы книг до одной фразы и спрашиваете весь ли это смысл? Мне кажется очевидно что нет.
Я через день пишу на чистом js фронт, мне на нем не приходилось, пока, строить сложные вещи, но я уверен что если погрузиться в этот вопрос глубже, инверсия зависимости подругому реализуется, возможно напишу про это что-то))
Ну я согласен что от неиспользуемых интерфейсов зависимость не нужна, это вроде очевидно.
Вы вырвали одну фразу, которая к делу, по сути, даже не относится, из книги где нужно последовательно читать главы чтобы все собрать в одну картину...
Я вас не хочу ни в чем переубедить. Я использую инверсию зависимости в своих проектах и придти к пониманию мне помогла эта книга.
Подробно можно прочитать в книге Роберта Мартина "Чистая архитектура"
Ну я тоже хорошо представляю откуда берутся требования.
По вашему разделение интерфейса на более мелкие, функциональные части, это построение инверсии зависимости??
Segregation как раз переводится как разделение, и не как не связанно с направлением требований...
Системный аналитик должен знать что такое инверсия зависимости?) Или, например, почему в луковичной архитектуре стрелочки зависимостей рисуют к домену? То есть более низкоуровневый код должен зависить от более высокого?) Ну это, как будто, должны программисты знать) Почему домен не должен зависить от базы данных))
Хотя мне в комментариях один тимлид ВК высказывал что им никакая инверсия не нужна и это все кодовое графоманство) Ну я хочу сказать что и приложение ВК не лучший пример для подражания)) Да и акции уже по 130 рублей или сколько там))
Понял, вопросов больше не имею
В языке где есть интерфейс достаточно написать implements (например php) и быть уверенным что ваши репозитории поддерживают контракт.
Получается вы как веб разработчик считаете что для домена (бизнес логики) интерфейс задают потребители бизнес логики? Интересно как.
Поймите, для меня как программиста это просто не приемлемо. Сидеть и сверять программу с текстом, когда за выполнением контрактов должен отвечать компилятор/интерпретатор это явно два шага назад
Я вам и пытаюсь сказать что нету никакого контракта у вас.
Получается что ваши репозитории должны знать тело каждой функции и что в ней может быть вызванно. Ладно один пример, учебный, но на реальном проекте это сразу превратится в барьер
Даже наследование класса и переопределение метода выглядит лучше чем "просто знать" где там что вызывается