Ну просто человек может не знать абревиатуру, но писать хороший код. Знание или не знание самого термина не особо помогает при опросе кандидата. Написать или найти недостаток в коде как по мне более действенный метод оценки кандидата
Вообще подобные вопросы на мой взгляд бесполезные. Те если работодатель реально хочет проверить соискателя то нужно или дать код написать или скажем оценить уже написанный. А спрашивать просто названия шаблонов такое себе на мой взгляд. Или вопросы на расшифровку solid. Это ещё глупее как по мне.
Ну так то да, но в статье преподносится вытягивание проекта джунами. т.е. понятное дело что без джунов никуда, но все же в реале проект тащат мидлы по большей части и сеньеры.
Хотя возможно я не правильно понял посыл статьи
Спорное утверждение. Данный инструмент должен уменьшить объем кода и как следствие проект меньше завязан на разработчика. Инфу же по этой либе любой может легко в доках прочитать.
Запутанная в ifах логика же наоборот разработчика делает более «бесценным» так как только он понимает, что там происходит
Спасибо за статью. Скажите а данная машина состояний персистентна? Что будет если приложение остановили, когда процесс был в каком — то промежуточном статусе(не в начальном и не в end), а затем включим: процесс будет потерян, продолжится или как?
PS: если это было в статье и я не заметил ответ на мой вопрос — прошу прощения
Должен ли новичок в программировании выбирать заведомо более сложную Java? Наверное, тоже нет.
Вообще не согласен. Не знаешь java->не понимаешь, что в итоге получается из kotlin кода -> велика вероятность написания некачественного кода.
Это из разряда — зачем учить летчиков в летном училище, когда есть автопилот
Спасибо, что прочли.
У меня лично опыта работы с подобными отчетами нет. Но пользуясь API camunda я думаю можно такие отчеты самим сделать. Апишка довольно крутая и позволяет вытаскивать что-то типо — число процессов которые прошли такой то шаг успешно или число процессов, которые сейчас на таком то шаге и тд
Спасибо вам, что прочитали.
1. Да храним прям в спринговом приложении
2. Процесс можно обновить на лету через Camunda Modeler. Лично мне этот вариант не нравится, ибо на мой взгляд это не особо целостно. Перенакатить модуль не особо сложно.
Ну процессы все-таки разработчики разрабатывают, поддерживают и баги в них фиксят. И если это не удобный для них инструмент, то на мой взгляд это немаловажно
1. Контроль версий через снепшоты — вообще не серьезно. А код-ревью как проводить? Давайте будем честны, что такую версионность можно взять и положить на далекую полку ибо это крайне неудобно
2. В 2017 году java8. Ну наконец — то
3. Если не вдаваться в демагогию про то как лучше админить, а просто взять как было и как стало: раньше админы постоянно чинили IBM и испытывали массу стресса из за этого. Сейчас когда каждое приложение в облаке все стало для них гораздо проще. Да и для нас.
4. Сравнивать эти продукты как раз надо. Одни и те же задачи решаем и на одном процессы — костыли, на другом — современные и тестируемые приложения в облаках
5. По поводу переферии — да она нужна. Метрики например написать. Но это не так долго делается. Гораздо больше времени теряется при использовании IBM BPM на вообще непонятно что:
a. умер сервер — давайте все посидим подождем пока админы починят
b. давайте разбираться с шаманством для Юнит тестирования. Зачем нам стандартные практики когда есть IBM BPM Testing Asset. Кстати интересно за него отдельная плата или он в комплекте
c. целый день устанавливать вебсферу на локальную машину. или как вариант пользоваться общей дев средой, которую тоже кстати кто-то админить должен
и список этот можно продолжать довольно долго
К слову камунду от нулевой компетенции до проекта на проде мы выкатили за 3 месяца. Я сомневаюсь, что дай сейчас продукт от IBM без компетенции получится сделать то же самое соответствующего качества
По каждому пункту будет очень долго дискутировать, но насчет богатых возможностей — действительно они есть. Например UCA довольно интересная штука, да и то что есть конструктор интерфейсов — тоже скорее плюс чем минус. Понятно, что конструктор убогий, но если цель сделать быстро MVP — почему нет.
А так да. Не самый приятный инструмент.
1. Речь про переиспользование кода процесса?
2. Ну это риторический вопрос на самом деле ибо сложно оценить сложность рефакторинга. Наверно сложнее, ибо при редактировании кода есть такой момент как скомпиллилось-не скомпиллилось. Тут только на этапе запуска будет ясно, что процесс поломался. Но для того, чтобы ничего не поломать мы пишем юнит тесты на процесс. Несколько раз действительно нас это выручало
3. Ну это не очень удобно на мой взгляд. Я не очень много видел деления процесса на подпроцессы
4. Не очень вопрос понял. Отвечу как понял — запустить процесс прям на лету из среды Camunda Modeler, не стартуя приложение, как в IBM нельзя(ну или я не знаю как). Ну честно говоря лично мне это особо нужно не было, ибо запустить бутовое приложение не особо долго, а проверить, что ничего не поломал при рефакторинге можно в принципе юнит тестами
5. Аналитики точно пользуются. Зачастую они сами их строят. Подправить можно и можно даже на лету подменить схему, но ИМХО делать этого не стоит. Все — таки это не стоит делать если на это нет прям супер-пупер критичной необходимости, ну или если это не прод
Хотя немного приврал. Проект можно архивом выгрузить и уже по файлам лазить и из этого какую-то пользу извлекать. Но будем честны — в этом мало приятного(
Хотя возможно я не правильно понял посыл статьи
тоже самое можно сказать про то, что круто быть одному на проекте, потому что ты там все знаешь и контроллируешь
В два раза больше работы, так как за джуниорами глаз да глаз
Запутанная в ifах логика же наоборот разработчика делает более «бесценным» так как только он понимает, что там происходит
PS: если это было в статье и я не заметил ответ на мой вопрос — прошу прощения
Вообще не согласен. Не знаешь java->не понимаешь, что в итоге получается из kotlin кода -> велика вероятность написания некачественного кода.
Это из разряда — зачем учить летчиков в летном училище, когда есть автопилот
У меня лично опыта работы с подобными отчетами нет. Но пользуясь API camunda я думаю можно такие отчеты самим сделать. Апишка довольно крутая и позволяет вытаскивать что-то типо — число процессов которые прошли такой то шаг успешно или число процессов, которые сейчас на таком то шаге и тд
1. Да храним прям в спринговом приложении
2. Процесс можно обновить на лету через Camunda Modeler. Лично мне этот вариант не нравится, ибо на мой взгляд это не особо целостно. Перенакатить модуль не особо сложно.
2. В 2017 году java8. Ну наконец — то
3. Если не вдаваться в демагогию про то как лучше админить, а просто взять как было и как стало: раньше админы постоянно чинили IBM и испытывали массу стресса из за этого. Сейчас когда каждое приложение в облаке все стало для них гораздо проще. Да и для нас.
4. Сравнивать эти продукты как раз надо. Одни и те же задачи решаем и на одном процессы — костыли, на другом — современные и тестируемые приложения в облаках
5. По поводу переферии — да она нужна. Метрики например написать. Но это не так долго делается. Гораздо больше времени теряется при использовании IBM BPM на вообще непонятно что:
a. умер сервер — давайте все посидим подождем пока админы починят
b. давайте разбираться с шаманством для Юнит тестирования. Зачем нам стандартные практики когда есть IBM BPM Testing Asset. Кстати интересно за него отдельная плата или он в комплекте
c. целый день устанавливать вебсферу на локальную машину. или как вариант пользоваться общей дев средой, которую тоже кстати кто-то админить должен
и список этот можно продолжать довольно долго
К слову камунду от нулевой компетенции до проекта на проде мы выкатили за 3 месяца. Я сомневаюсь, что дай сейчас продукт от IBM без компетенции получится сделать то же самое соответствующего качества
А так да. Не самый приятный инструмент.
кодапроцесса?2. Ну это риторический вопрос на самом деле ибо сложно оценить сложность рефакторинга. Наверно сложнее, ибо при редактировании кода есть такой момент как скомпиллилось-не скомпиллилось. Тут только на этапе запуска будет ясно, что процесс поломался. Но для того, чтобы ничего не поломать мы пишем юнит тесты на процесс. Несколько раз действительно нас это выручало
3. Ну это не очень удобно на мой взгляд. Я не очень много видел деления процесса на подпроцессы
4. Не очень вопрос понял. Отвечу как понял — запустить процесс прям на лету из среды Camunda Modeler, не стартуя приложение, как в IBM нельзя(ну или я не знаю как). Ну честно говоря лично мне это особо нужно не было, ибо запустить бутовое приложение не особо долго, а проверить, что ничего не поломал при рефакторинге можно в принципе юнит тестами
5. Аналитики точно пользуются. Зачастую они сами их строят. Подправить можно и можно даже на лету подменить схему, но ИМХО делать этого не стоит. Все — таки это не стоит делать если на это нет прям супер-пупер критичной необходимости, ну или если это не прод