Обновить
52
4.6

Пользователь

Отправить сообщение

Я бы сказал, что есть второй путь. Можно героически выносить горести и лишения, уезжая на дачу на 3 дня. А можно голосовать ногами против проектов, команд и организаций, которые это самое выгорание вызывают. Многие со временем начинают верить в миф, что "оно везде так". Но если задаться целью найти команду профессионалов, а не буратин разной степени деревянности, то это вполне реально. Нужно пользоваться возможностью, пока мы еще на "рынке кандидата".

Нужно же занимать работой раздутые штаты органов. Будут сидеть с лупой, изучать обстоятельства, свидетелей опрашивать, очные ставки делать. Может даже дадут собаке ютуб понюхать.

Связывание типа животного с относящейся к нему бизнес-логикой в рамках енам-класса - это уже нарушение SRP и смешение уровней абстракции.

Кроме того, финальный вариант из статьи вовсе не финальный. Что если с каждым животным потребуется связать не только тип работника, но и, например, тип вольера, тип поставщика кормов, режим дня? А что если работник нужен не в одном экземпляре (с мышом справится один человек, а на бегемота нужны двое-трое)? Енам будет обрастать новыми private final полями и дополнительной бизнес-логикой, а проблема нарушения SRP будет только усугубляться.

Я б использовал абстрактную фабрику.

Hidden text

Как это часто бывает, GOF спешит на помощь даже спустя 30 лет

AnimalFactory factory = animalFactory.findFactory(animal)
List<Workers> workers = factory.getWorkers()
List<FoodItem> food = factory.getFood()
...
AnimalFactory findFactory(Animal animal) {
	switch(animal)
  	case HIPPO -> new HippoFactory()
    ...
}

Такой подход максимально развязывает руки. Например, работники могут браться из пула, а не быть строго назначенными на каждый тип животного.

Короче, лучше вернутся к исчерпывающим свитчам из 14 джавы, чем накручивать енам левой логикой. Разрастающийся свитч будет локализован внутри фабрики. Ну а что потребуется дописывать код - тут уж извините, работа у нас такая. Плюс не забываем о TDD. Кейс добавления нового типа животного должен сразу появляться в тестах, что также минимизирует вероятность что-то забыть.

Разработчик баз данных

А кто это? Те, кто сами движки БД разрабатывает? Я полагаю, таких спецов во всей индустрии считанные сотни. Сколько их было в вашем исследовании, если не секрет?

А какой капитал еще можно привлечь? Да и лучше уж западный, чем наш родимый

А почему вы видите осуждение этой практики в моем посте? Я сам работаю на западную компанию, если что. Просто там чуть выше описана фактура, что это может плохо закончиться в текущих условиях. С командой поступили откровенно грязно - такие истории как раз могут отпугнуть стартапы от выхода на международный уровень.

А помните, еще вчера у каждого стартапа была мечта раскрутиться и привлечь западный капитал или вообще продаться американцам. Сам в таком работал. Теперь, видимо, следует подумать дважды.

Спасибо, словил еще WTFов. Сейчас бы сказали, что игру дизайнила нейросеть. Формально все на месте: уровни, оружие, враги, звуки. По факту какой-то онейроид: мутные офицеры СС бегают среди высоченных каменных стен, из которых местами летят фаерболы, а протагонист горько вздыхает от бессилия это изменить.

Была эта игра на сборнике "10^25 игр для 486". Помню, что испытывал перманентный WTF от эклектичности происходящего, левел дизайна и бескрайних уровней. Было больше похоже на технодемку, в то время как дум до сих выглядит законченным продуктом.

После прочтения уже десятков статей на хабре на эту тему я понимаю, что статьи не могут поменять ровно ничего. Лучший способ распространить свое видение - это делом показывать, что оно лучше. Если в ваших проектах любой баг обнаруживается за минуты, любая доработка безболезненно влезает в рамки спринта и не приносит регресса, любой джун въезжает в процесс за неделю - то есть смысл делиться этой фактурой с коллегами, мягко продвигать свой подход. Если все действительно классно, то коллеги проникнуться и понесут знание в свои проекты и другие команды.

