Комментарии 45
Именно так у всех поставщиков и работает:
— 95% функционала на low-code, где вероятность ошибки крайне низка, но и гибкость ограничена
— 5% допиливается вставками своего кода или подгрузкой модулей/плагинов/библиотек сторонних фирм
Во-вторых, low code он потому и low code — там есть код, но его мало. И системы предназначены для вставок low code
Возражение № 5. Концепция LowCode не предназначена для абстрактных расширяемых компонентов и поведенческих паттернов, которые мы все так любим. Единственный паттерн наследования поведения в LowCode — это copy-paste, который используется повсеместно.
Возражение № 6. Написание текста программы на любом языке будет более продуктивно, нежели работа с GUI и мышью.
Возражение № 7. Хваленый стек визуальных инструментов на деле оказывается неудобоваримым глючным дерьмом, который даже близко по возможностям не доходит до любой IDE.
Возражение № 8. Концепция LowCode не самодостаточна. Такие системы несут в себе очень ограниченный набор строго определенного функционала, а посему быстро начинают обрастать различными самопальными велосипедами и сателитами.
№5: бездоказательно. Прекрасно расширяется.
На личном примере: на прошлой неделе добавили компонент «визард» в репо компонентов и далее через клики мышки создаем UI с визардом. До этого расширили компонент «график» добавив range chart.
Требуется ли ручной код? Да, но минимально, в точках вставки для допиливания.
№ 6: вам нужно попробовать оба подхода, чтоб экспертно заявлять. Пишу код последние 30 лет и мое мнение несколько отличается. Нужно понимать, где low-code применим, но №6 — голословное заявление.
№7: в этом есть доля правды т.к. каждый поставщик low code имеет свое видение, не втискивающееся в традиционный коцепт source code development IDE (SC IDE).
В защиту low code нужно заметить что SC IDE на сегодня — шаблонная задача, которая решается также шаблонно. Low code IDE — задача более сложная и требует микро-взрыв мозга чтоб преодолеть шаблоны разработки.
№8: В этом сильная и слабая сторона low code. Эти системы лучше подходят для корпоративной разработки, когда вариативность UI ограничена, UI стандартен и порог вхождения в UI для посьзователя крайне низкий, чтоб любой новичок быстро освоился.
Пытаться создать уникальный UI на low code это такая-же глупость, как писать веб-сайты на ассемблере.
А насчет возражений №№2 и 3 полностью согласен: с SaaS капканами и расценками поставщики совсем обалдели от жадности и ждет их бесславное забвение, когда маятник SaaS качнется в обратную сторону (on-prem first). А хранить корпоративный код в облаке у безымянного провайдера, это как лезть на новый уровень игры и не сохраниться — безумие.
Ну ваш коммент выше — он тоже не доказательство. А лишь ваше частное мнение, основанное на неописанном большом опыте работы с некими неуказанными продуктами, разве нет?
Удачи.
Ну вот скажем свежий пример: продукт, который претендует на то, что без программирования будет позволять рисовать некие дашборды, которые показывают данные и графики, в том числе из time series DB под названием OneTick. Она сама по себе редкая, поэтому найти продукт, который с ней из коробки работает, мы посчитали удачей.
Нарисовали дашборд довольно быстро. Показали пользователям. И сразу проблема — дашборд показывает графики котировок на некие бонды, бонды трейдерам интересны разные, поэтому выбирать инструмент нужно было обязательно. А бондов этих — их порядка 50 или 150 тысяч, не так важно точное число, как тот факт, что показать их в виде таблицы не прокатит — никакой UI не позволяет нормально работать с такого размера таблицей.
Выяснилось, что трейдеры эти свои бумаги, они их, как ни странно, помнят. Ну т.е., вы можете запомнить такое нечто, как ISIN, который выглядит как RU000A0JR5F7? А они могут — это их работа. Поэтому идеальный ввод для них — это так называемый комбо-бокс, выпадающий список с полем ввода, куда можно вводить часть ISIN. Ну и что выяснилось — что способа написать обработчик события OnKeyUp, например, не предусмотрено. Т.е. сделать собственный lookup, как это называется скажем в Excel, нельзя. В Excel можно, на VBA, а тут нет.
Дальше стандартная претензия — нет хранения версий. Работа командой превращается в мучение. Нет диффа, нет слияния версий.
Как говорится, угадайте с трех раз, куда отправился данный продукт, благо мы не успели приобрести лицензию, и пользовались бесплатным триал периодом? Правильно — на помойку.
Другой случай — так называемые BPM решения (конкретно — от IBM). Вот у вас ситуация 95-5, а там у меня была примерно обратная. Т.е. 95% решений писались на языке программирования, и только редчайшие 5% укладывались в возможности, предоставляемые системой через UI. Это на помойку не пошло — но все кто на этом разрабатывал, кляли продукт почем зря. Нравился он только продавцам лицензий на него.
№ 6: вам нужно попробовать оба подхода, чтоб экспертно заявлять. Пишу код последние 30 лет и мое мнение несколько отличается. Нужно понимать, где low-code применим, но №6 — голословное заявление.
Я использовал и low-code решения, и традиционное программирование. Могу подписаться под каждым словом: разработка на low-code дольше и сложнее. Да, какие-то простые решения на low-code действительно получаются, кхм, простыми (уж извините за тавтологию), и сразу же, по сути, задокументированными. Но в реальной жизни простые очень быстро перестают быть простыми, и low-code превращаются в нагромождение схем/блоков. И если вам нужно внести изменение где-то в середине сложного бизнес-процесса, вполне вероятно, вы их возненавидите. По крайней мере, если вы параллельно видите, насколько проще это делается в классических средах, с исходными текстами.
Мы знаем, что часто в low code приходят инженеры с уровнем абстракции code first и начинают из low code делать code first. Спрашиваешь — зачем тут так много кода, это можно было бы правильно сделать, и слышишь в ответ «что-то писать захотелось, не чувствую себя творцом». Ага.
А теперь представим, что мы написали сотню микросервисов и через полгода где-то что-то нужно поправить.
Вопрос не в том, чтобы возненавидеть или радоваться в коде (будто тысячи строк кода понятнее сложных схем) — нейминг и возможность сделать абстракцию важно. Если у вас большой бизнес-процесс или задача интеграции, сделайте подзадачу. Всё, как в традиционных парадигмах. Никто не мешает и большая часть решений позволяют.
№5: бездоказательно. Прекрасно расширяется.
Это не расширение, а использование шаблона. Речь идет о возможности наследовать сам шаблон, например создать другой шаблон визарда на основе старого, добавив дефолтные экраны Greeting и Confirming (наследование). Или создать другой бизнес процесс на основе поведения старого, с определенными изменениями (полиморфизм). И все это мышкой.
№ 6: вам нужно попробовать оба подхода, чтоб экспертно заявлять.
Не хочу меряться бородами, я из эпохи Microsoft Access, Delphi, Visual Basic/C++… Кроме того почти 10 лет работал с различными BPMS. Так что визуальных инструментов для программирования насмотрелся достаточно. Все визуальные среды имеют одни и те же проблемы с копированием, редактированием, рефакторингом, поиском и поддержкой функционала. При отсутствии кода как такового усложняется контроль изменений, бекап, и переносимость. Кроме того, визуальные среды плохо справляются с промежуточным состоянием: в коде я проектирую и пишу в том порядке, как мне удобнее — до момента компиляции это абсолютно неважно. Визуальные же среды требуют строгую последовательность действий: нельзя выбрать компонент, который еще не существует и не описан. А ввиду ограниченности функционала все среды всегда имеют fallback в какой-то нативный язык программирования, но он как правило уже плохо связан с визуальным редактором — любое изменение мышкой уже не отражается автоматически в коде. И постепенно туда стекает весь функционал проекта.
№7: в этом есть доля правды т.к. каждый поставщик low code имеет свое видение
Я бы даже больше сказал — поставщику ровным счетом насрать на то, кто и как будет работать в этих визуальных средах, особенно об эргономике и удобстве разработки. Его основная задача — задвинуть недалекому клиенту свой продукт, продемонстрировав как просто и красиво там делается "Hello World". А клиент в свою очередь наймет чертей, которые и будут копошиться в этом дерьме.
В защиту low code нужно заметить что SC IDE на сегодня — шаблонная задача, которая решается также шаблонно. Low code IDE — задача более сложная и требует микро-взрыв мозга чтоб преодолеть шаблоны разработки.
Ну да, построить семантическую среду, которая бы распознавала текст программы, текущий контекст, подсвечивала бы в реальном времени ошибки компиляции, применяла бы эвристические методы анализа кода, корректировала бы программиста и подсказывала бы проблемные места и лучшие решения — это шаблонная задача. А некая визуальная среда состоящая из типовых элементов, блок-схем, формочек и комбобоксов требует, однако, взрыв мозга! Еще интересно какие шаблоны разработки она преодолевает? ФП и теория типов — вот это взрыв мозга и преодоление шаблонов! А то, что в визуальных редакторах — это лишь Basic XXI века.
№8: В этом сильная и слабая сторона low code. Эти системы лучше подходят для корпоративной разработки, когда вариативность UI ограничена, UI стандартен и порог вхождения в UI для посьзователя крайне низкий, чтоб любой новичок быстро освоился.
В этом вся суть. Такие среды позволяют линейно и методично клепать типовой функционал низкоквалифицированным персоналом. Только вот общие затраты почему-то на порядки превосходят традиционные решения.
№6. low code это новый уровень абстракции разработки, она постоянно растет. Сначала машинные команды, потом память, потом функции, потом ООП, потом фреймворки и компоненты. Теперь компоненты становятся самодокументируемыми и гибко расширяемыми — low code.
Мы знаем случаи на практике, когда команда разработки на питоне не могла завершить сервис месяцами, который мы внедрили силами джуна и менеджера за две недели. Замечу, что большая часть наших ребят — это разработчики, и мы понимаем что такое разработка. PHP, Python, Go, Node.js, *.js, Flutter — на всём этом мы пишем. Но при этом мы не хотим постоянно отвлекаться в разработке на минорные правки, нам хочется писать нормальный интересный код, и принцип low code этому способствует. Почему вы принцип путаете с каким-то конкретным инструментом, о котором вы не говорите? :)
№7 а давайте конкретно, вы о каком конкретно стеке?
№8 Давайте конкретно? Если вы спроектировали интеграцию в Talend, и она у вас выгрузилась в отдельный docker и работает автономно, но при этом в месте разработчика у вас все интеграции под рукой — где там место «самопальному велосипеду»? Наоборот, это способствует более правильной архитектуре и не перегружает конечные системы лишней логикой интеграций. Это про ESB. Но тоже самое можно говорить и про бизнес-процессы, и про моделирование данных, и про интерфейсы и т.п.
Замечу, что большая часть наших ребят — это разработчики, и мы понимаем что такое разработка. PHP, Python, Go, Node.js, *.js, Flutter — на всём этом мы пишем.
Возможно не получается именно потому, что на всем этом вы пишите. Сразу. У вас нет единой технологии, стратегии и стека решений, а соответственно и единой команды с хорошими экспертами в своей области. Кроме того, что многие вышеупомянутые вами языки нетипизированные (как например TypeScript, Java, Kotlin, C#) и годятся лишь для поделок на коленях. Принципы я изложил в посте выше — визуальная среда хуже справляется с разработкой нетиповых задач, но требует меньший порог вхождения.
№8 Давайте конкретно?
Конкретно все BPMS. Вам продают визуальный редактор и движок для выполнения процессов. Сам по себе этот движок ничего не делает и не умеет делать. Единственное, чем он занимается — это дерганием сторонних сервисов, которые и делают всю необходимую работу. Все это называется гордым словом Business Orquestration. Для каких-то специфических задач или других технологий связи вам продают отдельно "бизнес-коннекторы".
Основное мое возражение к подобному (а также к любому виду визуального программирования) — невозможно использовать Version Control. И даже вменяемый diff двух веток обычно нельзя сделать. Т.е. убивается совместная работа.
Почему-то весь этот рекламируемый конструктор всегда визуальный. Эти самые большие блоки конструктора, которыми эти самые citizen developers пользоваться — они при помощи текста, а не картинок в одно целое собираться никак не могут? Все эти бизнес аналитики, расписывающие и программирующие процессы из высокоуровневых элементов — они с текстом работать не умеют что ли?
2. Если вы используете уже существующие low code, то важно не обобщать, а смотреть конкретно. Я приводил скрины Talend — в нем есть version control. И всё что делается визуально, конвертится в код, который может далее использоваться как угодно в контроле. Другое дело, что сами компоненты генерят кучу кода, который сложно валидировать. Для этого есть инструменты визуального контроля. Тут безусловно другие принципы, и применять codefirst подход к более высокому уровню абстракции это как жаловаться сегодня из «уровня абстракции ассемблера», что в современных высокоуровневых языках не видна работа с памятью и машинными командами.
2.1. И ещё одно соображение, что изменения внутри конструктора вовсе не всегда должны проходить версионный контроль, потому что есть понятие «последняя миля автоматизации». Это как git к редактору уровня в игре прикручивать — ну в теории можно, но рельно ли нужно? git нужен к движку.
Не понял аргумента, почему не важно и почему version control не нужен. Вот есть что-то написанное на low code. Соседний отдел что-то в прошлом году поправил и поэтому у меня сегодня (только сейчас заметил, т.к. этот отчет раз в год запускается) чего-то не работает. Как мне искать, что именно они там правили и что по дороге сломали?
Давайте от абстрактных размышлений перейдем к конкретным.
Ваш пример. У вас есть некий отчет, который настолько вам нужен, что вы им аж раз в год пользуетесь, и при этом этот отчет для своих нужд может поменять какой-то другой отдел. Если у того отдела свои задачи, то лучше ему дать собственный отчет и пусть они меняют его (и в LCAP это сделать просто). Если же это кто-то из ваших сотрудников поменял, и он перестал формироваться и вы через год это обнаружили (допустим, сотрудник уже не помнит зачем и что он менял), и в той low code системе нет возможности посмотреть изменения конфигурации, то благодаря самодокументируемости вы пересоберете отчет вновь и быстро.
Собственно, сравним с парадигмой code first:
а) у вас могли поменяться конфиги (не факт что изменения конфигов логируются, а если логируются, то они в нормальном виде)
б) у вас код вообще мог не меняться, а поменяться третья система (а тесты регулярно не бегают, потому что их обычно редко кто просто так гоняет, и наличие хороших тестов в традиционной разработке — отдельная тема).
Но в low code вы визуально понимаете как что работает, и lowcode ные вставки кода читаются за минуту. А в code-first коде формирования отчета, который вы трогали год назад, вы разбираться будете минимум пару часов.
И это не имеет отношения к разделению прав.
Давайте от абстрактных размышлений перейдем к конкретным.
Да. Вот там в статье картинки имеются. Как будет выглядеть поиск изменений в этих процессах кроме 'открыть два варианта рядом и старательно сравнивать, чем они отличаются'?
Можно показать? Ну вот набор извлекаемых полей (я так понимаю, оно для этого служит) в tExtractJSONFields_1 изменился.
Так вот, году эдак в 2013 я написал инструмент, который умеет экспортировать проект в виде ZIP с папками и файлами, где лежит как BPMN диаграмма, так и те скрипты (код), которыми этот проект расширяется — потому что функциональности BPMN не хватает в каждом первом проекте. Версионирование там есть — но убогое. Сравнение выглядит именно так, как вы описали. А в экспорте по крайней мере можно положить две версии рядом, и посмотреть нормальными инструментами, что же там изменилось.
Ну так вот — инструмент написан в далеком 2013, но еще год назад мне с благодарностью сообщали, что он все еще используется — то есть с тех пор никакой возможности сравнить две версии процесса не появилось.
то есть с тех пор никакой возможности сравнить две версии процесса не появилось
У меня есть некие подозрения, что это потому что IDE, в которой эти квадратики и стрелочки рисуют все та же — из 2013 года.
Но за примерно три с половиной года ситуация с версионированием при мне только становилась хуже. Изначально был проект, который лежал в VCS. Потом сделали свою. И понеслась…
Ну и за компанию — чем вся картинка лучше текста в духе (понятно, что уродливо, но я над синтаксисом языка особо и не думал)
tPrejob_1 -[OnCpmonentOk]-> tFTPConnection_1
{
tRESTClient_1 -[row2 (Response)]-> tExtractJSONFields_1 -[row3(Main)]-> tJavaRow_2 -[row4(Main)-> tFileOutputRaw_1
}
tRESTClient_1 -[onSubjobOk]-> tFTPPut_1 -[OnComponentOk] -> tFTPClose_1По которому, если кому удобней так смотреть, можно эту же картинку рядом нарисовать.
1. Сам пользователь (менеджер/директор), который взял и накидал нужную ему схему?
2. Свой выделенный ИТ-отдел?
3. Внешний фрилансер/контора, наподобие допиливателей 1с?
Что с внедрением: переписал файлик со схемой и вперёд? Вжух-вжух и в продакшен?
И что с ответственностью за такую «разработку»: Кто что будет говорить в случае ошибок, что с этим делать? Например:
1. Манагер: да я не специалист. И ничего делать не буду, потому что не знаю.
2. Свой отдел: тонкости процессов производства в другом департаменте/городе/стране пусть описывают те, кто в это разбирается. Нам дали ТЗ мы по нему сделали. Неправильно работает — правьте ТЗ. Ну, мы конечно, поправим. Мы же ИТ. Но лучше ещё раз пройти обучение. А вообще, мы были против этой системы, давайте внедрим другую.
3. Фрилансер: да я вообще вас не знаю.
Как вообще это «по-правильному» выстраивается?
2. Внедрение. Бывает что да, вжух и в продакшен, потому что если ты поменял понятную часть в конструкторе (в интеграции атрибут добавил например), то с высокой долей вероятности тестировать code-first подходами не требуется по ряду причин. Или если вы в приложении что-то изменили.
На ТЗ нет ни у кого времени. Мы не видели ни одного ТЗ, даже госовского, чтобы там не менялось в процессе очень многое. Именно с этим борется Agile, ТЗ это не «бережливое» производство, если мы IT берем (в строительстве в качестве ТЗ BIM и там другая история).
2.1. Преодолевать сопротивление IT нужно, потому что рано или поздно текущий пузырь роста зарплат к производительности труда рухнет, так не может объективно долго продолжаться.
Выстраивается это тем, как учит Agile — разработчики и продукт оунер начинают мыслить задачей в терминах ценности. Выстраивается всё точно так же, как и в обычной разработке. Просто разработка становится больше консультантом, наставником и дизайнером («давай подумаем как это лучше сделать»), но нормальные it команды и так уже так работают, просто теперь они будут работать еще быстрее.
ИМХО: то что два программиста сделают за день, через «BPMN» делается дюжиной программистов за неделю.
зато рюшечки и квадратики можно потягать руками на презентации.
Об отсутствии адекватного CVS/CI/дебага/отладки/бекапов вообще молчу.
Хороший, даже блестящий, разработчик, не в состоянии сделать что-то хорошее в low code, пока не сменит парадигму с code-first на более верхнеуровневую low code.
И потом, эти же разработчики в code first решениях устают от операционки — «задачи неинтересные».
Если вам реально интересно докопаться до сути, а не прибежать в комменты и сказать что-то, что вообще никак нельзя проверить, дайте подробности: какая задача, какие фреймворки, в чем проблема. Давайте обсудим конкретно.
Можно еще сделать систему с единственной большой красной кнопкой "сделай мне хорошо". Нажимаешь — и все сразу есть. Ума не приложу, почему еще никто не догадался до такого. Энтерпрайзу будет большая экономия средств. Что раньше делал целый отдел, решается одним кликом.
В энтерпрайзе такие системы присутствуют только потому, что продавцы хорошо присели на уши членам правления с подобными тезисами. По-факту получается следующее:
- Это вендорлок
- Отсутсвие разработчиков
- Бизнесу совершенно без разницы на чем написан софт. Я ни разу не встречал настолько продвинутых бизнесов, которые самы что-то делали в лоукод системах
Выбор инструментов должен быть осознанным. В первую очередь должна быть команда которая умеет пользоваться этими инструментами.
Это же всего лишь один из вариантов. Хотите писать код — да пожалуйста, пишите. А у low-code систем есть свои потребители, в том числе в Enterprise.
Просто бизнес-аналитики, не знающие ни одного языка программирования, довольно легко учатся использовать low-code для своих локальных задач. А если low-code система еще и умеет делать веб-сервисы и обращаться к ним, или что-то вроде собственных библиотек, эти локальные, созданные экспертами в своей области, решения идут дальше.
Проблема в том, что в 90% случаев, после того как эти ребята нафигачат что-то в low-code и упрутся в ограничения или в неподдерживаемые вещи, они приходят к обычным девелоперам и говорят "ну мы вот уже работающее решение накидали на 90%, допилите недостающее". А решение это уже в продакшене, agile же ведь, все дела, и у него 2к пользователей. Т.е. вариант "двайте все это говно выкинем и задизайним по нормальному" уже вообще никак не вариант. И обычным ребятам, которые против low-code, приходится жрать это говно ведрами… ну либо всеми правдами и неправдами отнекиваться от участия в таком (но это уже больше для опытных, кто прошел первый вариант хотя бы разок). Поэтому и пишут тут, дабы оградить молодых неопытных коллег от этих граблей.
Иногда они подходят, но уж точно не для энтерпрайз уровня поделок, у которых цикл жизни может быть длинной в десятилетия.
Вообще мое мнение, что все эти лоу-код штуки они не от богатства, они от нужды или недальновидности. Часто нет (по разным причинам) нормального архитектора, который сделат человеческий fit-gap анализ. Нет девелоперов, которые смогли бы в high-code. Или не было того, кто мог бы сказать твердое "нет" продаванам лоу кода. Ну и прочие подобные негоразды.
Согласна с вашей мыслью, что у многих просто нет квалифицированной команды, способной оценить все риски и перспективы, а затем выбрать лучшее решение.
Правда ли, что low-code нельзя применять в enterprise-решениях: разбираемся с основными возражениями