Давай так - имея только код ориентироваться будет на круг всяко легче, чем имея код И bpmn, который связан с кодом совершенно не очевидным образом. К тому же у нас микросервисный мир, в котором есть такая штука, как api, которое является единой точкой входа в сервис, имея эту точку разматывать клубок становится сильно легче, а для камунды ничего подобного нет - все в не явном виде на текстовых метках, по которым нет толком ни поиска, ни навигации.
Всего одну? Вы понимаете, что по сути каждый элемент bpmn будет ссылаться на "какой-то код" - каждый кубик, каждая стрелка будет смотреть в java-код. Не имея быстрого и надежного средства навигации туда-сюда поддержка и развитие превратится в адЪ, где львиная доля времени будет уходить на поиски откуда ноги растут.
А теперь задание со звездочкой - быстро и на кончиках пальцев понять в каком месте bpmn используется произвольный кусок кода? И в обратную сторону - какой конкретно код лежит под каждым кубиком диаграммы? Пока двусторонний переход из bpmn в код и обратно нельзя будет сделать по привычному ctrl+клик использование камунды в продакшене будет мучением для развития и поддержки.
Ну, и как волшебным образом "смежная команда" может оценить сотрудников соседей, если они не погружены и не вовлечены в то, кто что делает у этих самых соседей? Отдельные команды - отдельное планирование.
А откуда возьмутся эти "большие числа"? Команда редко больше 12-15 человек, а кто тебя еще знает достаточно хорошо, чтобы определить твою компетентность? В соседних отделах как ни крути, а знать тебя будут довольно однобоко, и что бы такой "360" сделать адекватным и информативным в него придется ввалить столько усилий, что мама не горюй.
Внедрить 360-фидбэк. Мнение команды о человеке часто бывает куда более объективнее, чем мнение сторонних менеджеров, зажатых в тисках квот.
Интересно, в каком мире живет тот, кто это написал? Потому что в реальном мире все эти "360" не имеют с реальностью ничего общего. Что меня, как сотрудника, должно мотивировать объективно оценивать коллегу? Да ничего, нет такой мотивации. А вот мотивов оценить его НЕ объективно полным-полно. Мы с ним друзья-кореша? Везде высший балл! Мы с ним не в ладах? На тебе низкие оценки. все эти "360" это просто попытка переложить ответственность с больной головы на здоровую - это не мы тебе низкие оценки дали, а твои же коллеги, разбирайся с ними. Конечно разберусь - вот будет очередной "360" и я им покажу!
Пожалуй, одно из самых заметных изменений для каждого разработчика
Вы издеваетесь? Каждому разработчику давно плевать где там в коде public static void main(String[] args) - это одна единственная строка, которая генерируется за разработчика, и видит он ее примерно никогда. Изменение, ё-мое...
Краткое содержание: если слышишь "мы семья - значит тебя пытаются нае... обмануть с целью извлечения из тебя максимальной выгоды. Всегда помни, что ты за деньги продаешь 8 часов своей жизни из 5 дней в неделю, и на этом все.
А кто говорил о проблеме? Никакой проблемы нет, есть свершившийся факт - jpa прячет от разработчика sql. Идите и перечитайте первое мое сообщение, там именно об этом. Если для вас не проблема, что между вами и БД появляется прослойка, которая прячет от вас конечный запрос, который будет выполнен, и лишает вменяемых средств воздействия на этот запрос, то счастья вам и здоровья, продолжайте изгаляться с энтити графом когда что-то идет не так.
Если подобную логику делать самому получится просто свой велосипед.
Нет. Велосипед получился, когда написание запросов забрали у разработчика, и возложили на искуственного идиота. Но этот велосипед вполне себе едет, многим нравится.
А что, эти аннотации как-то говорят разработчику какой итоговый sql будет сформирован? Они описывают объекты базы данных, а вовсе не запрос, который к ним будет выполняться.
Ну, как это "не про то", когда именно эта часть в jpa уехала настолько под капот, что что б увидеть запрос нужно параметр конфиги менять? Именно про то!
Использовать entity graph для получения правильных запрсов.
Сначала берем jpa что б не думать о sql, а потом начинаем танцевать нижний брейк с энтити графом, что б получить "правильный запрос". Хех, что здесь может быть не так?! =))))
Какие еще "накладные расходы"? GC в эрланге за счет иммутабельности работает буквально моментально - просто берет и чистит состояние процесса, по сути, без долгой беготни по ссылкам, поскольку их нет.
И ни слова про зарплату, про ее индексацию и ее повышение. Вы там точно ожидания мониторили, а не фантазии?
Новый правленый bpmn точно так же нужно выводить в прод, его точно так же нужно тестировать. На круг сам по себе его наличие ничего не ускоряет.
Давай так - имея только код ориентироваться будет на круг всяко легче, чем имея код И bpmn, который связан с кодом совершенно не очевидным образом. К тому же у нас микросервисный мир, в котором есть такая штука, как api, которое является единой точкой входа в сервис, имея эту точку разматывать клубок становится сильно легче, а для камунды ничего подобного нет - все в не явном виде на текстовых метках, по которым нет толком ни поиска, ни навигации.
вызывает функцию описанную в JAVAВсего одну? Вы понимаете, что по сути каждый элемент bpmn будет ссылаться на "какой-то код" - каждый кубик, каждая стрелка будет смотреть в java-код. Не имея быстрого и надежного средства навигации туда-сюда поддержка и развитие превратится в адЪ, где львиная доля времени будет уходить на поиски откуда ноги растут.А теперь задание со звездочкой - быстро и на кончиках пальцев понять в каком месте bpmn используется произвольный кусок кода? И в обратную сторону - какой конкретно код лежит под каждым кубиком диаграммы? Пока двусторонний переход из bpmn в код и обратно нельзя будет сделать по привычному ctrl+клик использование камунды в продакшене будет мучением для развития и поддержки.
А там еще и перец может быть, который в БД вообще не храниться...
Ну, и как волшебным образом "смежная команда" может оценить сотрудников соседей, если они не погружены и не вовлечены в то, кто что делает у этих самых соседей? Отдельные команды - отдельное планирование.
А откуда возьмутся эти "большие числа"? Команда редко больше 12-15 человек, а кто тебя еще знает достаточно хорошо, чтобы определить твою компетентность? В соседних отделах как ни крути, а знать тебя будут довольно однобоко, и что бы такой "360" сделать адекватным и информативным в него придется ввалить столько усилий, что мама не горюй.
Всех много, а всего мало - и всего на всех не хватит.
Внедрить 360-фидбэк.Мнение команды о человеке часто бывает куда более объективнее, чем мнение сторонних менеджеров, зажатых в тисках квот.Интересно, в каком мире живет тот, кто это написал? Потому что в реальном мире все эти "360" не имеют с реальностью ничего общего. Что меня, как сотрудника, должно мотивировать объективно оценивать коллегу? Да ничего, нет такой мотивации. А вот мотивов оценить его НЕ объективно полным-полно. Мы с ним друзья-кореша? Везде высший балл! Мы с ним не в ладах? На тебе низкие оценки. все эти "360" это просто попытка переложить ответственность с больной головы на здоровую - это не мы тебе низкие оценки дали, а твои же коллеги, разбирайся с ними. Конечно разберусь - вот будет очередной "360" и я им покажу!
Вот нет других проблем при изучении языка - сигнатура метода main все портит...
Пожалуй, одно из самых заметных изменений для каждого разработчикаВы издеваетесь? Каждому разработчику давно плевать где там в коде
public static void main(String[] args)- это одна единственная строка, которая генерируется за разработчика, и видит он ее примерно никогда. Изменение, ё-мое...Краткое содержание: если слышишь "мы семья - значит тебя пытаются нае... обмануть с целью извлечения из тебя максимальной выгоды. Всегда помни, что ты за деньги продаешь 8 часов своей жизни из 5 дней в неделю, и на этом все.
А кто говорил о проблеме? Никакой проблемы нет, есть свершившийся факт - jpa прячет от разработчика sql. Идите и перечитайте первое мое сообщение, там именно об этом. Если для вас не проблема, что между вами и БД появляется прослойка, которая прячет от вас конечный запрос, который будет выполнен, и лишает вменяемых средств воздействия на этот запрос, то счастья вам и здоровья, продолжайте изгаляться с энтити графом когда что-то идет не так.
Если подобную логику делать самому получится просто свой велосипед.Нет. Велосипед получился, когда написание запросов забрали у разработчика, и возложили на искуственного идиота. Но этот велосипед вполне себе едет, многим нравится.
А что, эти аннотации как-то говорят разработчику какой итоговый sql будет сформирован? Они описывают объекты базы данных, а вовсе не запрос, который к ним будет выполняться.
JPA/ORM это не про то, чтобы не думать об sqlНу, как это "не про то", когда именно эта часть в jpa уехала настолько под капот, что что б увидеть запрос нужно параметр конфиги менять? Именно про то!
Использовать entity graph для получения правильных запрсов.Сначала берем jpa что б не думать о sql, а потом начинаем танцевать нижний брейк с энтити графом, что б получить "правильный запрос". Хех, что здесь может быть не так?! =))))
Какие еще "накладные расходы"? GC в эрланге за счет иммутабельности работает буквально моментально - просто берет и чистит состояние процесса, по сути, без долгой беготни по ссылкам, поскольку их нет.
А давно эрланг стал интерпретируемым?
А почему приговор-то?