Правила игры позволяли организация вписываться в эту программу? Позволяли. Банки увидели в этих правилах для себя профит и вписались. Банки виноваты лишь в том, что не держат ясновидящих в штате.

А развод - это как раз когда правила игры меняются на 180 градусов каждые 3 месяца.

Почитать вряд ли, а у очевидцев поспрашивать можно. Примерно так было:

  • Размещать ИТ и бизнес в одном флаконе плохо. Бизнес лезет в ИТ своими липкими ручонками и мешает работать. Айда весь ИТ в Сбертех

  • Осваиваем средства на переезды, бюрократию, брендинг, корпоративную ерунду и т.д.

  • Размещать ИТ и бизнес в разных флакона плохо. ИТ не чувствует потребности бизнеса и живет своей жизнью. Айда весь ИТ назад в Сбер. В Сбертехе оставляем только т.н. "платформенные сервисы".

  • Осваиваем средства на переезды, бюрократию, брендинг, корпоративную ерунду и т.д.

А потом ввели назад. См. буффонаду историю Сбера и Сбертеха.

статья не для тех, кто "уже умеет", а для тех, кто только встал на эти грабли

Мне кажется, вам указывают не на сами грабли с подзапросом к связанным сущностям, а на то что вы от имени образовательного ресурса демонстрируете сразу пачку антипаттернов, с последствиями которых героически боретесь. В статье критически не хватает сноски о том, что IRL подобные фокусы с доступом к репо из контроллера просто неприемлемы, а в архитектуре приложения должен главенствовать принцип изоляции и слабой связности. И это не вопрос вкусовщины и разнообразия мнений в интернете, а реальная практика, к которой вы якобы готовите своих студентов.

Ну буррито же неправославно. Лучше кулебяка.

Hidden text

Кулебяка - это расстегай в категории эндовыпечки

Классный развод получился. Начали с обещаний отмены налогов и прочих райских кущей. Закончили отсрочкой и ипотекой для полутора сотрудников ФГУП НИИ ТочВычМашСтыдСрам

Проблема оплаты АСУТП в том что автоматизацию почти всегда можно заменить на "ручной труд"

Скорее проблема в том, что нет сценариев, когда АСУТП приносит сверхприбыль. Ну да, обмазали цех автоматикой, получили какой-то буст в производительности, лет через 5 оно может даже окупится... В это время студенты-ухари склепали очередной тикток и грамотно его раскрутили - сорвали 1000% прибыли просто из воздуха

А можно узнать предполагаемый православный синтаксис для ФП и реактивщины? Map, flatmap, bind, monad, either, yield, debounce, throttle и т.д.

Обращаюсь ко всем молодым, у кого в голове всплывает вопрос из заголовка. Ответ на него утвердительный. Даже в статье контр-агрументов нет.

Можно убеждать себя, что вы тоже ИТшники, тоже программисты, тоже занимаетесь сложными и интересными задачами. Это все так, но есть 2 проблемы. Первая: рынок так не думает. Вторая: жизнь одна. Выводе делайте сами, и чем раньше, тем лучше. Я 7 лет назад сбежал из АСУ ТП в "обычное" ИТ и ни разу не пожалел.

HTML-отклик полностью сам себя описывает

Здесь и далее какая-то игра в наперстки. Ничто не мешает включить элементы HATEOAS в JSON, ничто не мешает убрать их из HTML. Все зависит от задач данного апи. В большинстве случаев было бы странно заставлять клиента начинать с "елдиной точки входа" и пробегать через N промежуточных запросов ради получения результата. Поэтому и существуют сваггер и апи доки.

Практика разошлась с описанной 20 лет назад теорией - бывает. А перегрузка и неправильное использование терминов в IT вещь в принципе нередкая.

Cyberforum.ru

Оно еще живо? Лет 5 назад сайберфорум был местом, где на вопрос "как на языке А сделать Б" отвечали или "а тебе зачем" или "возьми лучше язык Е и сделай Ж".

Информация

В рейтинге
910-й
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Старший
Java
Kotlin