Ну, минусов-то тут не за что. Нормальный вопрос, на нормальную (хотя и далеко не новую тему).
Попробую дать свой ответ.
Те кто думает, будто манипулирование коллекциями в таком стиле легче читается, как минимум лукавят. Для кого-то может и легче, но это дело субъективное. Вопросу тут не в легкости. Дело в другом — такой функциональный стиль удобнее компонуется, потому что по сути это функции, которые можно объединять в формулы, спокойно параллелить вычисления (если данные имутабельны и нет побочных эффектов), причем правильность компоновки в значительной степени за нас проверит компилятор.
>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.
Ну, кстати Activity — не самый худший вариант. Я бы сказал, что тут имеет место оптимальное разделение обязанностей между движком BPM, и всем остальным (UI, интеграциями, версионированием проекта). В том же случае IBM BPM это например не так. Коммит-логов в нормальном виде там кстати тоже нет (((
В базе данных роль файлов играют схемы и таблицы. Смещения и адреса лежат ниже уровня, доступного пользователю. Так что разницы в общем почти никакой и нет.
Вот смотрите — вы нарисовали красивую картинку «Запрос на предоставление отпуска». Выглядит неплохо, если забыть на время, что это — код. И понять можно. А теперь представьте себе процесс, где диаграмм штук скажем 50 (а это не самый крупный, какой я видел и делал), и каждая из них содержит штук 20 и более элементов. И вы допустим разработчик, и пошли вы в отпуск. Все было хорошо, до тех пор, пока вы не вернулись, и не увидели, что процесс кто-то поменял.
Вот у IBM в этом случае все фигово до безобразия. Диффа нет, merge тоже нет.
Расскажите, что у вас? Есть ли версионирование процессов, можно ли сделать ветку, можно ли сравнить, что было неделю назад с тем что сейчас, можно ли сделать merge?
Вообще-то в тех реальных «адски сложных» бизнес процессах, которые я делал лично и видел, часть BPM была где-то процентов 10 от силы. Ну может иногда 30. А остальные 70 как раз составляли логика UI, и работа с разного рода интеграциями. Поэтому насчет «дешевле» у меня как раз масса вопросов. По той простой причине, что программировать в виде диаграмм в BPM — это ужасно. По сравнению с нормальным процессом разработки на нормальных инструментах — это как в каменный век вернуться.
Видите ли, я не знаю, какие там BPMS вы изучали, а я три с лишним года проработал на IBM BPM. И там можно не просто писать запросы — там полноценный язык программирования, на выбор — либо javascript (Mozilla Rhino) либо чуть посложнее — Java. И формы там допиливаются до любого состояния — с лукапами, с rest запросами, направо и налево. И SQL-запросы пишутся какие угодно, к любой базе. Только все равно получается паршиво.
В принципе, можно интегрироваться с чем угодно. Но только в принципе.
Проблема в том, что как только вы начали писать такой код — вашему процессу как раз и будут опаньки, потому что глядя на диаграмму вы больше ничего уже не понимаете. Вы не видите кода, вы не знаете, что он делает, откуда берет и куда кладет данные. Диаграмма больше не отражает почти ничего. И самый лучший, по моему опыту, способ интегрироваться с каким-либо UI, если он вам нужен — это не делать его в BPM системе вообще. Делать где угодно, в каком угодно виде. На любом инструменте.
Ну, про удалиться и додумать дома — это ведь тоже не я придумал. Я лишь говорю, что люди разные, а время интервью ограничено. Да, возможности проверить напрямую нет. Но и делать из этого сразу выводы рановато.
Вы что-то себе додумали из моего ответа, я такого не говорил. Я лишь сказал, что если у человека не возникли прямо сейчас уточняющие вопросы — это ровным счетом ничего пока не значит. Вот если они не возникли вообще — да, это плохо.
Прежде чем куда-то переходить, нужно для начала продемонстрировать, что семантический дифф реально удобнее обычного, а этого пока не видать. Даже для простого в целом xml я не видел реально работающей технологии. При этом совершенно понятно, что работать с AST внутри кода намного удобнее, чем с текстом. И скажем рефакторинг вряд ли кто-то делает в здравом уме на тексте. Но с показом человеку все хуже.
Общаться со сложным заказчиком и формулировать уточняющие вопросы на ходу прямо в процессе разговора — это все равно две разные вещи. Иногда полезно подумать, прежде чем уточнять.
Мы говорим про код, который не являлся бы текстом. Вон чуть выше коммент от Portnov, с которым я вполне согласен — все известные мне попытки уйти от текстового представления практически сводятся примерно к перечисленным, и все они очень плохи на практике. В том числе потому, что практически работающего диффа нигде нет. То что вы показали, хотя бы для java, выглядит неплохо, но почему-то в реальной жизни все что встречается — это структурный поиск/замена у IDEA.
На самом деле у меня есть подозрение, почему это так. Текст это одномерная структура. Как только мы уходим от одномерности к многомерности, аналогичные алгоритмы на дереве или графе сразу становятся значительно более дорогими вычислительно. И значительно более сложными для понимания. Что косвенно подтверждается комментарием к 8 ответу по вашей ссылке — сложность O(n^2) это ни в какие ворота обычно.
На мой взгляд, вопросы реально хорошие. Причем годятся и для разработчика — с некоторыми изменениями, разумеется.
>Что, по моему мнению, печально.
Ну это вы зря, кстати. Есть такие люди, которым надо подумать, прежде чем задачать уточняющие вопросы. Думать в обстановке собеседования не очень комфортно, поэтому вопросы вполне могли возникнуть позже. Те кто уточнил сразу — наверное и вероятно лучше остальных, но браковать только по этому признаку преждевременно.
А кто сказал, что PalmOS без файлов? У нее просто немного специфическая структура, там грубо говоря одна только база данных фиксированной структуры, и все. Если это база — то оно что-ли уже не файлы?
Я про этого самого автора, хоть и отвечал в данном случае не ему.
Понимаете, я бы лично для начала хотел бы поглядеть на этот самый семантический дифф. Исходя из того, что автор предлагает в комментах обычный дифф для xml, у него такого на самом деле нет. И я такого никогда не видел. Т.е. проблема (одна из главных) инструментов, которые чуть выше обсуждаются, для работы с UML, с BPMN, которого я нахлебался по самое немогу, и другими вполне читаемыми человеком форматами — типа SVG, ровно в том, что нет хорошо сформулированной семантики такого диффа.
Ну хоть какой-нибудь паршивенький семантический дифф для SVG картинок? Вы думаете я против? Я только за — но я никогда не видел ни одного хорошего примера подобного решения.
Хм. Понимаете, автор всерьез уверен, что xml сравнивается диффом. Ну о чем тут можно говорить? Сравнивается — ну отлично, пусть пойдет, и попробует сравнить два документа word, где все содержимое в одной строке (вторая — xml заголовок).
Ну не понимает человек, что <a x=«a» y=«b»/> и <a y=«b» x=«a»></a> это семантически одинаковые документы, а дифф при этом будет весьма и весьма толстый.
Что можно поменять в UML (или BPMN) скажем стрелочку, «чтоб было красиво», семантически это останется тоже самое — а дифф мы снова поимеем при этом неизвестного размера. И самое главное — мы не сможем выделить из него то, что на самом деле важно, и то, что является украшательством.
Т.е. даже если формат не проприетарный, как BPMN, а вместо менеджеров диаграммами программируют бизнес-аналитики — это мало что меняет. Все равно на выходе из таких идей как правило получается один г****код.
Теоретически — сравнивается. А практически — это дает столько мусора, что выделить из этого шума полезные данные очень сложно. Т.е. как инструмент для починки, когда что-то сломалось — это работает, а как повседневный инструмент — нет.
Дело в том, что BPMN, а еще SVG и скажем WordML, а еще UML-диаграммы где-нибудь в Rational — они все xml. SSIS кстати тоже. Но поскольку предполагается, что рисовать их вы все-таки будете инструментом, сериализованное представление в xml может быть любого формата.
Кроме всего прочего, разработчики инструментов вовсе не горят желанием показывать вам xml представление. Я не про всех, конечно. Многие.
Так сложилось, что на прошлом месте работы у меня основным инструментом был язык BPMN, на котором бизнес-процессы описываются в виде схемок из квадратиков и стрелочек. А на текущем — SQL Server Integratiion Services, где в таком же виде описываются так называемые процессы ETL. Так я просто скажу — терпеть не могу и тех и других.
Потому что и те и другие — не текст. Потому что в итоге сделать diff (а также и merge) мы не можем, картинки не сравниваются и не объединяются, потому что компонуются программы из таких блоков прямо скажем фигово (по сравнению с функциональным программированием и ООП). Потому что языка картинок не хватает для того, чтобы реализовать все нужное, и к нему в реальности быстро добавляется обычный классический язык программирования — и мы сразу имеем зоопарк из двух языков, а то и из трех. Потому что у каждого квадратика есть еще и атрибуты, и немало, которые становятся еще и третьим способом представления информации о процессе.
Попробую дать свой ответ.
Те кто думает, будто манипулирование коллекциями в таком стиле легче читается, как минимум лукавят. Для кого-то может и легче, но это дело субъективное. Вопросу тут не в легкости. Дело в другом — такой функциональный стиль удобнее компонуется, потому что по сути это функции, которые можно объединять в формулы, спокойно параллелить вычисления (если данные имутабельны и нет побочных эффектов), причем правильность компоновки в значительной степени за нас проверит компилятор.
>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.
Вот смотрите — вы нарисовали красивую картинку «Запрос на предоставление отпуска». Выглядит неплохо, если забыть на время, что это — код. И понять можно. А теперь представьте себе процесс, где диаграмм штук скажем 50 (а это не самый крупный, какой я видел и делал), и каждая из них содержит штук 20 и более элементов. И вы допустим разработчик, и пошли вы в отпуск. Все было хорошо, до тех пор, пока вы не вернулись, и не увидели, что процесс кто-то поменял.
Вот у IBM в этом случае все фигово до безобразия. Диффа нет, merge тоже нет.
Расскажите, что у вас? Есть ли версионирование процессов, можно ли сделать ветку, можно ли сравнить, что было неделю назад с тем что сейчас, можно ли сделать merge?
В принципе, можно интегрироваться с чем угодно. Но только в принципе.
Проблема в том, что как только вы начали писать такой код — вашему процессу как раз и будут опаньки, потому что глядя на диаграмму вы больше ничего уже не понимаете. Вы не видите кода, вы не знаете, что он делает, откуда берет и куда кладет данные. Диаграмма больше не отражает почти ничего. И самый лучший, по моему опыту, способ интегрироваться с каким-либо UI, если он вам нужен — это не делать его в BPM системе вообще. Делать где угодно, в каком угодно виде. На любом инструменте.
На самом деле у меня есть подозрение, почему это так. Текст это одномерная структура. Как только мы уходим от одномерности к многомерности, аналогичные алгоритмы на дереве или графе сразу становятся значительно более дорогими вычислительно. И значительно более сложными для понимания. Что косвенно подтверждается комментарием к 8 ответу по вашей ссылке — сложность O(n^2) это ни в какие ворота обычно.
>Что, по моему мнению, печально.
Ну это вы зря, кстати. Есть такие люди, которым надо подумать, прежде чем задачать уточняющие вопросы. Думать в обстановке собеседования не очень комфортно, поэтому вопросы вполне могли возникнуть позже. Те кто уточнил сразу — наверное и вероятно лучше остальных, но браковать только по этому признаку преждевременно.
Понимаете, я бы лично для начала хотел бы поглядеть на этот самый семантический дифф. Исходя из того, что автор предлагает в комментах обычный дифф для xml, у него такого на самом деле нет. И я такого никогда не видел. Т.е. проблема (одна из главных) инструментов, которые чуть выше обсуждаются, для работы с UML, с BPMN, которого я нахлебался по самое немогу, и другими вполне читаемыми человеком форматами — типа SVG, ровно в том, что нет хорошо сформулированной семантики такого диффа.
Ну хоть какой-нибудь паршивенький семантический дифф для SVG картинок? Вы думаете я против? Я только за — но я никогда не видел ни одного хорошего примера подобного решения.
Ну не понимает человек, что <a x=«a» y=«b»/> и <a y=«b» x=«a»></a> это семантически одинаковые документы, а дифф при этом будет весьма и весьма толстый.
Что можно поменять в UML (или BPMN) скажем стрелочку, «чтоб было красиво», семантически это останется тоже самое — а дифф мы снова поимеем при этом неизвестного размера. И самое главное — мы не сможем выделить из него то, что на самом деле важно, и то, что является украшательством.
Т.е. даже если формат не проприетарный, как BPMN, а вместо менеджеров диаграммами программируют бизнес-аналитики — это мало что меняет. Все равно на выходе из таких идей как правило получается один г****код.
Дело в том, что BPMN, а еще SVG и скажем WordML, а еще UML-диаграммы где-нибудь в Rational — они все xml. SSIS кстати тоже. Но поскольку предполагается, что рисовать их вы все-таки будете инструментом, сериализованное представление в xml может быть любого формата.
Кроме всего прочего, разработчики инструментов вовсе не горят желанием показывать вам xml представление. Я не про всех, конечно. Многие.
Знаете, мне будет совершенно не жалко. Если человек пытается меня оценивать по таким идиотским критериям — нам с ним не по дороге.
И главный вопрос — зачем это тут? Оно же еще и перевод…
Потому что и те и другие — не текст. Потому что в итоге сделать diff (а также и merge) мы не можем, картинки не сравниваются и не объединяются, потому что компонуются программы из таких блоков прямо скажем фигово (по сравнению с функциональным программированием и ООП). Потому что языка картинок не хватает для того, чтобы реализовать все нужное, и к нему в реальности быстро добавляется обычный классический язык программирования — и мы сразу имеем зоопарк из двух языков, а то и из трех. Потому что у каждого квадратика есть еще и атрибуты, и немало, которые становятся еще и третьим способом представления информации о процессе.