Comments 78
Мне кажется, что low code в ближайшие несколько лет так и останутся игрушками для заказа пиццы. Зато верю в GraphQL и докер. Сделал бекенд, запакаковал в контейнер, подключил к гейтвею через федерацию. Поменьше баз данных и очередей только создавать и баундед контексты правильно определять, но это уже совсем другая история.
Платформа не может остановиться на первой версии, поэтому команда будет разрабатывать платформу… всегда и платить этой команде нужно много и долго.
Нужно просто как c rust'ом чтобы компилятор low-code был написан тоже на low-code.
А если серьезно, мне кажется, low-code неплохо смотрится в data flow, когда нужно собирать данные из огромного количества источников в разных форматах, немного изменять, складывать в DWH и тд.
Манихейство - согласно М., в мире извечно существуют 2 самостоятельных начала: светлое (доброе) и тёмное (злое). Тёмное начало в лице 5 тёмных стихий пошло войной на светлое начало и захватило часть его. См. https://bigenc.ru/religious_studies/text/2183045. Непонятно, что заставило автора излагать материал в такой черно-белой манере:( Очевидно лишь, что те "темные стихии", что "пошли войной" - это, конечно, low-code:)
График просто позорный. Хотя бы для приличия обозначили число "фич", на котором графики пересекаются? Надеюсь, это не "1"? Уже не спрашиваю о соотношении "сложности" и "числа фич".
Цитирую: " Как мне кажется, единственный шанс окупить всю эту историю с созданием собственного решения, это продажа внутренней low-code платформы на внешнем рынке, потому что сама себя внутри компании эта платформа вряд ли когда-то окупит." Сразу напомню старое правило - когда кажется, креститься надо. У нас есть такая платформа и она вполне окупалась и до того, как мы начали ее продавать.
Я отнюдь не фанатик таких платформ. Да и сам автор указывает на то, что на практике в сколько-нибудь серьезных системах результат достигается комбинацией low-code и обычного программирования. Далее, еще Кузьма Прутков сказал: " Каждый человек необходимо приносит пользу, будучи употреблен на своем месте." Не надо обманывать читателей, выдавая low-code как "серебряную пулю" цифровизации. Используйте такой подход в уместных ситуация. Для сильнонагруженных систем 24х7 он подходит плохо. Но такими системами круг задач вовсе не ограничен.
(прикола ради) Хотел бы я посмотреть на "тетю Машу" из бухгалтерии, которая запросто " идет в Zapier и «программирует» себе пару триггеров и интеграций." Обратите внимание на дефиницию "тетя". Конечно, low-code - это удел старых теток. А вот программирование - дело для молодых современных бакалавриаток!
И на что не пойдешь в страстном желании облить конкурента дурнопахнущей субстанцией...(реплика в сторону) Вот такая черно-белая логика сильно мешает нам цивилизованно и относительно равномерно развиваться. Искусство компромисса и последовательный системный подход даются нам тяжело...
Жаль, что вы не увидели объективности в статье. У всех подходов есть плюсы, минусы и границы применимости.
Очевидно, что график схематичный, и нужен для того, чтобы показать тенденции. Вы правда верьте в то, что можно указать точную цифру на оси Х?
Интересно было бы узнать как вы посчитали окупаемость внутренней платформы. Что было в затратах? Что в прибыли? Покажите, пожалуйста, цифры. Можно в попугаях, что бы нарушать NDA.
Ответил в треде
Хотелось бы уточнить, а что Вы считаете low-code платформами ? Вот, например, мы делаем решения для розничного бизнеса на базе low-code платформы, которые достаточно сложные, так как закрывают практически все основные процессы таких компаний. И там нет экспоненциального роста сложности. Вот демо (логин и пароль : guest) для оценки сложности. Что мы делаем не так?
Я бегло посмотрел инструмент. Если я правильно понял, вы предоставляете функционал для типовых задач розничного бизнеса. Что-то типа 1С в интерфейсе. Если вашим клиентам хватает кликов в интерфейсе, то все эти клиенты примерно одинаковые и, видимо, не такие большие как может показаться. Например, Леруа Мерлен не взяли бы себе ваш WMS (не в обиду вам, там просто очень много специфики, которую не накидаешь в интерфейсе).
Если вашим клиентам достаточно кликать в интерфейсе и не надо писать код, то у вас отличное low-code решение под вашу нишу. Если брать график, то решения заказчиков не уходят в "красную" зону.
Именно поэтому я и спрашивал, что Вы считаете low-code платформой. Если исходить из определения wikipedia, то это получается та платформа, в которой решение создается при помощи прямоугольничков, стрелочек и так далее (то есть визуально). Лично мне, как человеку с математической подготовкой, такое определение совсем не нравится. Можно без проблем создать визуальный интерфейс, в котором я буду просто писать программу на С++ при помощи мышки (стрелочек и т.д.). Станет ли от этого Visual Studio low-code платформой - вопрос риторический.
Я к тому, что главное - не визуальность, а уровень абстрагирования платформы. Если мы возьмем концепцию MVC, то понятно, что основная логика кроется в M и C, а не V. И каким образом идет задание логики : при помощи мышки, или в виде кода - не столь принципиально. Например, в той же системе отчетности JasperReports есть два представления отчета : визуальный и в виде XML. С точки зрения интерфейса вы правите отчет в одном месте - автоматически правится в другом. Причем коммитится, естественно, XML-файл.
Если я правильно понял, вы предоставляете функционал для типовых задач розничного бизнеса
Нет, платформа универсальна, и подходит практически для любых B2B решений.
Если вашим клиентам хватает кликов в интерфейсе
Тут есть определенное недопонимание. Вся система задается в виде встроенного высокоуровневого декларативного DSL. Сейчас нет визуального конструктора для него, но создать его не проблема. Другое дело, что я не уверен, что им будет удобно пользоваться. Саму логику программы делают не конечные пользователи, а скорее бизнес-аналитики. Являются ли они разработчиками - вопрос сложный, и мы его постарались описать в этой статье.
все эти клиенты примерно одинаковые и, видимо, не такие большие как может показаться
Они все-таки достаточно сильно отличаются друг от друга (и там не только розница). Насчет величины : около десятка клиентов имеют более 5000 сотрудников. Количество работающих пользователей в системе - от 800 до 1500. Базы данных до 4ТБ. Да, это не Газпром конечно, но и не такие маленькие компании. И главное, что они работают ровно в одной системе с одной базой данных (а не с множеством систем, как во многих крупных компаниях).
Расскажите как проходит разработка на такой платформе:
-- где хранится код логики / модели данных?
-- как происходит выкладка на стейджи / прод?
-- нет ли конфликтов логики / моделей при параллельной разработке фичей?
-- насколько просто рефакторить код?
-- нет ли сложности с входом в разработку, потому как новый DSL это всегда порог вхождения?
где хранится код логики / модели данных?
В виде плоских файлов (модулей) в системе контроля версий. В каждом файле может быть как модели данных, так и действия, ограничения и задание интерфейса. Вот пример репозитория. Там все 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, но в целом уже через пару недель люди делали реальные задачи (плюс все-таки в платформе много встроенных защит от того, чтобы сильно накосячить).
Спасибо, стало понятней. Посмотрел ваш репо. Мне кажется это не совсем Low-code платформа. Скорее просто свой DSL.
В моем опыте Low-код платформы – это standalone монстры полные gui-редакторов, через которые "мышкой" конфигурируются основные компоненты для реализации прикладных задач. Подобные системы полны недостатков, о чем ТС упоминает в статье, и я с ним солидарен. Ваш же случай как мне кажется не подходит под это описание.
это standalone монстры полные gui-редакторов, через которые "мышкой" конфигурируются основные компоненты для реализации прикладных задач
Да, да, так я их и видел. Спасибо за комментарий.
вы путаете no-code с low-code платформами
Это суть одно и то же. Если судить по https://www.gartner.com/reviews/market/enterprise-low-code-application-platform то это как раз то, о чем говорит ТС (и я в своем комментарии).
Но путаница есть, например, @CrushBy привел в пример скорее мета-фреймворк со своим DSL и механиками, которые упрощают построение приложение. Такие вещи имеют место быть. Но это не те low-code/no-code системы.
Да, меня тоже впечатляет, что для таких платформ (в частности со своим DSL) нет общепринятого названия. У меня язык не поворачивается назвать тот же 1С - просто фреймворком. Вот Spring - это Java-фреймворк, а 1С - именно платформа. И, на мой взгляд, лучше всего подходит как раз название "low-code платформы".
Если речь об 1С:Предприятие, то это полноценная ERP-система. У нее свои конкретные задачи.
Если брать Elma, Pega, Ibm Bpm - это вот те самые low-code монстры, которые я имею ввиду. Это standalone платформы, через gui которых конфигурируются прикладные задачи.
Решение, о котором вы CrushBy говорили, не попадают под категорию платформ, поскольку это не standalone система. Это скорее мета-фреймворк (над-фреймворк), который с помощью DSL и плагинов для IDE помогает разрабатывать приложения в классическом стиле.
Нет, я именно говорю о голой 1С-платформе, на которой делают решения (в 1С-воском простонародье такие решения называются "нетленки"). Называть ERP-системой платформу 1С без конкретной конфигурации (то есть без бизнес-логики вообще) совершенно точно некорректно.
Допустим. Но отличие вашего мета-фреймворка от этих standalone решений вы подтверждаете? Или для вас это одно и то же?
Отличие конечно же есть. И поэтому писал, что с терминологией сейчас есть проблемы.
В частности я вообще не вижу смысла в визуальном программировании. Все упрется как минимум, в систему контроля версий и merge конфликтов. Как это сделать визуально, а не в plain-code для меня большая загадка.
Но в целом нормальная высокоуровневая система, как эти standalone решения, должна иметь многослойную архитектуру (как, например, стек TCP/IP). Это нужно, чтобы когда на верхнем слое что-то не удается сделать, то можно было бы спустится на уровень ниже, а не падать сразу на написание голового java-кода по сути с нуля.
В комментариях к оригинальной статье уже написали "что вы делаете не так". Вы пишите на странном велосипеде, который никто кроме вас поддерживать не сможет. Не ясна рыночная ниша этого продукта. Но вам нравится и никто не сможем вам запретить. Я бы ни за что для себя такую систему не поставил, потому что нет в мире достаточного количества программистов на этой "платформе". Если говорить про dsl на jvm-стеке, то в Kotlin прекрасный dsl. Почему не использовать его?
В комментариях к оригинальной статье уже написали "что вы делаете не так"
Когда я спрашивал, про что "мы делаем не так", то я писал, что мы успешно делаем сложные решения на low-code платформе.
Вы пишите на странном велосипеде, который никто кроме вас поддерживать не сможет.
Ряд наших клиентов развили у себя внутреннюю экспертизу по платформе и прекрасно самостоятельно на ней разрабатывают. Плюс многие сторонние люди уже ее используют для решения разных задач.
Не ясна рыночная ниша этого продукта
Та же, что и у платформ 1С, Microsoft Access и прочих.
Если говорить про dsl на jvm-стеке, то в Kotlin прекрасный dsl
Как я уже писал выше - главное не язык, а уровень абстрагирования. У Kotlin'а уровень абстрагирования не сильно выше, чем у Java. А у lsFusion выше даже чем у 1С.
У Kotlin'а уровень абстрагирования не сильно выше, чем у Java
Либо вы плохо знакомы с Kotlin, либо у нас разное понимание абстрагирования. В Java вы вот такое не напишите. Рекомендую еще посмотреть на сигнатуры функций из примера на главной страницы Ktor. Опять таки уровень абстракции сильно выше, чем в Java. Ну и вишенка на торте - корутины.
Если все-таки когда-нибудь доделают expression trees, то будет комбинация полностью покрывающая заявленные вами преимущества: декларативность - dsl. Возможность очень сильно перколбасить байткод (и не только для асинхронного взаимодействия) - корутины. Эффективная трансляция в SQL - деревья выражений. Только вот такой DSL будет на 100% нативным для JVM и при желании его допишем любой программист, знакомый с Kotlin, а не с вашим особым языком. Все подсветки синтаксиса, автокомплишны и т.д. тоже будут работать автоматом. Пока expression trees нет, есть Spring Data или JOOQ, которые такие же декларативные, как ваш "особый уникальный невероятный (без регистрации и смс) язык".
Аналогичные DSL без изобретения языка можно довольно быстро организовать на .NET-стеке с помощью уже упомянутых деревьев выражений и LINQ или вообще F#'а. Нет принципиально никакой разницы - учить ограниченное подмножество существующего языка или ваш язык. Ваша дискуссия с@lairв оригинальном треде - тому пример. Просто, видимо, у вас сильная эмоциональная связь с вашим детищем, которая не позволяет объективно его оценивать.
Еще раз, мы говорим о совершенно разных задачах и предметной области. Я не отрицаю, что Kotlin - хорошая технология для своих задач.
Пока expression trees нет
Странная логика. Сравнивать технологию, которая уже работает годами с тем, чего нет, и неизвестно будет ли когда-либо.
Аналогичные DSL без изобретения языка
Извините, но я не очень понимаю, что значит "DSL без изобретения языка". DSL - это и есть новый язык. Кстати, а что насчет SQL ? Это классический DSL, разработанный под конкретные цели. Или может вместо него надо было использовать Cишный синтаксис ? Напомню, что он создавался для тех же людей, что и low-code платформы.
Просто, видимо, у вас сильная эмоциональная связь с вашим детищем, которая не позволяет объективно его оценивать.
К сожалению, Вы оцениваете все только с точки зрения технического специалиста. Если все-таки рассматривать бизнес-составляющую (скорость, цена, качество), то все становится гораздо интереснее. Именно благодаря скорости/цене/качеству за 5 лет на решения на базе lsFusion перешли 70% рынка крупного ритейла в Беларуси. И клиентам все равно, какие модные или немодные технологии используются. Им важно то, чтобы можно было очень быстро реализовывать в системе их пожелания.
Я вам о том что ваш dsl можно было сделать без изобретения своего ЯП. Вы мне о том, что ваш продукт дешевле SAP и 1С. Ну дешевле. Вы молодцы. Dsl без изобретения языка - это когда вы берёте подмножество существующего яп и даёте прикладниками его. Без потери выразительности можно было использовать и linq-синтаксис C#, перегрузив SelectMany и Select и компутейшны из F# и kotlin dsl, но вы написали своё. Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье, но вы продолжаете настаивать, что ваш язык лучше. На мой вкус он ничем не примечательный и никаких революций вы не произвели. Tool support вашего dsl хуже, чем у mainstream-языков. Вы утверждаете, что "он понятнее для не программистов", но это бездоказательно. Объясните, почему нельзя добиться тех же результатов используя вашу платформу и один из языков на выбор в качестве dsl: Kotlin, C#, F#, TS, Python, Ruby. Я могу изобразить аналогичный вашему код на каждом из этих языков. А копипастить по примеру и обезьяну можно научить.
Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье
Это по той простой причине, что большинство комментаторов не всегда пытаются разобраться в сути проблемы, а оценивают поверхностно. Точно также, как и Вы.
Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье, но вы продолжаете настаивать, что ваш язык лучше
Сейчас речь идет не о языке, а о высокоуровневой архитектуре для построения приложений. Язык вторичен. Чтобы объяснить разницу, важно понимать, что при написании на lsFusion 80% - это декларативный код, а 20% - императивный. Во всех остальных системах - наоборот.
К сожалению, вот так абстрактно объяснить это достаточно тяжело, но чтобы просто понять, ответьте - зачем придумали SQL ? Знаете, кто был его целевой аудиторией (и сейчас не только программисты его используют). Почему не взяли стандартный Cи-подобный синтаксис ? Мой ответ : потому, что он гораздо лучше подходит для конкретной задачи/архитектуры (формирования запросов для реляционной логики). А ваш какой ?
И зачем вообще по-вашему существуют DSL ? Зачем существуют средства для разработки DSL в той же IDEA, если новые языки не нужны ?
Язык вторичен
Итого, можно было не писать парсер под новый язык, а использовать подмножество другого JVM-языка и сэкономить ресурсы, что я и пытался донести.
Это по той простой причине, что большинство комментаторов не всегда пытаются разобраться в сути проблемы, а оценивают поверхностно. Точно также, как и Вы.
Вот прям нет пророка в своем отечестве.
Язык вторичен. Чтобы объяснить разницу, важно понимать, что при написании на lsFusion 80% - это декларативный код, а 20% - императивный. Во всех остальных системах - наоборот.
Во "все остальные системы" вы включили системы написанные на хаскеле, linq, spring data и jooq?
К сожалению, вот так абстрактно объяснить это достаточно тяжело, но чтобы просто понять...
Уже объяснили. Это называется "паттерн "интерпретатор" в ООП и "свободная монада" или "Tagless Final" в ФП.
Зачем существуют средства для разработки DSL в той же IDEA, если новые языки не нужны ?
Для более короткого/простого/эффективного решения узкого, но распространенного класса задач. Я не говорю, что новые языки не нужны. Я говорю, что конкретно придуманный вами язык (не платформа) не нужен. Хороша ли платформа или нет я не знаю, раз она помогает вам зарабатывать деньги, для вас она хороша.
Итого, можно было не писать парсер под новый язык, а использовать подмножество другого JVM-языка и сэкономить ресурсы, что я и пытался донести.
Во-первых, парсер пишется же не с нуля, туда просто загружается грамматика. Там не было особо эконимии ресурсов. Но тут есть еще один нюанс.
Наш язык никак не ориентирован на Java/Kotlin и т.д. разработчиков. Я себе слабо представляю ситуацию, когда Java разработчик будет писать на lsFusion. Точно также, как я слабо представляю, как Java разработчик вдруг станет 1С-программистом (в обратную сторону, кстати, частый кейс.
И это не потому, что платформа 1С или lsFusion - плохая. А потому, что разработка на 1С и lsFusion тесно связана с бизнес-анализом (общением с пользователями напрямую, быстрой разработкой без какого-либо ТЗ и по сути самостоятельным внедрением), и программирование там идет на гораздо более высоком уровне. С другой стороны у таких платформ ниже порог вхождения. Любой Java-разработчик при желании сможет писать на 1С или lsFusion. В обратную сторону - это далеко не так.
Итак, если мы никак не ориентируемся на Java-разработчиков (или Python/Kotlin), то зачем нам было брать Cишный синтаксис ? Ведь все равно им будут пользоваться люди, которые не знают ни того, ни другого. Не лучше ли тогда сделать свой наиболее удобный DSL под конкретную архитектуру ?
Котлин - это компиляция фич из других языков (в том числе и то что по ссылке) помноженная на унаследованные ограничения JVM. Такой билдер конкретно в джаве (и конкретно в данный момент) не напишешь, но менее красивый эквивалентный код вполне. Пример того, какую шляпу можно получить, если думать о дсл, а не о пользователях, можно посмотреть в Gradle. Сам по себе Котлин никаких решающих преимуществ не дает в части дсл, чтобы еще и от него зависеть.
Десктопный клиент в гигабайтах, отдельное IDE, свой DSL это, чтобы порог вхождения был повыше и перспектив поменьше.
Подобная система система ценна именно написанным и работающим бизнес кодом, который легко кастомизируется программистом с улицы.
А сам движок сваять ни разу не сложно, если мозги есть, то и в "одно рыло" можно сделать. Сам когда-то делал ради интереса такой pet-проект (javascript/php/mysql) и забросил, сейчас где-то в интернете валяется с открытым кодом на гите. Видео можно на двойной скорости смотреть, там 7 минут https://www.youtube.com/watch?v=e10i7o0gVpI как работало, сейчас jquery не модно и хрен с ним.
Десктопный клиент в гигабайтах
Это у кого ? Десктопный клиент весит 18МБ (заархивированный через Pack200). Но большинство у нас используют веб-клиент. Там и функциональность больше и устанавливать ничего не нужно.
отдельное IDE
А есть платформы без IDE ? В качестве IDE используется IDEA, которая можно сказать лучшая IDE в мире.
свой DSL это, чтобы порог вхождения был повыше и перспектив поменьше
Свой DSL наооборот делает порог вхождения ниже (не все люди могут стать Java-программистами).
Подобная система система ценна именно написанным и работающим бизнес кодом, который легко кастомизируется программистом с улицы.
Скажите это 1С, на котором написано огромное количество "нетленок" (то есть с нуля, без какого-либо бизнес-кода.
А сам движок сваять ни разу не сложно, если мозги есть, то и в "одно рыло" можно сделать.
Прототип движка сделать то несложно. А вот сделать промышленную платформу, с документацией и примерами, с хотя бы несколькими десятками внедрений на 1000+ одновременных пользователей и террабайтными базами данных, с понятными процессами внедрения, поддержки, доработки и интеграциями - это гораздо сложнее.
Довод о невозможности быстрого тестирования этих приложений выглядит слабым. Юнит тесты там конечно не попишешь, но это ведь обязанность владельцев low-code платформы. А писать интеграционные или GUI тесты ничего не мешает. Разве что отсутствие разработчиков автотестов среди Citizen Developer и желание сохранить минимальный бюджет. Да и то, есть же low-code решения и для написания тестов. Тот же Selenium IDE, например. Если они вдруг поймут, что им нужны тесты и захотят их писать, то подходящие им инструменты уже есть.
Я думаю, что, наравне с аналитиками, мануальные тестировщики хороший источник кадров для разработки low-code. Они глубко погружены в бизнес-процессы, умеют думать за пользователя и не слишком привязаны к инструментарию, который надо осваивать годами (как у бэк- или фронт-эндеров). Кстати, похожая ситуация и у разработчики UI автотестов, которые без особых усилий могут перейти в разработку RPA (еще одна технология из категории "сделаем это по-быстрому"). Другое дело что зарплаты в российском RPA выглядят не очень привлекательными, даже для тех, кто ничего, кроме Selenium тестов не освоил. Но, это уже другой вопрос.
Теоритически можно организовать полноценное автотестирование. Даже если не брать модульные тесты, то е2е написать можно. Но тут, как вы заметили, нужны профи, ни о каком визуальном тестировании речи не идет.
Это напоминает мне историю, когда в американской компании было 1К индусов в Индии и 20 человек в Израиле. Задача этих 20 несчастных была в том, чтобы рефакторить поток г*внокода индусов. Я согласен, можно попробовать так организовать.
Ну, почему теоретически. У меня вполне реальный опыт обучения "с нуля" SAP-консультанта написанию автотестов на Python и Robot Framework. К концу первой недели он начал писать тесты сам. До этого у него весь опыт программирования был ограничен школьными уроками информатики.
Натыкать тесты в Selenium IDE сможет и Citizen Developer. А учитывая что жизненный цикл у low-cod решений приблизительно как у бабочки поденки, им даже PageObject не потребуется.
Я понимаю, что вы говорите. Да, можно обучить не-QA делать работу QA и этот человек будет писать какие-то тесты. Но что нам нужно от автотестирования в конечном счете? Я подразумеваю, что перед выкладкой на прод запускается набор тестов, который говорит, что ВСЯ система работает как надо. Тогда не нужен ручной регресс. Сделает ли непрофессиональный тестировщик такую работу?
Хороший учебник начинается с определения границ применимости тех знаний, которые в нем даются. Известный учебник Куликова по тестированию ПО во первых главах содержит объяснение почему исчерпывающее тестирование невозможно. Собственно вся теория тестирования состоит в поиске компромиссов между ограниченными ресурсами и тестовым покрытием. Сам выбор в пользу low-code происходит из-за жёсткого ограничения ресурсов на разработку, что уж говорить про тестирование? Я думаю, что надеятся на полноценное покрытие в таких проектах не стоит по определению.
На 100% и всеобъемлющее надеяться не стоит, но надо же быть уверенным до релиза, что система работает. Какой вы видите способ? Надеяться, что кто-то из аналитиков написал достаточно тестов после вашего недельного обучения? Как при этом делается релиз?
Повторюсь: лечить подобное подобным. Ждать что аналитики или 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 в том, что они могут быть ближе к пользователю, чем любой аналитик. Иногда это бывает важнее стройной архитектуры (чью ценность я ни в коей мере не умаляю).
А потом все эти "тесты" сломаются и их выкинут как нечитаемой и неподдерживаемое гуано.
Это сплошь и рядом и на обычных проектах происходит. Low-code проекты имеют важное преимущество -- они не могут быть большими. Поэтому и натыкать заново или поменять локаторы методом find n replace в них гораздо легче.
Справедливо:)
они не могут быть большими
Как раз проблема в том, что они могут быть большими. Вы удивитесь сколько людей и компаний верит в то, что критически важные для бизнеса вещи, можно сделать в визуальном редакторе. Собственно, поэтому я эту статью и написал :)
Хорошо, соглашусь что могут. Но, ограниченно по времени. Я согласен с вашим графиком, и на нем есть участок, где системы могут находится в таком состоянии предельной сложности. Но, если добавить на график кривую стоимости владения такой системой, то будет очевидно, что в таком состоянии она долго пребывать не сможет. Очевидно, что стоимость будет расти, во-первых нелинейно, во-вторых быстрее чем у "традиционных".
Автотестирование, конечно может служить средством борьбы со сложность и объемом тестируемой системы, но на ограниченном этапе и в свою очередь может порождать проблемы. И тоже очевидно, что пределы роста для low-code автотестирование ниже, чем у "традиционных". Те есть, основанных на языках программирования общего назначения и специализированных фреймворках и библиотеках.
Если бы бабушка была дедушкой... Выкиньте из разработки тестирование и можно первичную стоимость миниму на четверть урезать, но какой ценой. Low-code оно по цене выглядит привлекательным, как мне кажется, во многом по тому, что вокруг него нет всего того, что позволяет разработке сохранять адекватную стоимость внесения изменений и эксплуатации.
вокруг него нет всего того, что позволяет разработке сохранять адекватную стоимость внесения изменений и эксплуатации
Плюсую! В low-code первая версия выглядит обнадеживающе, а потом резкий рост сложности убивает проект. Когда-то писал об этом статью https://blog.byndyu.ru/2013/12/it.html
а потом резкий рост сложности убивает проект
Согласен. Мы пишем Backend-for-Frontend (BFF) на low-code платформе нашего заказчика, которую он сам и разрабатывает. Когда мы просто проксировали запросы в наши сервисы as is, то с этим как-то можно было жить, но потом начался маппинг, обогащение сущностей из внешних систем, аутентификация и авторизация, дублирование кода из-за сложностей с его переиспользованием и наверное сейчас BFF проще переписать с нуля на Nest.js (потому-что у нас все сервисы написаны на Nest.js) чем поддерживать.
Поскольку вывод начинается со слова "пока", ожидается развитие этой темы. Есть два предложения:
1. Сравнение с подходом DSL. Это серьезный конкурент low-code
2. Рассмотрение систем в динамике.
Одно дело взглянуть на статичную картину, вырезать из нее кусок под LC решение и выкинуть туда возможности по конфигурированию. Но как управлять этим в будущем? Из примера с бухгалтером и смс - что произойдет с кодом кода появится не один телефон, а два? или директор будет иметь два почтовых ящика? А как обрабатывать исключения? и т.д.
Поддержка LC решения в актуальном виде может стоить дороже чем реализация программистами тех хотелок, которые он позволяет сделать пользователю.
Ну и как было у классика: "Две вещи бесконечны: Вселенная и человеческая глупость. Но на счет вселенной я не уверен". Насколько простым и понятным должно быть LC решение, чтобы его спокойно мог использовать не искушенный пользователь?
Серьезный скепсис способна разрушить практика. Хочется увидеть примеры где это реально заработало, причем не с точки зрения реализации, а с точки зрения реального использования таких фич рядовыми пользователями
Интересный факт: долгое время самым популярным языком программирования был макро-язык Lotus 1-2-3. То есть ничего нового под луной нет и low-code подход это то самое, что сделало популярными персональные компьютеры. Могу привести пример времён Windows XP. Работал я тогда сисадмином на металлообрабатывающем заводике. Ну и дали мне там задание сделать систему учёта заказов. Я и сделал ее на Microsoft Access. Там всего кода было - одна строка в которой генерировались номера заказов. Проработало все это около года, а потом к нам пришел новый главбух, который выбил бюджет на допиливание 1С и оно послужило тех. заданием для 1С-ников, которые перетащили все это к себе и добавили списание материалов. Такого добра в мелком и среднем бизнесе полным полно. И когда оно работает, как MVP - этот подход вполне оправдан. Тут я с автором вполне согласен. Не надо только из этой трепетной лани пытаться вырастить битюга.
Спасибо за комментарии. У вас чувствуется опыт за плечами.
Если говорить о том, во что я верю, то я скорее отдаю предпочтение набору готовы микросервисов с понятным входом и выходом. Я был бы готов платить за такие мини-инструменты и комбинировать их в своих системах. Что-то типа https://dadata.ru/ или https://kontur.ru/focus/api/how-to-work. Если бы таких сервисов с API было достаточно много, то и время разработки можно было сократить, переложив часть работы на внешние сервисы.
Правда при этом мы получаем новые точки отказа, но тут уже всё зависит от того, как мы построили свою систему, как мы реализовали fault tolerance и где мы подумали об SLA в нашей системе и какое SLA обещают внешние сервисы. В целом, я думаю, что это может сработать.
А https://albato.ru/ под ваше пожелание не подходит? Сам я с ним правда не работал, но на первый взгляд похоже на то, что вы хотите.
Я бы не стал относить bpmn движки к low code. Чтобы их нормально, полноценно использовать у вас должно быть куча кода вокруг, а умение писать исполняемые бизнесс процессы это отдельная магия которой очень не много кто владеет и это точно не "продвинутый пользователь" и его зарплата точно не ниже зарплаты программиста. Описанный "аналитиком" или менеджером в нотации bpml процесс, чаще всего использовать можно только после полной переработки разработчиком уровня не ниже сеньер.
Да, процессы в camunda замечательно покрываются тестами если у вас есть java разработчик/тестер.
Да, я согласен, что Camunda где-то на грани. Теоритически в ней можно обойтись и без кода, но часто приходится добавлять обработчики. Тут я привел пример с Camunda, чтобы обесопасить тех, кто возьмет ее в работу, от того, чтобы писать код внутри этой платформы. Иначе этот скрытый код будет очень сложно обрабатывать.
Все еще банальнее.
Камнуда фактически не представляет средств работы с данными, верификация, целостность.
GUI интерфейсы камунды хоть и возможны, но максиму на что тянут, это прототип.
Если все элементы процесса без поднятия уровня абстракции пихать в BPMN схему она станет абсолютно не читаемой и не поддерживаемой, многие люди просто в реальности не представляют сколько в их процессах действий поскольку интуитивно их укрупняют. А такой процесс не может быть выполнен, ему нужны все действия. Простейший способ — это понять, попробовать написать инструкцию для любого самого простого действия, а потом попробовать по этой инструкции, строго по ней, выполнить запрашиваемое действие. В итоге многие детали реализации процесса прячутся в коде( тут важно соблюсти баланс ) и требуют разработчика достаточно высокой квалификации, поскольку это распределенная система, да и особенности работы камунды ему нужно знать, а значит знать java. Вот и получается, вроде low code, а разработчиков помноженных на квалификацию нужно не меньше, а возможно и больше, и уж точно с ней не может работать сотрудник не имеющий должной квалификации в ИТ.
Есть поучительный пример индустрии, в которой lowcode одержал убедительную победу — это industrial automation. Сейчас абсолютное большинство систем автоматизации производственных процессов выполняются на тех или иных lowcode-системах, а не-lowcode решения часто получают презрительную кличку «самопал» и допускаются только в самых простых проектах. Почему так произошло — тема для отдельного разговора; вкратце же можно назвать такие причины:
- общие подходы и требования, которые выработала индустрия, оказались хорошо реализуемыми «в целом», без необходимости чрезмерной кастомизации под каждого клиента;
- задачи industrial automation получилось разбить на сравнительно небольшое количество ограниченных контекстов с эталонной реализацией;
- наличие жестких требований к соблюдению стандартов, лицензированию и сертификации ПО и аппаратного обеспечения;
- фактический vendor lock клиентов на готовые программно-аппаратные комплексы основных производителей;
- исторически более низкая квалификация и более низкая оплата труда разработчиков промышленного ПО в сравнении с обычными разработчиками;
- как следствие предыдущего — практически полный отказ от software tailoring в пользу максимальной поддерживаемости, сопровождаемости и прочего maintainability.
Всё это и привело там к тотальному доминированию lowcode, который в таких условиях показал себя настолько хорошо, что удивляешься не тому, что его в промышленной автоматизации так много, а тому, что в остальных отраслях его так мало.
Как сертифицированый специалист по програмиированию контроллеров Omron, перебежчик в .Net, вкусивший Booble.io отвечу))
В промконтроллерах не нужны высокий уровень абстракций, валидация всех данных, структура данных в худшем случае массив данных для конфигурации совмещённых устройств IO. По своему опыту скажу что изменение в коде может потребоваться если отдел закупок не смог купить такую же ревизию устройства которое пошло под замену, и новое устройство имеет отличающийся метод управления/конфигурации от предыдущей версии устройства.
В тоже время требуется понятность/наглядность/отладка , программы написанные и принятые к эксплуатации работают весь жизненный цикл оборудования.
Вот вам и ответ!
Что называется найди все отличия))
Мои рекомендации для будущих low-code программистов/студий, это удобное и быстрое средство для проверки бизнес идеи. Если все устраивает и не предполагается существенных изменений в бизнесе процессах на проекте и нагрузка не кладёт ваше решение, то это ваша серебряная пуля))!
Да Стандарт IEC-1131, где парами определены языки программирования как в текстовом виде так и в графическом. FB + FBD, IL+LD, SFC. Это целый мир, со своими нюансами, проблемами и подходами, про который обычные программисты даже и не догадываются, создавая на коленке какие то свои локальные решения.
Bizagi ещё жив? Давали бесплатно bpmn редактор, который транслировался в workflow с формочками и ролями.
Огромные, монструозные low-code платформы используются в медицине. Там десятки уровней доступа и сотни ролей сотрудников, тысячи форм разных документов и отчётов, и всё это настраивается в визуальном интерфейсе со сложной иерархической системой настроек. Вообще, в медицине процент людей, знающих хотя бы один язык программирования, близок к нулю, и это в основном вызвано зарплатами и специфичным отношением к программистам в госучреждениях. Поэтому система сделана так, что администрировать её может любой выпускник колледжа после 2 недель обучения. Доступа к самой логике и базам данных у сотрудников ЛПУ, как правило, нет.
Может поэтому пошёл такой бум на автоматизацию медицины?
А в этих системах есть какая-то бизнес-логика отличная от стандартной? Может там цена ошибки так высока, что ты можешь брать только мега-отточенные и проверенные кубики, а не делать свое на коленке?
В основном логика "спускается сверху" и пишется сотрудниками РМИАЦ, так как она должна соответствовать требованиям законодательства и приказам ТФОМС. Сисадмины на местах могут подключать модули (есть готовые шаблоны для АРМ поликлиники, стационара и т.д.), настраивать порядок работы в соответствии со спецификой своего ЛПУ, раздавать права. Система в чём-то напоминает 1С, даже имеет свой скриптовый язык. Но на практике никто не лезет в дебри настроек, т.к. через пару месяцев придёт обновление и придётся возиться уже с ним.
ты можешь брать только мега-отточенные и проверенные кубики
Не такие уж они отточенные и удобные. Особенно с точки зрения пользователя - простое действие может требовать кучу кликов и полминуты ожидания. Но функцию защиты информации система выполняет хорошо. Большая часть багов - непонятно откуда возникший Access denied.
По-моему low-code решения - это фактически попытка создать сабсет языка программирования общего назначения с абстракциями, соответствующими какой-то предметной области. И тут возникает 2 проблемы, которые почти невозможно решить:
1. Существует очень мало компаний, которые могут описать абстракции, которыми они оперируют в своей деятельности, с таким уровнем формализма, что их можно описать на языке программирования общего назначения и предоставить в пользование не-программистам. Из-за этого всегда будут возникать уточнения абстракций, которые повлекут за собой дообучение пользователей low-code системы. А они не хотят постоянно дообучаться - им надо выполнять свои прямые обязанности.
2. Даже если найдется компания, которая опишет свои абстрации достаточно формально, эти абстракции не подойдут другой компании, работающей в той же предметной области и все придется начинать сначала.
Что имеется в виду под сложностью системы и как она определяется количественно? Без определений графики выглядят загадочно. В частности, почему для стандартного подхода зависимость линейная, а для low-code — экспоненциальная?
Имеются ввиду метрики, например, Sonar.
График условно линейный. Чтобы он был линейный нужно еще побороться. Если руки растут из правильных мест, то можно управлять сложностью. Если нет, то ничего не спасет. Но при low-code, когда нет рефакторинга и автотестов, ничего не поможет.
простейший вариант: копипаста. Если у вас уже есть функция А, которая что-то делает, то чтобы добавить туда новую фичу - чаще всего она копируется и в нее добавляется небольшой флаг, так что теперь у вас будет еще и функция Б (которая на 90% повторяет А - и никакого рефакторинга с выносом общей части).
Я на Java видел как индусы плодят код копипастой, что уж говорить про low-code ...
Спасибо за статью. Было интересно посчитать. Как вы считаете, может ли UiWebKit стать той самой low-code платформой для Web UI, способной выдержать экспоненциальный рост проекта?
Александр, спасибо большое за статью! Очень обстоятельно и полезно ;-)
У меня вопрос: а что Вы думаете про нишу стартапов и быстрой валидации идей (MVP)? Кажется, что рынок NoCode/LowCode сейчас сфокусирован именно на этой нише с точки зрения того, что 90% идей стартапов проваливаются, важно быстро и дешево их уметь проверять - это я говорю не о быстром создании лендинга на тильде и генерациии трафика на него через директ, а о быстром создании полноценных веб или мобильных приложений с использованием таких платформ как:
Bubble.io (здесь и Web, и PWA мобилки и кроссплатформенные мобилки),
Webflow (только красивый фронт),
FlutterFlow (кроссплатформеннные мобилки с автоматической генерацией кода для подготовки сборок в сторы)
Adalo (простенькие кросплатформенные мобилки с возможностью публикации в сторы)
Glide (очень простые шаблонные мобилки в вид PWA)
Integromat, Adalo (аналог Zapier для интеграций)
Тут получается, что быстро создаем прототип на NoCode/LowCode платформе. Далее:
Если не выстреливает идея, то не жалко потраченных денег и времени (чаще всего того самого человека, которую идею сформулировал (не нужна команда)).
А если выстреливает, то тогда уже можно смело с нуля реализовывать это ПО архитектурно правлиьно с использованием команды программистом, QA, DevOps (при этом есть уверенность, что продукт востребованный и что эти усилия будут не впустую).
Где и как применять low-code платформы