Если честно, я не спец по 1С, не знаю, почему ограничения там задаются в коде. В Java полно вариантов задавать их декларативно, вот тут неплохой обзор.
Я имел в виду сравнение с алгоритмами. Код с ветвлениями, условиями, вызовами функций и т.п. Что-то вроде (фантазирую) «проверить остатки, если недостаточно проверить дату следующего поступления или отменить другой заказ, если этот клиент имеет приоритет».
В визуальном программировании как таковом нет ничего плохого. Там где оно уместно, это действительно может и время экономить и порог входа снижать. Имхо, в конструкторе отчетов оно как раз уместно. Смысл в том, что low code платформы пихают его везде, не особо предоставляя альтернативу.
Объекты, регистры и даже простые запросы — это довольно близко к «декларативщине». Здесь нет логики, и поэтому на мой взгляд нет ничего плохого в том, чтобы описывать их в визуальной среде. Это может даже быть удобнее и быстрее кода в каких-то случаях. То же касается и интерфейса, неважно с относительным или абсолютным позиционированием.
Логику они все же пишут в коде, а не блок схемами.
1Совцы все-таки пишут код. Мышкой они интерфейс рисуют. Это ближе к классическому RAD. По возможностям и скорости разработки любому low code до 1С как до Китая…
CUBA поддерживает кластера на уровне web и middleware слоев. Микросервисы вполне на CUBA пишутся. Возможно для каких-то сценариев они будут «жирноваты», но в общем случае это не проблема.
Спасибо! На самом деле Vaadin (построенный на GWT) — основной UI. Polymer клиент — альтернатива нестандартных интерфейсов, например порталов для внешних пользователей.
Если только ооочень издалека )) Drupal — CMS, строить на нем учетную систему с сотней-другой экранов и справочников например вы врядли станете. Скорее уж с 1С сравнение ближе. Или с Delphi.
Совсем нет. Confluence — это упрощенно говоря внутренняя вики, то есть средство хранения и совместной работы над статьями. ТЕЗИС — это ECM-система, призванная в первую очередь автоматизировать и регламентировать бизнес-процессы организаций.
Сейчас это ограничение контролируется только в среде разработки — CUBA Studio. Бесплатная версия просто не открывает проекты большего размера. Никаких ограничений на сущности или сессии в рантайме больше нет — после того, как вы написали приложение, вы можете делать с ним все что хотите. Собственно, избавить конечные приложения от лицензионных ограничений и было основной целью изменения политики.
Аналогично, организации не всегда нужно автоматизировать все и сразу мегавнедрением ECM (waterfall). Такие внедрения часто заканчиваются плачевно в силу разных причин. Лучше решать задачи постепенно, итерациями — но понимая общую цель и стратегию.
REvseev, я думаю, что частично ответил в комментарии выше. Конечно, процессы должны быть формализованы, Станислав не предлагает заменить процессы свободным общением. Но желательно, чтобы они отражали реальные эффективные рабочие процессы, сохраняя возможность изменений с минимальными трудозатратами — как с организационной, так и с технической точки зрения.
zhavoronok, статья в первую очередь о том, что стандартные agile практики ИТ могут также хорошо подходить не-ИТ бизнесу. И если вы внедряете у себя ECM систему, нужно в первую очередь смотреть не на стандарты, а на то, что реально происходит в вашей организации, автоматизировать то, что даст наибольший эффект, и так, чтобы людям стало работать проще, чтобы взаимодействия на всех уровнях были максимально простыми и эффективными, а не «по стандарту» или «по вертикали». Кроме того, и люди и софт должны быть готовы к изменениям процессов вместе с развитием бизнеса (что не отменяет необходимость их формализации).
Мы помогаем заказчикам выявить первоочередные задачи, и сформировать наилучшее решение. В результате мы часто внедряем систему итеративно (agile), так, чтобы решить наиболее насущные задачи в максимально короткий срок. При этом далеко не всегда при внедрении ТЕЗИС классический модуль канцелярии (входящие-исходящие, ОРД и прочее) является наиболее востребованным. Для бизнеса формальный документооборот редко является действительно критичной задачей. Например для Российского Регистра Морского Судоходства мы в первую очередь реализовали процедуры прохождения заявок на освидетельствование судов, освидетельствования в промышленности и флоте и только потом стандартное согласование договоров и канцелярию.
staskin1, правильным ответом будет «и то и то».
И agile, и waterfall — это концепции, реализация которых может сильно отличаться на практике. Если говорить упрощенно, для небольших проектов — например простое внедрение ТЕЗИС — мы используем waterfall модель. Требования понятны, можно легко написать спецификацию и рассчитать конечную цену внедрения. Очевидно, что это максимально комфортный вариант для заказчика. Необходимость изменений в таком случае обычно невелика, и формальный процесс управления ими (change requests) не слишком трудоемок.
Для крупных проектов — в основном это сложное корпоративное ПО, или масштабные внедрения продуктов ТЕЗИС или Sherlock — такой подход уже плохо работает. В большинстве случаев (скажу больше — во всех) на начальном этапе заказчик может сформировать лишь высокоуровневые требования к решению. Понимание деталей приходит по мере развития проекта, когда становятся понятными возможности системы и то, как они используются на практике. В таких проектах мы используем agile методологию. Детальное планирование и анализ требований осуществляются лишь на короткий горизонт ближайшей итерации — спринта (в нашей практике 1-2 месяца). Параллельно с разработкой ведется планирование следующего и т.д. Это дает гибкость в управлении изменениями и позволяет минимизировать ненужную работу. Например, детальное планирование всего проекта, когда мы наверняка знаем, что большая часть требований изменится. Или формальную реализацию функциональности по спецификации (она ведь подписана!), когда уже очевидно несоответствие спецификации реальным потребностям. В итоге мы экономим время и деньги заказчика.
С другой стороны, мы не можем применять «экстремальные» варианты agile процессов, в которых долгосрочное планирование отсутствует в принципе (хотя я думаю они хорошо подходят например для разработки компактных, но массовых продуктов на рынке b2c). И заказчик, и мы должны понимать конечную цель проекта, его архитектуру, основные принципы работы и взаимодействия компонентов. Поэтому обычно мы создаем roadmap, а также функциональную спецификацию на весь проект, покрывающую основные требования без деталей реализации. Это дает нам возможность примерно оценить общие сроки и бюджет проекта (с некоторой вилкой), и таким образом управлять ожиданиями заказчика.
Я имел в виду сравнение с алгоритмами. Код с ветвлениями, условиями, вызовами функций и т.п. Что-то вроде (фантазирую) «проверить остатки, если недостаточно проверить дату следующего поступления или отменить другой заказ, если этот клиент имеет приоритет».
Логику они все же пишут в коде, а не блок схемами.
Мы помогаем заказчикам выявить первоочередные задачи, и сформировать наилучшее решение. В результате мы часто внедряем систему итеративно (agile), так, чтобы решить наиболее насущные задачи в максимально короткий срок. При этом далеко не всегда при внедрении ТЕЗИС классический модуль канцелярии (входящие-исходящие, ОРД и прочее) является наиболее востребованным. Для бизнеса формальный документооборот редко является действительно критичной задачей. Например для Российского Регистра Морского Судоходства мы в первую очередь реализовали процедуры прохождения заявок на освидетельствование судов, освидетельствования в промышленности и флоте и только потом стандартное согласование договоров и канцелярию.
И agile, и waterfall — это концепции, реализация которых может сильно отличаться на практике. Если говорить упрощенно, для небольших проектов — например простое внедрение ТЕЗИС — мы используем waterfall модель. Требования понятны, можно легко написать спецификацию и рассчитать конечную цену внедрения. Очевидно, что это максимально комфортный вариант для заказчика. Необходимость изменений в таком случае обычно невелика, и формальный процесс управления ими (change requests) не слишком трудоемок.
Для крупных проектов — в основном это сложное корпоративное ПО, или масштабные внедрения продуктов ТЕЗИС или Sherlock — такой подход уже плохо работает. В большинстве случаев (скажу больше — во всех) на начальном этапе заказчик может сформировать лишь высокоуровневые требования к решению. Понимание деталей приходит по мере развития проекта, когда становятся понятными возможности системы и то, как они используются на практике. В таких проектах мы используем agile методологию. Детальное планирование и анализ требований осуществляются лишь на короткий горизонт ближайшей итерации — спринта (в нашей практике 1-2 месяца). Параллельно с разработкой ведется планирование следующего и т.д. Это дает гибкость в управлении изменениями и позволяет минимизировать ненужную работу. Например, детальное планирование всего проекта, когда мы наверняка знаем, что большая часть требований изменится. Или формальную реализацию функциональности по спецификации (она ведь подписана!), когда уже очевидно несоответствие спецификации реальным потребностям. В итоге мы экономим время и деньги заказчика.
С другой стороны, мы не можем применять «экстремальные» варианты agile процессов, в которых долгосрочное планирование отсутствует в принципе (хотя я думаю они хорошо подходят например для разработки компактных, но массовых продуктов на рынке b2c). И заказчик, и мы должны понимать конечную цель проекта, его архитектуру, основные принципы работы и взаимодействия компонентов. Поэтому обычно мы создаем roadmap, а также функциональную спецификацию на весь проект, покрывающую основные требования без деталей реализации. Это дает нам возможность примерно оценить общие сроки и бюджет проекта (с некоторой вилкой), и таким образом управлять ожиданиями заказчика.