Comments 14
И вот тут и есть фундаментальная проблема, первая которая звучит, " выкидывают все и переделывают ", а вторая, сложность техническая и бытовая, это как бы совсем не пересекающиеся вещи. Очень часто задача которая выглядит предельно простой, а давайте поменяем цвет кнопки, по факту требует, " выкидывают все и переделывают ". Не плохо бы в начале именно эту мысль и доводить. Да и мало кто отдает себе отчет, что, "" выкидывают все и переделывают ", очень легко может быть три и более нулей к бюджету.
Очень часто задача которая выглядит предельно простой, а давайте поменяем цвет кнопки, по факту требует, " выкидывают все и переделывают "
Для этого необходима правильная архитектура и вот как раз обычно low-code решения берут на себя часть построения этой архитектуры (особенно в части всяких низкоуровневых решений)
На практике все эти подходы разбиваются в прах когда становится понятно, что узор из стрелочек и прямоугольников работает не так как задумывалось и это нужно отдебажить. Казалось бы обычная для ИТ ситуация, но ни рисователи стрелочек, ни разработчики этих систем как правило оказываются не способны преодолеть такую, казалось бы тривиальную проблему. В результате менеджмент просто меняет один хайп на другой и хомяки продолжают крутить колесо.
Разве? запустил процесс и у тебя бодро побежали подсвечиваться стрелочки и квадратики.
(и в довольно большой мешанине стрелочек и квадратиков у нас разок оказалось, что контролер видит ошибку и у него 2 пути, утвердить или вернуть на доработку. Но при рисовании стрелки "вернуть на доработку" ошиблись, точнее там во всех квадратиках было "если поле не заполнено, то заполнить, иначе идем дальше" и в итоге процесс не задав никому вопроса приходил обратно на контролера.
В итоге фактически у него был выбор "пусть задача висит на тебе" или "утверди, пусть идет дальше".
Нормально отдебажились.)
Очень зависит от конкретной системы, некоторые вполне себе нормально покрываются автоматическими тестами и отлаживаются. Но понятно дело для этого нужен разработчик и явно не джун.
В более совершенных системах можно делать блок схему из блоков которые сами сосоят из блоков и это решает поблему взрыва.
нескольких сотен сценариев выглядит в no-code системе как взрыв квадратиков и стрелочек, который наш мозг не способен осознать.
По опыту работы с JBPM, Drools, Camunda, Mulesoft, Hasura довольно успешно работает следующая стратегия: Аналитик вместе с заказчиком рисует блок схемы, а программист потом доводит эти схемы до рабочего состояния.
Плюс на этапе обсуждения схема это не рабочий но понятный макет, который потом превращается в выполняемый код. Это сокращает, время разработки. Но бывали моменты когда была нужна функциональность, отсутствующая в готовых кубиках. В этом случае было грустно, надо было писать код для системы low-code, а не бизнес функциональность.
Я в течение 5 лет участвовал в разработке очень сложных промышленных решений на одной очень интересной low-code платформе, и могу сказать следующее:
1) миф об ограниченности применения low-code платформ бытует среди адептов классической разработки лишь только потому, что в широком доступе (к сожалению) нельзя найти и потестировать достаточно "взрослые" платформы. То, что можно найти, по сути предлагает либо простые конструкторы простых веб-сайтов, либо негибкие конструкторы для типовых бизнес-задач вроде склада, онлайн-магазина и т.п., не рассчитанные на масштабирование. Я работал с системой, которая может решить (и решает) очень сложные задачи, связанные с обработкой больших потоков данных в телекомах, процессит сотни гигабайт критичных данных в сутки, реализует коммерческие расчеты с многоуровневыми агрегациями, и при всем при этом позволяет адаптировать бизнес-логику расчетов на лету, что мы и делали, зачастую прямо по ходу совещаний с заказчиком.
2) утверждение, что для разработки на low-code необязательно быть программистом - в корне неверно. Я скажу, что как раз наоборот. Архитектору, у которого в руках мощнейший инструмент, позволяющий собрать сложный функционал в одиночку за полдня, не нужны разработчики совсем, т.к. он соберет этот функционал сам. Поэтому хорошая команда для разработки на low-code - это команда универсальных людей, каждый из которых способен выполнять функции бизнес-аналитика, архитектора и разработчика одновременно. Назовите такого человека как хотите. Он с утра слушает бизнес-требования на совещании с заказчиком, к вечеру готова примерная архитектура, к вечеру следующего дня готов прототип, наутро обсуждение прототипа с заказчиком на предмет соответствия ожиданиям, затем две недели ожидания доступа к источникам, пару дней на отладку, и затем выкат в прод. Я реально работал именно так. Это очень интересно.
3) "в чем же смысл low-code, если для каждый разработчик должен быть архитектором?" - спросите вы. Смысл в следующем: проект в одном иностранном телекоме с сумасшедшими по сложности бизнес-требованиями наша команда из 4-5 человек реализовала за полтора года на low-code, причем оставила огромные возможности для дальнейшего развития функционала. После этого меня занесло в российский финсектор в классический проект разработки "с нуля" с бизнес-требованиями примерно в два раза проще, и на этом проекте только в самом его начале в чате сидело почти 40 человек (аналитики, архитекторы, разработчики, тестировщики, документалисты, менеджеры), проект был рассчитан, если не ошибаюсь, на 4 года с перспективами продления. Результат при этом прогнозировался слабокастомизируемый. Считайте сами.
4) Простота "квадратиков" и "стрелочек" не является препятствием. В хорошем low-code есть пара-тройка типов пустых "квадратиков", которые предлагают написать себя самостоятельно на нескольких доступных языках. "Сделай свой квадратик" - это тоже интересно и мощно.
4) Очень жаль, что подобных платформ пока не найти не то что в свободном доступе, но и за более-менее вменяемые деньги. Лицензия же в 50 тыс евро - не для всех. Я с надеждой присматриваюсь к каждой компании, заявившей себя как разработчик low-code платформы, и очень жду, что кто-то поверит в подобный подход, инвестирует в раработку и сможет реализовать low-code платформу, включающую (в идеале):
конструктор модели данных, отображаемой на несколько типов хранилищ - например, на MySQL, Postgres, Oracle, Hive
конструктор веб-интерфейсов
конструктор отчетов
ETL-инструмент с хотя бы минимальным набором возможностей интеграции с источниками
кейс-менеджмент
Нужна первая версия подобной системы, нужен вывод ее в Open Source, чтобы небольшие команды программистов могли быстро реализовывать средние по сложности проекты за небольшие деньги, накапливали экспертизу, нужно сделать такую платформу известным и зарекомендовавшим себя инструментом, который развивается и совершенствуется, и тогда вендор сможет зарабатывать хорошие деньги на реализации больших и сложных проектов силами небольшого числа специалистов.
Жаль, что этого не случится.
так все это есть, только чтобы собрать это в рабочий продукт, нужны все те же аналитики, разработчики, "devops" :)
Мне, как автору статьи, ваши тезисы откликаются. Особенно 2 и 3 пункты. Могу их подтвердить на своем опыте, как основатель лоу-код платформы. Все наши внедренцы вынужденно становятся комбайнами аналитик-архитектор-разработчик. И это позволяет им даже в одиночку делать серьезные проекты.
Я, может быть с неправильными или просто старыми системами дело имел, но .. С nо-code как только задача переходила определенный уровень сложности ты переставал решать задачу как таковую, и большую часть времени придумывал как бы «выразить это в танце». В итоге система обрастала тучей совершенно мерзкого вида костылей…
C low-code, в целом, было полегче - там обычно есть родной способ воткнуть код. В результате имеем по сути обычный фрейворк, в котором часть действий по созданию кода можно сделать с помощью ide.
Мне кажется это все не о том, чтобы начать программировать в течении недели не приходя в сознание. Можно долго рассуждать про сложности в программировании, но imho, это точно синтаксис языка и не проблема с тем, что надо много букв печатать.
no-code не то чтобы мертвая концепция, а что-то вроде зомби и полностью оживет только во времена сильного ИИ. А Low-code не более и не менее, чем фреймворк с мощным ide. Хороший ускорит разработку, но принципиально ничего не изменит.
Мда... Господа... Бред чистой воды!
Главный вопрос ЗАЧЕМ!??
Зачем рассуждать о теме, в которой не шарите?
Посмотрите такие инструменты как bubble, n8n, а не то что принято называть no code в России.
В России тоже много хороших продуктов. Более того, половина западных продуктов создана российскими основателями и командами.
Статья — взгляд на границы применимости лоукода от одного из известных учатников ит отрасли. Если вы работаете/связаны со сферой лоукода и имеете свою позицию, я готов провести интервью и с вами. Напишите в личку.
Почему low-code не помогает «хорошим людям»