Разговоры о программировании без программистов идут постоянно. За последние 14 лет моей работы в IT идёт уже вторая волна любви к low-code решениям. Если вы дольше наблюдаете IT-рынок, то наверняка вспомните ещё пару подъёмов этой темы.
Не-программистов, которые создают бизнес-приложения в визуальных редакторах, назвали Citizen Integrator или Citizen Developer. Слоганы продавцов этой темы сводятся к следующему:
...with no-code/low-code platforms, anyone can build applications without software expertise, significantly faster, and at a fraction of the cost.
В этой статье я хочу разобраться насколько правдивы эти обещания, а также где и как стоит применять low-code платформы, чтобы не выстрелить себе в ногу.
Зачем бизнесу low-code платформы?
Текущий всплеск интереса к low-code скорее всего связан в тем, что дорогие программисты стали еще дороже, но и дорогих в свободном доступе на рынке не найдешь. Не-IT-компании не могут нанять вообще никого стоящего, а проекты при этом делать надо. Даже аутсорсеров найти непросто, потому что их кадры тоже размываются из-за желания крупных компаний развивать собственное IT и для этого идет найм сотнями, тысячами и тысячами.
Цифровая трансформация прорвалась даже в те компании, которые до последнего момента пытались обходить ее стороной. В итоге IT-проекты есть, деньги есть, а рук нет. Что делать? Кажется выгодным использовать low-code/no-code платформу, чтобы дешевые и многочисленные не-айтишники могли создавать бизнес-приложения.
На эту тему в Москве недавно прошла конференция «LOW-CODE 2021», где программный директор серии практических конференций издательства «Открытые системы» Дмитрий Волков написал такую вводную:
«Апологеты преподносят low-code как главный инструмент масштабной цифровой трансформации. Критики указывают на лоскутность, низкую производительность, отсутствие должной интеграции, проблемы с обслуживанием доморощенных решений, безопасностью и надежностью. Поэтому, прежде чем применять low-code/no-code, посетите нашу конференцию»
Я побуду в роли критика, но, заодно, опишу способ применения low-code платформы, при котором это применение будет эффективно и оправдано.
Причина провала предыдущих подходов к low-code
Low-code подкупает, когда видишь реализацию простой системы без кода и понимаешь, что ее создали в визуальном редакторе без программиста. А это дешево и быстро. Возникает естественное желание смасштабировать этот подход на все задачи бизнеса.
Приступ любви к low-code заканчивается тем, что low-code подход не может преодолеть проблему увеличения сложности, которая нелинейно растет во время создания IT-решения. В случае с визуальным программированием сложность растет слишком быстро, и система становится неуправляемой.
До определенного момента (до пересечения графиков) такое решение будет обгонять обычный подход по скорости разработки, т.е. вы быстрее выйдете на рынок. Но плюсы визуального программирования быстро заканчиваются и "визуальное" решение стремильно переходит в неуправляемое месиво.
Романтика low-code разбивается о суровую действительность, где IT должно помогать бизнесу создавать большие и сложные IT-системы с постоянно меняющимися требованиями и при этом выдерживать множество внутренних и внешних SLA.
Выглядит так, что для «простых» проектов low-code может подойти, а для «сложных» перестает работать. Давайте определим, что такое простая и сложная IT-система:
Простая система – решение локального уровня для пары сотрудников. Тетя Маша из бухгалтерии хочет, чтобы ей приходила СМС, когда в почту прилетает письмо от шефа. Она идет в Zapier и «программирует» себе пару триггеров и интеграций. Бизнес от этой автоматизации не зависит, логики минимум. Если требования тети Маши поменяются, то изменения можно будет легко внести самой тете Маше. Если триггер сломается, то никто в компании и среди клиентов бизнеса этого не ощутит.
Сложная система – решение на уровне бизнеса, критичное для бизнеса. Например, это тарификация заказов в Ozon, система управления заказами в Leroy Merlin, логистика доставки в маркетплейсе и т.п. От этих систем зависит прибыль бизнеса и репутация бренда. Такие системы часто меняются и изменения нужно вносить быстро и безопасно, т.е. уметь качественно и быстро тестировать. Эти системы подвергаются колебательным нагрузкам, их нужно уметь горизонтально масштабировать.
Простые системы можно и нужно делать на low-code платформах без программистов, а вот со сложными возникают проблемы, которые никак не могут решить создатели low-code платформ:
Рефакторинг и уменьшение технического долга или невозможно, или затруднено. При этом изменения в бизнесе нужно успевать вносить в системы. Бизнесу все равно сделали систему программисты, написав код, или аналитики, накидав квадратиков в визуальном редакторе. Изменения нужно вносить быстро и безопасно. На данный момент ни одна low-code платформа не имеет средств рефакторинга хотя бы приближенных к уровню продвинутых IDE.
Автотестирование невозможно или крайне затруднено. Без автотестов невозможно безопасно вносить изменения. Если нет автотестов, то мы возвращаемся в те доисторические времена, когда для релиза одной фичи нужен полный ручной регресс всей системы. Бизнес, который умеет считать деньги, не будет за это платить.
Высокие нагрузки, кастомные интеграции и безопасности. Эти задачи требуют квалифицированных инженеров и не могут быть полностью решены визуальном программированием, которое ориентируется на решение типовых задач.
Отдельно надо сказать, что если система создана в визуальном редакторе и ее решили перевести в обычный код, то нужно написать всю систему заново. В случае, если система изначально написана кодом, то возможна частичная замена кода или рефакторинг.
Получается, что сложное решение на low-code платформе – это «readonly-код» с очень высокой стоимостью внесения изменений. Это ли надо бизнесу?
РДС (Россия делает сама)
А может проблема в том, что low-code платформы слишком универсальные? Логичным ответом на это будет желание создать свою платформу, под себя.
Я общаюсь с разными компаниями и вижу, что внутри они создают собственные low-code решения. Кроме желания создавать ПО без программистов, есть еще естественная эволюция микросервисной архитектуры в оркестратор бизнес-сервисов.
Но при создании low-code платформы для себя появляется фактор стоимости. Затраты на разработку такой платформы, на мой взгляд, неоправданно высокие. Из чего состоят затраты:
Чтобы создать платформу для программирования без программистов, нужны очень хорошие программисты и проектировщики. То есть изначально нужно 1) привлечь, 2) удержать, чтобы экспертиза не потерялась, и 3) долго оплачивать профессиональную и дорогую команду айтишников.
Платформа не может остановиться на первой версии, поэтому команда будет разрабатывать платформу… всегда и платить этой команде нужно много и долго.
Пользователи этой платформы тоже получают зарплату. Хоть это и не перегретые программисты, но это продвинутые пользователи ПО и платить им нужно соответствующие деньги.
Поддержка пользователей, организация их обучения новым версиям тоже стоит денег и времени.
Чем шире low-code платформа используется в компании, тем больше кейсов она должна покрывать, т.е. она должна становится универсальней и гибче. А чем универсальней решение, тем оно дороже, т.е. такая платформа будет постоянно «дорожать».
При этом у собственной low-code платформы остаются всё те же проблемы с рефакторингом, тестированием, нагрузками и т.д. Эти проблемы остаются, потому что их решение стоит еще дороже, чем стоимость десятка таких low-code платформ.
Как мне кажется, единственный шанс окупить всю эту историю с созданием собственного решения, это продажа внутренней low-code платформы на внешнем рынке, потому что сама себя внутри компании эта платформа вряд ли когда-то окупит.
Когда применение low-code оправдано
Мы уже поняли, что сама по себе low-code платформа не принесет успеха в создании сложной IT-системы. Тем не менее у low-code платформ есть важная характеристика, которую хочется использовать – это визуализация алгоритма. То, что скрыто за строчками кода при обычном программировании, нарисовано в виде схемы в low-code платформе. Это дает возможность аналитиками, владельцам продукта, программистам, проектировщиками общаться на одном языке, глядя на схему процесса.
Работающим подходом является комбинация 1) low-code платформы для визуализации процесса и 2) реализация всех функций этого процесса в виде обычного ПО. Мы применяем для этого BPMN-движки типа Camunda и микросервисную архитектуру. На BPMN описывается процесс, а микросервисы реализуют нужные функции, включая интеграцию, работу с нагрузками, автотесты.
Здесь важно, что BPMN-движок не является самодостаточным, он только организует процесс, оркестрирует. Мы не пишем код внутри Camunda, чтобы потом не упереться в отсутствие рефакторига и автотестов.
В комбинации low-code + обычное ПО тоже есть сложности. Если подойти к процессу без должного опыта и внимания, то можно создать неподдерживаемое месиво из квадратиков и стрелочек. Тут нужны профессионалы, которые отлично знают нотацию BPMN, хорошие аналитики, готовые разложить процесс на части и учесть все исключительные ситуации. Откуда тогда экономия?
Экономия времени и денег получается за счёт декларативного описания процесса:
Его видно, поэтому проще коммуницировать внутри команды и с пользователями.
Его могут создать не-программисты и делают это довольно успешно после прохождения обучения по BPMN-движку.
Всегда актуальная документацию в виде схемы бизнес-процесса. Это как автодокументация, генерируемая по коду, только здесь наоборот код, генерируемый по документации. Они никак не могут разойтись и всегда соответствуют друг другу.
BPMN – довольно популярная нотация, т.е. знатоки есть среди разных профессией. При этом эта нотация всеобъемлющая, ею можно покрыть всё, что вам нужно для работы.
Кроме этого, BPMN-движок из коробки реализует часть рутинных операций, которые программистам писать уже не надо, например, таймеры, переходы между этапами и т.п.
Вывод
Пока я делаю вывод, что серьёзную IT-систему не создать без хороших инженеров исключительно на low-code платформе. Low-code оправдано применять для простых интеграций не критичных для бизнеса.
Тем не менее у low-code платформ есть характеристики, которые стоит взять на вооружение. Если грамотно встроить low-code платформу в разработку ПО, то можно нивелировать минусы и сэкономить за счет плюсов.
Ссылки
Комментарии (70)
zartdinov
15.01.2022 11:15+3Платформа не может остановиться на первой версии, поэтому команда будет разрабатывать платформу… всегда и платить этой команде нужно много и долго.
Нужно просто как c rust'ом чтобы компилятор low-code был написан тоже на low-code.
А если серьезно, мне кажется, low-code неплохо смотрится в data flow, когда нужно собирать данные из огромного количества источников в разных форматах, немного изменять, складывать в DWH и тд.
AlexanderByndyu Автор
15.01.2022 11:23+3Да, хорошо подходит, но до тех пока эти данные не надо трансформировать, валидировать, проверять на полноту и непротиворечивость и т.п., то есть до появления бизнес-логики
Elpi
15.01.2022 11:27-4Манихейство - согласно М., в мире извечно существуют 2 самостоятельных начала: светлое (доброе) и тёмное (злое). Тёмное начало в лице 5 тёмных стихий пошло войной на светлое начало и захватило часть его. См. https://bigenc.ru/religious_studies/text/2183045. Непонятно, что заставило автора излагать материал в такой черно-белой манере:( Очевидно лишь, что те "темные стихии", что "пошли войной" - это, конечно, low-code:)
График просто позорный. Хотя бы для приличия обозначили число "фич", на котором графики пересекаются? Надеюсь, это не "1"? Уже не спрашиваю о соотношении "сложности" и "числа фич".
Цитирую: " Как мне кажется, единственный шанс окупить всю эту историю с созданием собственного решения, это продажа внутренней low-code платформы на внешнем рынке, потому что сама себя внутри компании эта платформа вряд ли когда-то окупит." Сразу напомню старое правило - когда кажется, креститься надо. У нас есть такая платформа и она вполне окупалась и до того, как мы начали ее продавать.
Я отнюдь не фанатик таких платформ. Да и сам автор указывает на то, что на практике в сколько-нибудь серьезных системах результат достигается комбинацией low-code и обычного программирования. Далее, еще Кузьма Прутков сказал: " Каждый человек необходимо приносит пользу, будучи употреблен на своем месте." Не надо обманывать читателей, выдавая low-code как "серебряную пулю" цифровизации. Используйте такой подход в уместных ситуация. Для сильнонагруженных систем 24х7 он подходит плохо. Но такими системами круг задач вовсе не ограничен.
(прикола ради) Хотел бы я посмотреть на "тетю Машу" из бухгалтерии, которая запросто " идет в Zapier и «программирует» себе пару триггеров и интеграций." Обратите внимание на дефиницию "тетя". Конечно, low-code - это удел старых теток. А вот программирование - дело для молодых современных бакалавриаток!
И на что не пойдешь в страстном желании облить конкурента дурнопахнущей субстанцией...(реплика в сторону) Вот такая черно-белая логика сильно мешает нам цивилизованно и относительно равномерно развиваться. Искусство компромисса и последовательный системный подход даются нам тяжело...
AlexanderByndyu Автор
15.01.2022 12:12Жаль, что вы не увидели объективности в статье. У всех подходов есть плюсы, минусы и границы применимости.
Очевидно, что график схематичный, и нужен для того, чтобы показать тенденции. Вы правда верьте в то, что можно указать точную цифру на оси Х?
Интересно было бы узнать как вы посчитали окупаемость внутренней платформы. Что было в затратах? Что в прибыли? Покажите, пожалуйста, цифры. Можно в попугаях, что бы нарушать NDA.
Elpi
15.01.2022 12:48-4Я-то увидел. По сути я сказал, что истина где-то посередине. Но вы продолжаете упорствовать. Кто сказал, что этот странный график вообще нужен? просто убрать его не судьба?
CrushBy
15.01.2022 15:15+2Хотелось бы уточнить, а что Вы считаете low-code платформами ? Вот, например, мы делаем решения для розничного бизнеса на базе low-code платформы, которые достаточно сложные, так как закрывают практически все основные процессы таких компаний. И там нет экспоненциального роста сложности. Вот демо (логин и пароль : guest) для оценки сложности. Что мы делаем не так?
AlexanderByndyu Автор
15.01.2022 17:49Я бегло посмотрел инструмент. Если я правильно понял, вы предоставляете функционал для типовых задач розничного бизнеса. Что-то типа 1С в интерфейсе. Если вашим клиентам хватает кликов в интерфейсе, то все эти клиенты примерно одинаковые и, видимо, не такие большие как может показаться. Например, Леруа Мерлен не взяли бы себе ваш WMS (не в обиду вам, там просто очень много специфики, которую не накидаешь в интерфейсе).
Если вашим клиентам достаточно кликать в интерфейсе и не надо писать код, то у вас отличное low-code решение под вашу нишу. Если брать график, то решения заказчиков не уходят в "красную" зону.
CrushBy
15.01.2022 20:33+1Именно поэтому я и спрашивал, что Вы считаете low-code платформой. Если исходить из определения wikipedia, то это получается та платформа, в которой решение создается при помощи прямоугольничков, стрелочек и так далее (то есть визуально). Лично мне, как человеку с математической подготовкой, такое определение совсем не нравится. Можно без проблем создать визуальный интерфейс, в котором я буду просто писать программу на С++ при помощи мышки (стрелочек и т.д.). Станет ли от этого Visual Studio low-code платформой - вопрос риторический.
Я к тому, что главное - не визуальность, а уровень абстрагирования платформы. Если мы возьмем концепцию MVC, то понятно, что основная логика кроется в M и C, а не V. И каким образом идет задание логики : при помощи мышки, или в виде кода - не столь принципиально. Например, в той же системе отчетности JasperReports есть два представления отчета : визуальный и в виде XML. С точки зрения интерфейса вы правите отчет в одном месте - автоматически правится в другом. Причем коммитится, естественно, XML-файл.
Если я правильно понял, вы предоставляете функционал для типовых задач розничного бизнеса
Нет, платформа универсальна, и подходит практически для любых B2B решений.
Если вашим клиентам хватает кликов в интерфейсе
Тут есть определенное недопонимание. Вся система задается в виде встроенного высокоуровневого декларативного DSL. Сейчас нет визуального конструктора для него, но создать его не проблема. Другое дело, что я не уверен, что им будет удобно пользоваться. Саму логику программы делают не конечные пользователи, а скорее бизнес-аналитики. Являются ли они разработчиками - вопрос сложный, и мы его постарались описать в этой статье.
все эти клиенты примерно одинаковые и, видимо, не такие большие как может показаться
Они все-таки достаточно сильно отличаются друг от друга (и там не только розница). Насчет величины : около десятка клиентов имеют более 5000 сотрудников. Количество работающих пользователей в системе - от 800 до 1500. Базы данных до 4ТБ. Да, это не Газпром конечно, но и не такие маленькие компании. И главное, что они работают ровно в одной системе с одной базой данных (а не с множеством систем, как во многих крупных компаниях).
AlexanderByndyu Автор
16.01.2022 07:13главное - не визуальность, а уровень абстрагирования платформы
Да, как раз так и думаю. Спасибо за уточнение.
vasyakolobok77
15.01.2022 18:22+3Расскажите как проходит разработка на такой платформе:
-- где хранится код логики / модели данных?
-- как происходит выкладка на стейджи / прод?
-- нет ли конфликтов логики / моделей при параллельной разработке фичей?
-- насколько просто рефакторить код?
-- нет ли сложности с входом в разработку, потому как новый DSL это всегда порог вхождения?CrushBy
15.01.2022 20:47+2где хранится код логики / модели данных?
В виде плоских файлов (модулей) в системе контроля версий. В каждом файле может быть как модели данных, так и действия, ограничения и задание интерфейса. Вот пример репозитория. Там все lsf-файлы - это такие модули.
как происходит выкладка на стейджи / прод?
Обычно настраиваем jenkins, который все это собирает. Важно понимать, что конечное приложение - это просто java-программа, к которой подброшены lsf-файлы, написанные на DSL(которые просто должны быть в classpath). Соответственно, обращаться со всем этим делом можно также, как с любым Java приложением. Например, мы активно используем Maven для разбития на разные подпроекты.
нет ли конфликтов логики / моделей при параллельной разработке фичей?
Все резолвится системой контроля версий. В итоге получаются плоские файлы, а при запуске сервера платформа сравнивает предыдущую модель (которая хранится в самой базе) с новой моделью (которая в lsf-файлах) и проводит изменение структуры под новую логику.
насколько просто рефакторить код?
В качестве IDE используеются IntelliJ IDEA со своим плагином под DSL. Соответственно, поддерживается "Find usages", "Go to definition", "Rename" и т.д. Собственно у нас разные люди без проблем разбираются и правят "чужую" логику.
нет ли сложности с входом в разработку, потому как новый DSL это всегда порог вхождения?
Сейчас 90% процентов наших "разработчиков" на DSL никогда до этого не программировали ни на чем (оставшиеся до этого писали на 1С). Те, кто писал на 1С - вообще просто переключились без проблем. Остальных, конечно пришлось поучить основам контроля версий и IDE, но в целом уже через пару недель люди делали реальные задачи (плюс все-таки в платформе много встроенных защит от того, чтобы сильно накосячить).
vasyakolobok77
16.01.2022 00:33Спасибо, стало понятней. Посмотрел ваш репо. Мне кажется это не совсем Low-code платформа. Скорее просто свой DSL.
В моем опыте Low-код платформы – это standalone монстры полные gui-редакторов, через которые "мышкой" конфигурируются основные компоненты для реализации прикладных задач. Подобные системы полны недостатков, о чем ТС упоминает в статье, и я с ним солидарен. Ваш же случай как мне кажется не подходит под это описание.
AlexanderByndyu Автор
16.01.2022 07:15это standalone монстры полные gui-редакторов, через которые "мышкой" конфигурируются основные компоненты для реализации прикладных задач
Да, да, так я их и видел. Спасибо за комментарий.
Borz
16.01.2022 10:14вы путаете no-code с low-code платформами
vasyakolobok77
16.01.2022 11:39Это суть одно и то же. Если судить по https://www.gartner.com/reviews/market/enterprise-low-code-application-platform то это как раз то, о чем говорит ТС (и я в своем комментарии).
Но путаница есть, например, @CrushBy привел в пример скорее мета-фреймворк со своим DSL и механиками, которые упрощают построение приложение. Такие вещи имеют место быть. Но это не те low-code/no-code системы.
CrushBy
16.01.2022 12:18Да, меня тоже впечатляет, что для таких платформ (в частности со своим DSL) нет общепринятого названия. У меня язык не поворачивается назвать тот же 1С - просто фреймворком. Вот Spring - это Java-фреймворк, а 1С - именно платформа. И, на мой взгляд, лучше всего подходит как раз название "low-code платформы".
vasyakolobok77
16.01.2022 13:14-1Если речь об 1С:Предприятие, то это полноценная ERP-система. У нее свои конкретные задачи.
Если брать Elma, Pega, Ibm Bpm - это вот те самые low-code монстры, которые я имею ввиду. Это standalone платформы, через gui которых конфигурируются прикладные задачи.
Решение, о котором вы CrushBy говорили, не попадают под категорию платформ, поскольку это не standalone система. Это скорее мета-фреймворк (над-фреймворк), который с помощью DSL и плагинов для IDE помогает разрабатывать приложения в классическом стиле.
CrushBy
16.01.2022 13:19+2Нет, я именно говорю о голой 1С-платформе, на которой делают решения (в 1С-воском простонародье такие решения называются "нетленки"). Называть ERP-системой платформу 1С без конкретной конфигурации (то есть без бизнес-логики вообще) совершенно точно некорректно.
vasyakolobok77
16.01.2022 13:55Допустим. Но отличие вашего мета-фреймворка от этих standalone решений вы подтверждаете? Или для вас это одно и то же?
CrushBy
16.01.2022 14:05Отличие конечно же есть. И поэтому писал, что с терминологией сейчас есть проблемы.
В частности я вообще не вижу смысла в визуальном программировании. Все упрется как минимум, в систему контроля версий и merge конфликтов. Как это сделать визуально, а не в plain-code для меня большая загадка.
Но в целом нормальная высокоуровневая система, как эти standalone решения, должна иметь многослойную архитектуру (как, например, стек TCP/IP). Это нужно, чтобы когда на верхнем слое что-то не удается сделать, то можно было бы спустится на уровень ниже, а не падать сразу на написание голового java-кода по сути с нуля.
marshinov
16.01.2022 08:50+1В комментариях к оригинальной статье уже написали "что вы делаете не так". Вы пишите на странном велосипеде, который никто кроме вас поддерживать не сможет. Не ясна рыночная ниша этого продукта. Но вам нравится и никто не сможем вам запретить. Я бы ни за что для себя такую систему не поставил, потому что нет в мире достаточного количества программистов на этой "платформе". Если говорить про dsl на jvm-стеке, то в Kotlin прекрасный dsl. Почему не использовать его?
CrushBy
16.01.2022 09:00+2В комментариях к оригинальной статье уже написали "что вы делаете не так"
Когда я спрашивал, про что "мы делаем не так", то я писал, что мы успешно делаем сложные решения на low-code платформе.
Вы пишите на странном велосипеде, который никто кроме вас поддерживать не сможет.
Ряд наших клиентов развили у себя внутреннюю экспертизу по платформе и прекрасно самостоятельно на ней разрабатывают. Плюс многие сторонние люди уже ее используют для решения разных задач.
Не ясна рыночная ниша этого продукта
Та же, что и у платформ 1С, Microsoft Access и прочих.
Если говорить про dsl на jvm-стеке, то в Kotlin прекрасный dsl
Как я уже писал выше - главное не язык, а уровень абстрагирования. У Kotlin'а уровень абстрагирования не сильно выше, чем у Java. А у lsFusion выше даже чем у 1С.
marshinov
16.01.2022 10:24У Kotlin'а уровень абстрагирования не сильно выше, чем у Java
Либо вы плохо знакомы с Kotlin, либо у нас разное понимание абстрагирования. В Java вы вот такое не напишите. Рекомендую еще посмотреть на сигнатуры функций из примера на главной страницы Ktor. Опять таки уровень абстракции сильно выше, чем в Java. Ну и вишенка на торте - корутины.
Если все-таки когда-нибудь доделают expression trees, то будет комбинация полностью покрывающая заявленные вами преимущества: декларативность - dsl. Возможность очень сильно перколбасить байткод (и не только для асинхронного взаимодействия) - корутины. Эффективная трансляция в SQL - деревья выражений. Только вот такой DSL будет на 100% нативным для JVM и при желании его допишем любой программист, знакомый с Kotlin, а не с вашим особым языком. Все подсветки синтаксиса, автокомплишны и т.д. тоже будут работать автоматом. Пока expression trees нет, есть Spring Data или JOOQ, которые такие же декларативные, как ваш "особый уникальный невероятный (без регистрации и смс) язык".
Аналогичные DSL без изобретения языка можно довольно быстро организовать на .NET-стеке с помощью уже упомянутых деревьев выражений и LINQ или вообще F#'а. Нет принципиально никакой разницы - учить ограниченное подмножество существующего языка или ваш язык. Ваша дискуссия с@lairв оригинальном треде - тому пример. Просто, видимо, у вас сильная эмоциональная связь с вашим детищем, которая не позволяет объективно его оценивать.
CrushBy
16.01.2022 12:16+2Еще раз, мы говорим о совершенно разных задачах и предметной области. Я не отрицаю, что Kotlin - хорошая технология для своих задач.
Пока expression trees нет
Странная логика. Сравнивать технологию, которая уже работает годами с тем, чего нет, и неизвестно будет ли когда-либо.
Аналогичные DSL без изобретения языка
Извините, но я не очень понимаю, что значит "DSL без изобретения языка". DSL - это и есть новый язык. Кстати, а что насчет SQL ? Это классический DSL, разработанный под конкретные цели. Или может вместо него надо было использовать Cишный синтаксис ? Напомню, что он создавался для тех же людей, что и low-code платформы.
Просто, видимо, у вас сильная эмоциональная связь с вашим детищем, которая не позволяет объективно его оценивать.
К сожалению, Вы оцениваете все только с точки зрения технического специалиста. Если все-таки рассматривать бизнес-составляющую (скорость, цена, качество), то все становится гораздо интереснее. Именно благодаря скорости/цене/качеству за 5 лет на решения на базе lsFusion перешли 70% рынка крупного ритейла в Беларуси. И клиентам все равно, какие модные или немодные технологии используются. Им важно то, чтобы можно было очень быстро реализовывать в системе их пожелания.
marshinov
16.01.2022 13:11+1Я вам о том что ваш dsl можно было сделать без изобретения своего ЯП. Вы мне о том, что ваш продукт дешевле SAP и 1С. Ну дешевле. Вы молодцы. Dsl без изобретения языка - это когда вы берёте подмножество существующего яп и даёте прикладниками его. Без потери выразительности можно было использовать и linq-синтаксис C#, перегрузив SelectMany и Select и компутейшны из F# и kotlin dsl, но вы написали своё. Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье, но вы продолжаете настаивать, что ваш язык лучше. На мой вкус он ничем не примечательный и никаких революций вы не произвели. Tool support вашего dsl хуже, чем у mainstream-языков. Вы утверждаете, что "он понятнее для не программистов", но это бездоказательно. Объясните, почему нельзя добиться тех же результатов используя вашу платформу и один из языков на выбор в качестве dsl: Kotlin, C#, F#, TS, Python, Ruby. Я могу изобразить аналогичный вашему код на каждом из этих языков. А копипастить по примеру и обезьяну можно научить.
CrushBy
16.01.2022 13:29Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье
Это по той простой причине, что большинство комментаторов не всегда пытаются разобраться в сути проблемы, а оценивают поверхностно. Точно также, как и Вы.
Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье, но вы продолжаете настаивать, что ваш язык лучше
Сейчас речь идет не о языке, а о высокоуровневой архитектуре для построения приложений. Язык вторичен. Чтобы объяснить разницу, важно понимать, что при написании на lsFusion 80% - это декларативный код, а 20% - императивный. Во всех остальных системах - наоборот.
К сожалению, вот так абстрактно объяснить это достаточно тяжело, но чтобы просто понять, ответьте - зачем придумали SQL ? Знаете, кто был его целевой аудиторией (и сейчас не только программисты его используют). Почему не взяли стандартный Cи-подобный синтаксис ? Мой ответ : потому, что он гораздо лучше подходит для конкретной задачи/архитектуры (формирования запросов для реляционной логики). А ваш какой ?
И зачем вообще по-вашему существуют DSL ? Зачем существуют средства для разработки DSL в той же IDEA, если новые языки не нужны ?
marshinov
16.01.2022 17:03Язык вторичен
Итого, можно было не писать парсер под новый язык, а использовать подмножество другого JVM-языка и сэкономить ресурсы, что я и пытался донести.
Это по той простой причине, что большинство комментаторов не всегда пытаются разобраться в сути проблемы, а оценивают поверхностно. Точно также, как и Вы.
Вот прям нет пророка в своем отечестве.
Язык вторичен. Чтобы объяснить разницу, важно понимать, что при написании на lsFusion 80% - это декларативный код, а 20% - императивный. Во всех остальных системах - наоборот.
Во "все остальные системы" вы включили системы написанные на хаскеле, linq, spring data и jooq?
К сожалению, вот так абстрактно объяснить это достаточно тяжело, но чтобы просто понять...
Уже объяснили. Это называется "паттерн "интерпретатор" в ООП и "свободная монада" или "Tagless Final" в ФП.
Зачем существуют средства для разработки DSL в той же IDEA, если новые языки не нужны ?
Для более короткого/простого/эффективного решения узкого, но распространенного класса задач. Я не говорю, что новые языки не нужны. Я говорю, что конкретно придуманный вами язык (не платформа) не нужен. Хороша ли платформа или нет я не знаю, раз она помогает вам зарабатывать деньги, для вас она хороша.
CrushBy
16.01.2022 17:56Итого, можно было не писать парсер под новый язык, а использовать подмножество другого JVM-языка и сэкономить ресурсы, что я и пытался донести.
Во-первых, парсер пишется же не с нуля, туда просто загружается грамматика. Там не было особо эконимии ресурсов. Но тут есть еще один нюанс.
Наш язык никак не ориентирован на Java/Kotlin и т.д. разработчиков. Я себе слабо представляю ситуацию, когда Java разработчик будет писать на lsFusion. Точно также, как я слабо представляю, как Java разработчик вдруг станет 1С-программистом (в обратную сторону, кстати, частый кейс.
И это не потому, что платформа 1С или lsFusion - плохая. А потому, что разработка на 1С и lsFusion тесно связана с бизнес-анализом (общением с пользователями напрямую, быстрой разработкой без какого-либо ТЗ и по сути самостоятельным внедрением), и программирование там идет на гораздо более высоком уровне. С другой стороны у таких платформ ниже порог вхождения. Любой Java-разработчик при желании сможет писать на 1С или lsFusion. В обратную сторону - это далеко не так.
Итак, если мы никак не ориентируемся на Java-разработчиков (или Python/Kotlin), то зачем нам было брать Cишный синтаксис ? Ведь все равно им будут пользоваться люди, которые не знают ни того, ни другого. Не лучше ли тогда сделать свой наиболее удобный DSL под конкретную архитектуру ?
leha_gorbunov
16.01.2022 19:56Десктопный клиент в гигабайтах, отдельное IDE, свой DSL это, чтобы порог вхождения был повыше и перспектив поменьше.
Подобная система система ценна именно написанным и работающим бизнес кодом, который легко кастомизируется программистом с улицы.
А сам движок сваять ни разу не сложно, если мозги есть, то и в "одно рыло" можно сделать. Сам когда-то делал ради интереса такой pet-проект (javascript/php/mysql) и забросил, сейчас где-то в интернете валяется с открытым кодом на гите. Видео можно на двойной скорости смотреть, там 7 минут https://www.youtube.com/watch?v=e10i7o0gVpI как работало, сейчас jquery не модно и хрен с ним.
CrushBy
17.01.2022 09:53Десктопный клиент в гигабайтах
Это у кого ? Десктопный клиент весит 18МБ (заархивированный через Pack200). Но большинство у нас используют веб-клиент. Там и функциональность больше и устанавливать ничего не нужно.
отдельное IDE
А есть платформы без IDE ? В качестве IDE используется IDEA, которая можно сказать лучшая IDE в мире.
свой DSL это, чтобы порог вхождения был повыше и перспектив поменьше
Свой DSL наооборот делает порог вхождения ниже (не все люди могут стать Java-программистами).
Подобная система система ценна именно написанным и работающим бизнес кодом, который легко кастомизируется программистом с улицы.
Скажите это 1С, на котором написано огромное количество "нетленок" (то есть с нуля, без какого-либо бизнес-кода.
А сам движок сваять ни разу не сложно, если мозги есть, то и в "одно рыло" можно сделать.
Прототип движка сделать то несложно. А вот сделать промышленную платформу, с документацией и примерами, с хотя бы несколькими десятками внедрений на 1000+ одновременных пользователей и террабайтными базами данных, с понятными процессами внедрения, поддержки, доработки и интеграциями - это гораздо сложнее.
conopus
15.01.2022 17:34+1Довод о невозможности быстрого тестирования этих приложений выглядит слабым. Юнит тесты там конечно не попишешь, но это ведь обязанность владельцев low-code платформы. А писать интеграционные или GUI тесты ничего не мешает. Разве что отсутствие разработчиков автотестов среди Citizen Developer и желание сохранить минимальный бюджет. Да и то, есть же low-code решения и для написания тестов. Тот же Selenium IDE, например. Если они вдруг поймут, что им нужны тесты и захотят их писать, то подходящие им инструменты уже есть.
Я думаю, что, наравне с аналитиками, мануальные тестировщики хороший источник кадров для разработки low-code. Они глубко погружены в бизнес-процессы, умеют думать за пользователя и не слишком привязаны к инструментарию, который надо осваивать годами (как у бэк- или фронт-эндеров). Кстати, похожая ситуация и у разработчики UI автотестов, которые без особых усилий могут перейти в разработку RPA (еще одна технология из категории "сделаем это по-быстрому"). Другое дело что зарплаты в российском RPA выглядят не очень привлекательными, даже для тех, кто ничего, кроме Selenium тестов не освоил. Но, это уже другой вопрос.
AlexanderByndyu Автор
15.01.2022 17:42+1Теоритически можно организовать полноценное автотестирование. Даже если не брать модульные тесты, то е2е написать можно. Но тут, как вы заметили, нужны профи, ни о каком визуальном тестировании речи не идет.
Это напоминает мне историю, когда в американской компании было 1К индусов в Индии и 20 человек в Израиле. Задача этих 20 несчастных была в том, чтобы рефакторить поток г*внокода индусов. Я согласен, можно попробовать так организовать.
conopus
15.01.2022 18:01+1Ну, почему теоретически. У меня вполне реальный опыт обучения "с нуля" SAP-консультанта написанию автотестов на Python и Robot Framework. К концу первой недели он начал писать тесты сам. До этого у него весь опыт программирования был ограничен школьными уроками информатики.
Натыкать тесты в Selenium IDE сможет и Citizen Developer. А учитывая что жизненный цикл у low-cod решений приблизительно как у бабочки поденки, им даже PageObject не потребуется.
AlexanderByndyu Автор
16.01.2022 07:17Я понимаю, что вы говорите. Да, можно обучить не-QA делать работу QA и этот человек будет писать какие-то тесты. Но что нам нужно от автотестирования в конечном счете? Я подразумеваю, что перед выкладкой на прод запускается набор тестов, который говорит, что ВСЯ система работает как надо. Тогда не нужен ручной регресс. Сделает ли непрофессиональный тестировщик такую работу?
conopus
16.01.2022 12:17Хороший учебник начинается с определения границ применимости тех знаний, которые в нем даются. Известный учебник Куликова по тестированию ПО во первых главах содержит объяснение почему исчерпывающее тестирование невозможно. Собственно вся теория тестирования состоит в поиске компромиссов между ограниченными ресурсами и тестовым покрытием. Сам выбор в пользу low-code происходит из-за жёсткого ограничения ресурсов на разработку, что уж говорить про тестирование? Я думаю, что надеятся на полноценное покрытие в таких проектах не стоит по определению.
AlexanderByndyu Автор
16.01.2022 13:33На 100% и всеобъемлющее надеяться не стоит, но надо же быть уверенным до релиза, что система работает. Какой вы видите способ? Надеяться, что кто-то из аналитиков написал достаточно тестов после вашего недельного обучения? Как при этом делается релиз?
conopus
16.01.2022 18:48+1Повторюсь: лечить подобное подобным. Ждать что аналитики или Citizen Developers освоят общепринятые средства автотестирования не стоит. Им нужны аналогичные low-code иструменты: для E2E тестов Web UI - рекордеры вроде Selenium IDE, для REST API - VCR (https://habr.com/ru/post/246409/)и т. д. Когда им надоест руками менять локаторы во всех тестах, изобретут PageObject Model. А не изобретут - значит и не надо было.
И мне кажется вы недооцениваете аналитиков. Они точно будут знать продукт лучше тестировщика, который только пришел на проект. И натыкать тестов на happy path смогут не хуже мануального тестировщика. Конечно ждать от них знания техник тест-дизайна или готовности писать негативные или нагрузочные тесты - вряд ли стоит. Но, это как в химии: чистота вещества стоит очень недешево: каждая девятка после запятой стоит в десять раз дороже. Я думаю, если хочется посолить помидор, то лучше иметь в солонке молотую каменную соль, а чем ждать, когда купят NaCl категории ЧДА.
Ну, а дальше снова по учебнику: начинаем с позитивных тестов по базовым функциям -- sanity tests. Для определения дальнейших приоритетов есть здравый смысл и мнение стейк холдера. )
И мое субьективное мнение: я получил изрядныйы опыт "IT за медные деньги". И конденсаторы на материнских платах перепаивал, чтобы сделать софтовый маршрутизатор для компании и писал для себя RPA-скрипты, когда и слова такого не было. Low-code мне видется одной из версий "IT за медные деньги". Участвовать в таком больше не хочется, поэтому основной посыл вашей статьи мне близок.
Но, я также знаю, что оптимальные ниши, и для low-code/no-code, и для RPA - есть. В том числе и в крупных компаниях. Если не выходить за границы этих ниш в пространстве и во времени, то можно увидеть не только недостатки, но и достоинства этих подходов. Например, что сила Citizen Developers в том, что они могут быть ближе к пользователю, чем любой аналитик. Иногда это бывает важнее стройной архитектуры (чью ценность я ни в коей мере не умаляю).
marshinov
16.01.2022 09:00А потом все эти "тесты" сломаются и их выкинут как нечитаемой и неподдерживаемое гуано.
conopus
16.01.2022 12:22+1Это сплошь и рядом и на обычных проектах происходит. Low-code проекты имеют важное преимущество -- они не могут быть большими. Поэтому и натыкать заново или поменять локаторы методом find n replace в них гораздо легче.
AlexanderByndyu Автор
16.01.2022 13:35+1они не могут быть большими
Как раз проблема в том, что они могут быть большими. Вы удивитесь сколько людей и компаний верит в то, что критически важные для бизнеса вещи, можно сделать в визуальном редакторе. Собственно, поэтому я эту статью и написал :)
conopus
16.01.2022 15:59+1Хорошо, соглашусь что могут. Но, ограниченно по времени. Я согласен с вашим графиком, и на нем есть участок, где системы могут находится в таком состоянии предельной сложности. Но, если добавить на график кривую стоимости владения такой системой, то будет очевидно, что в таком состоянии она долго пребывать не сможет. Очевидно, что стоимость будет расти, во-первых нелинейно, во-вторых быстрее чем у "традиционных".
Автотестирование, конечно может служить средством борьбы со сложность и объемом тестируемой системы, но на ограниченном этапе и в свою очередь может порождать проблемы. И тоже очевидно, что пределы роста для low-code автотестирование ниже, чем у "традиционных". Те есть, основанных на языках программирования общего назначения и специализированных фреймворках и библиотеках.
nApoBo3
15.01.2022 22:59Если бы бабушка была дедушкой... Выкиньте из разработки тестирование и можно первичную стоимость миниму на четверть урезать, но какой ценой. Low-code оно по цене выглядит привлекательным, как мне кажется, во многом по тому, что вокруг него нет всего того, что позволяет разработке сохранять адекватную стоимость внесения изменений и эксплуатации.
AlexanderByndyu Автор
16.01.2022 07:19вокруг него нет всего того, что позволяет разработке сохранять адекватную стоимость внесения изменений и эксплуатации
Плюсую! В low-code первая версия выглядит обнадеживающе, а потом резкий рост сложности убивает проект. Когда-то писал об этом статью https://blog.byndyu.ru/2013/12/it.html
KillWolfVlad
16.01.2022 10:24+1а потом резкий рост сложности убивает проект
Согласен. Мы пишем Backend-for-Frontend (BFF) на low-code платформе нашего заказчика, которую он сам и разрабатывает. Когда мы просто проксировали запросы в наши сервисы as is, то с этим как-то можно было жить, но потом начался маппинг, обогащение сущностей из внешних систем, аутентификация и авторизация, дублирование кода из-за сложностей с его переиспользованием и наверное сейчас BFF проще переписать с нуля на Nest.js (потому-что у нас все сервисы написаны на Nest.js) чем поддерживать.
NoWeekOff
15.01.2022 18:00+1Поскольку вывод начинается со слова "пока", ожидается развитие этой темы. Есть два предложения:
1. Сравнение с подходом DSL. Это серьезный конкурент low-code
2. Рассмотрение систем в динамике.
Одно дело взглянуть на статичную картину, вырезать из нее кусок под LC решение и выкинуть туда возможности по конфигурированию. Но как управлять этим в будущем? Из примера с бухгалтером и смс - что произойдет с кодом кода появится не один телефон, а два? или директор будет иметь два почтовых ящика? А как обрабатывать исключения? и т.д.
Поддержка LC решения в актуальном виде может стоить дороже чем реализация программистами тех хотелок, которые он позволяет сделать пользователю.
Ну и как было у классика: "Две вещи бесконечны: Вселенная и человеческая глупость. Но на счет вселенной я не уверен". Насколько простым и понятным должно быть LC решение, чтобы его спокойно мог использовать не искушенный пользователь?
Серьезный скепсис способна разрушить практика. Хочется увидеть примеры где это реально заработало, причем не с точки зрения реализации, а с точки зрения реального использования таких фич рядовыми пользователями
conopus
15.01.2022 20:09+2Интересный факт: долгое время самым популярным языком программирования был макро-язык Lotus 1-2-3. То есть ничего нового под луной нет и low-code подход это то самое, что сделало популярными персональные компьютеры. Могу привести пример времён Windows XP. Работал я тогда сисадмином на металлообрабатывающем заводике. Ну и дали мне там задание сделать систему учёта заказов. Я и сделал ее на Microsoft Access. Там всего кода было - одна строка в которой генерировались номера заказов. Проработало все это около года, а потом к нам пришел новый главбух, который выбил бюджет на допиливание 1С и оно послужило тех. заданием для 1С-ников, которые перетащили все это к себе и добавили списание материалов. Такого добра в мелком и среднем бизнесе полным полно. И когда оно работает, как MVP - этот подход вполне оправдан. Тут я с автором вполне согласен. Не надо только из этой трепетной лани пытаться вырастить битюга.
AlexanderByndyu Автор
16.01.2022 07:25Спасибо за комментарии. У вас чувствуется опыт за плечами.
Если говорить о том, во что я верю, то я скорее отдаю предпочтение набору готовы микросервисов с понятным входом и выходом. Я был бы готов платить за такие мини-инструменты и комбинировать их в своих системах. Что-то типа https://dadata.ru/ или https://kontur.ru/focus/api/how-to-work. Если бы таких сервисов с API было достаточно много, то и время разработки можно было сократить, переложив часть работы на внешние сервисы.
Правда при этом мы получаем новые точки отказа, но тут уже всё зависит от того, как мы построили свою систему, как мы реализовали fault tolerance и где мы подумали об SLA в нашей системе и какое SLA обещают внешние сервисы. В целом, я думаю, что это может сработать.
conopus
16.01.2022 18:56А https://albato.ru/ под ваше пожелание не подходит? Сам я с ним правда не работал, но на первый взгляд похоже на то, что вы хотите.
nApoBo3
15.01.2022 22:53+3Я бы не стал относить bpmn движки к low code. Чтобы их нормально, полноценно использовать у вас должно быть куча кода вокруг, а умение писать исполняемые бизнесс процессы это отдельная магия которой очень не много кто владеет и это точно не "продвинутый пользователь" и его зарплата точно не ниже зарплаты программиста. Описанный "аналитиком" или менеджером в нотации bpml процесс, чаще всего использовать можно только после полной переработки разработчиком уровня не ниже сеньер.
Да, процессы в camunda замечательно покрываются тестами если у вас есть java разработчик/тестер.
AlexanderByndyu Автор
16.01.2022 07:28+1Да, я согласен, что Camunda где-то на грани. Теоритически в ней можно обойтись и без кода, но часто приходится добавлять обработчики. Тут я привел пример с Camunda, чтобы обесопасить тех, кто возьмет ее в работу, от того, чтобы писать код внутри этой платформы. Иначе этот скрытый код будет очень сложно обрабатывать.
nApoBo3
16.01.2022 15:45+2Все еще банальнее.
Камнуда фактически не представляет средств работы с данными, верификация, целостность.
GUI интерфейсы камунды хоть и возможны, но максиму на что тянут, это прототип.
Если все элементы процесса без поднятия уровня абстракции пихать в BPMN схему она станет абсолютно не читаемой и не поддерживаемой, многие люди просто в реальности не представляют сколько в их процессах действий поскольку интуитивно их укрупняют. А такой процесс не может быть выполнен, ему нужны все действия. Простейший способ — это понять, попробовать написать инструкцию для любого самого простого действия, а потом попробовать по этой инструкции, строго по ней, выполнить запрашиваемое действие. В итоге многие детали реализации процесса прячутся в коде( тут важно соблюсти баланс ) и требуют разработчика достаточно высокой квалификации, поскольку это распределенная система, да и особенности работы камунды ему нужно знать, а значит знать java. Вот и получается, вроде low code, а разработчиков помноженных на квалификацию нужно не меньше, а возможно и больше, и уж точно с ней не может работать сотрудник не имеющий должной квалификации в ИТ.
eutist
15.01.2022 23:16+3Есть поучительный пример индустрии, в которой lowcode одержал убедительную победу — это industrial automation. Сейчас абсолютное большинство систем автоматизации производственных процессов выполняются на тех или иных lowcode-системах, а не-lowcode решения часто получают презрительную кличку «самопал» и допускаются только в самых простых проектах. Почему так произошло — тема для отдельного разговора; вкратце же можно назвать такие причины:
- общие подходы и требования, которые выработала индустрия, оказались хорошо реализуемыми «в целом», без необходимости чрезмерной кастомизации под каждого клиента;
- задачи industrial automation получилось разбить на сравнительно небольшое количество ограниченных контекстов с эталонной реализацией;
- наличие жестких требований к соблюдению стандартов, лицензированию и сертификации ПО и аппаратного обеспечения;
- фактический vendor lock клиентов на готовые программно-аппаратные комплексы основных производителей;
- исторически более низкая квалификация и более низкая оплата труда разработчиков промышленного ПО в сравнении с обычными разработчиками;
- как следствие предыдущего — практически полный отказ от software tailoring в пользу максимальной поддерживаемости, сопровождаемости и прочего maintainability.
Всё это и привело там к тотальному доминированию lowcode, который в таких условиях показал себя настолько хорошо, что удивляешься не тому, что его в промышленной автоматизации так много, а тому, что в остальных отраслях его так мало.
Amor-roma
16.01.2022 02:36+6Как сертифицированый специалист по програмиированию контроллеров Omron, перебежчик в .Net, вкусивший Booble.io отвечу))
В промконтроллерах не нужны высокий уровень абстракций, валидация всех данных, структура данных в худшем случае массив данных для конфигурации совмещённых устройств IO. По своему опыту скажу что изменение в коде может потребоваться если отдел закупок не смог купить такую же ревизию устройства которое пошло под замену, и новое устройство имеет отличающийся метод управления/конфигурации от предыдущей версии устройства.
В тоже время требуется понятность/наглядность/отладка , программы написанные и принятые к эксплуатации работают весь жизненный цикл оборудования.
Вот вам и ответ!
Что называется найди все отличия))
Мои рекомендации для будущих low-code программистов/студий, это удобное и быстрое средство для проверки бизнес идеи. Если все устраивает и не предполагается существенных изменений в бизнесе процессах на проекте и нагрузка не кладёт ваше решение, то это ваша серебряная пуля))!
AlexanderByndyu Автор
16.01.2022 07:32
xxxDef
16.01.2022 07:10+1Да Стандарт IEC-1131, где парами определены языки программирования как в текстовом виде так и в графическом. FB + FBD, IL+LD, SFC. Это целый мир, со своими нюансами, проблемами и подходами, про который обычные программисты даже и не догадываются, создавая на коленке какие то свои локальные решения.
iShrimp
16.01.2022 10:27+2Огромные, монструозные low-code платформы используются в медицине. Там десятки уровней доступа и сотни ролей сотрудников, тысячи форм разных документов и отчётов, и всё это настраивается в визуальном интерфейсе со сложной иерархической системой настроек. Вообще, в медицине процент людей, знающих хотя бы один язык программирования, близок к нулю, и это в основном вызвано зарплатами и специфичным отношением к программистам в госучреждениях. Поэтому система сделана так, что администрировать её может любой выпускник колледжа после 2 недель обучения. Доступа к самой логике и базам данных у сотрудников ЛПУ, как правило, нет.
AlexanderByndyu Автор
16.01.2022 13:38А в этих системах есть какая-то бизнес-логика отличная от стандартной? Может там цена ошибки так высока, что ты можешь брать только мега-отточенные и проверенные кубики, а не делать свое на коленке?
iShrimp
16.01.2022 19:25В основном логика "спускается сверху" и пишется сотрудниками РМИАЦ, так как она должна соответствовать требованиям законодательства и приказам ТФОМС. Сисадмины на местах могут подключать модули (есть готовые шаблоны для АРМ поликлиники, стационара и т.д.), настраивать порядок работы в соответствии со спецификой своего ЛПУ, раздавать права. Система в чём-то напоминает 1С, даже имеет свой скриптовый язык. Но на практике никто не лезет в дебри настроек, т.к. через пару месяцев придёт обновление и придётся возиться уже с ним.
ты можешь брать только мега-отточенные и проверенные кубики
Не такие уж они отточенные и удобные. Особенно с точки зрения пользователя - простое действие может требовать кучу кликов и полминуты ожидания. Но функцию защиты информации система выполняет хорошо. Большая часть багов - непонятно откуда возникший Access denied.
JCDenton
17.01.2022 13:54+1По-моему low-code решения - это фактически попытка создать сабсет языка программирования общего назначения с абстракциями, соответствующими какой-то предметной области. И тут возникает 2 проблемы, которые почти невозможно решить:
1. Существует очень мало компаний, которые могут описать абстракции, которыми они оперируют в своей деятельности, с таким уровнем формализма, что их можно описать на языке программирования общего назначения и предоставить в пользование не-программистам. Из-за этого всегда будут возникать уточнения абстракций, которые повлекут за собой дообучение пользователей low-code системы. А они не хотят постоянно дообучаться - им надо выполнять свои прямые обязанности.
2. Даже если найдется компания, которая опишет свои абстрации достаточно формально, эти абстракции не подойдут другой компании, работающей в той же предметной области и все придется начинать сначала.
sovpel
17.01.2022 15:28+1Что имеется в виду под сложностью системы и как она определяется количественно? Без определений графики выглядят загадочно. В частности, почему для стандартного подхода зависимость линейная, а для low-code — экспоненциальная?
AlexanderByndyu Автор
17.01.2022 15:29Имеются ввиду метрики, например, Sonar.
График условно линейный. Чтобы он был линейный нужно еще побороться. Если руки растут из правильных мест, то можно управлять сложностью. Если нет, то ничего не спасет. Но при low-code, когда нет рефакторинга и автотестов, ничего не поможет.
vassabi
17.01.2022 19:49простейший вариант: копипаста. Если у вас уже есть функция А, которая что-то делает, то чтобы добавить туда новую фичу - чаще всего она копируется и в нее добавляется небольшой флаг, так что теперь у вас будет еще и функция Б (которая на 90% повторяет А - и никакого рефакторинга с выносом общей части).
Я на Java видел как индусы плодят код копипастой, что уж говорить про low-code ...
marshinov
Мне кажется, что low code в ближайшие несколько лет так и останутся игрушками для заказа пиццы. Зато верю в GraphQL и докер. Сделал бекенд, запакаковал в контейнер, подключил к гейтвею через федерацию. Поменьше баз данных и очередей только создавать и баундед контексты правильно определять, но это уже совсем другая история.
AlexanderByndyu Автор
Игрушки или нет, но их опять активно пытаются использовать для критичных бизнес-приложений. Поэтому я статью и написал