No-Code и Low-Code. Взгляд инженера и бизнесмена

По слухам, в мире набирает обороты движение No-Code и Low-Code, активно обсуждаются плюсы и минусы этих подходов. Иногда некоторые заявляют: «Будущее программирования — вовсе не кодинг». Давайте попробуем разобрать вопрос по-взрослому, как инженер и как бизнесмен.

Меня зовут Константин Митин, я сооснователь и руководитель компании itMegastar/itMegagroup. Когда-то был простым разработчиком, работал в L3, дорос до тим-лида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в itMegastar.

Давайте поймём суть явления. Не так давно начали массово развиваться онлайн платформы No-Code и Low-Code. Заявляется, что в качестве реакции на возрастающую сложность и многообразие средств разработки ПО. Целью ставится упрощение, автоматизация, частичный отказ от профессиональных разработчиков и расширение количества людей, которые могли бы создавать собственный продукт, при этом абсолютно не разбираясь в программировании. Разница между No-Code и Low-Code состоит в том, что в первом можно «вообще» не писать код, а во втором всё же придётся писать немного кода. #nbsp ;

Хорошо, избавиться от профессиональных разработчиков, с которыми постоянно какие-то проблемы и «Долго, дорого и не то».

Что на это нам ответит инженер?

Инженер скажет, что надо знать историю вопроса, которая тянется с 80-х и 90-х годов, посоветует прочитать Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы» и «Серебряной пули нет», которая вышла в 1986 году, там уже многое было сказано. Понятно, что читать лень, поэтому давайте на пальцах.

Стать профессиональным разработчиком и инженером — сложно. К этому нужно готовиться со школьной скамьи, получать сложное техническое образование, уделить хотя бы лет 10 своему профессиональному росту, работая на коммерческих проектах. Таких людей, честно говоря, на рынке не так уж и много.

А вот количество работы на рынке постоянно растёт, как и количество специалистов, занятых в сфере ИТ (будем их так называть). Из-за этого отрасль уже какое десятилетие ищет возможность выполнять разработку силами всё менее и менее квалифицированных специалистов, пусть даже и под надзором опытного наставника. Вы когда-нибудь задумывались, кто такие Solution Architect, что они делают, почему они появились и зачем нужны? Оно оттуда же, из решения этой проблемы.

Конечно, инженеры, которые занимаются автоматизацией, начинают автоматизировать свою же собственную работу. Разрабатываются готовые библиотеки решений, модульные подходы, компонентные сборки, виджеты и многое другое. Оно позволяет выполнять больший объём работы силами менее компетентных специалистов.

И визуальные среды программирования появились ещё в те времена, когда нынешние Solution Architect ещё в школе учились. Delphi, Visual C++, иные среды WYSIWYG (What You See Is What You Get, «что видишь, то и получишь») разработки, их было много на самом деле.

Когда мы сегодня говорим о No-Code и Low-Code, мы фактически говорим об онлайн платформах WYSIWYG разработки, но не только.

Очень быстро стало понятно, что профессиональных разработчиков мало, разработчиков с более низким классом в какой-то момент тоже стало не хватать, к разработке стали привлекать «не разработчиков».

Например, привлекли бизнес-аналитиков, написав им BPMN System. Инженеры сказали, вы же рисуете бизнес-процессы в BPMN? А давайте вы это будете делать в специальной среде, в которой мы ещё позволим писать простенькие условия, например на JS. И тебе хорошо, и у нас автоматически весь work flow разработается?

Если честно, то иногда инженеры заходят совсем далеко. Например, ещё в 0-х годах в консервативной корпоративной среде уже были действующие реализации подхода Composite Application. Пользователям давали обширный набор виджетов, объясняли, что с чем можно «забиндить» мышкой, и говорили, а теперь ты сам себе приложение собираешь.

Что после всех этих экспериментов стало с профессиональными разработчиками? Ничего не стало, как их было недостаточно, так и осталось, как работы было очень много, так и осталось. Почему так?

Например, вы делаете большой корпоративный портал со сквозным процессом через крупную корпорацию и их подрядчиков. При этом вы опираетесь на BPMNS Camunda, это тот самый Low-Code, который даёт много готового из коробки. Из чего состоит на самом деле ваша работа? Вам нужно выработать итоговые требования, развернуть вокруг этой самой Camunda обвязку из микросервисов, большая часть из которых будет интеграционной, встроить это все в архитектурный ландшафт конкретной корпорации, реализовать интеграцию с сервисами подрядчиков и очень много других важных вопросов, где нужно думать, а не писать код. Именно тех вопросов, которые может решить только профессиональный разработчик, а не кто-то другой.

Знаете ли вы, почему большинство разработчиков не владеют навыками слепой печати? Вслепую печатают только хакеры в фильмах. Все потому, что большую часть своей работы программист думает, непосредственно набор кода занимает 5%-15% общего времени. Навыки слепой печати не помогают разработчику работать ощутимо быстрее, он же не секретарь-референт.

На самом деле, в области профессиональной разработки обсуждать вопрос о плюсах и минусах No-Code и Low-Code уже не надо. Максимум, что появилось за последние 10 лет — появились SaaS онлайн-платформы. Ну, мы рады. Что-то ещё надо сказать?

Что нам скажет бизнесмен?

Помните слова о программистах про «Долго, дорого и не то»? Вот именно это беспокоит бизнесмена. И рассмотреть вопрос придётся с забытых «Программист за 1 год» и «Сайт за 5000».

Одним из самых массовых ИТ-продуктов являются сайты мелкого и среднего бизнеса. Именно они составляют большую часть web-разработки. Есть ещё интернет-магазины, но о них позже. А ещё разработка таких сайтов поддаётся стандартизации, автоматизации и конвейерной разработке, потому что, по сути, они ничем, кроме наполнения, не отличаются.

Работы было много, высокого профессионализма для её выполнения не требовалось, был дефицит кадров. Многие ВУЗы страны ответили на это программами профессиональной переподготовки типа «Стань web-дизайнером за 1 год». А профессиональное сообщество в это время совершенствовало свои инструменты, выпуская различные CMS (Content management system, система управления контентом). В итоге рынок дошёл до того, что сайт можно было сконфигурировать мышкой, дописать немного вёрстки и логики, после чего сайт был готов.

Логическим концом стало появление онлайн сервисов типа Tilda, позволяющих собрать свой сайт мышкой. Внезапно, ещё лет 20 назад во многом сходным образом сайт можно было сделать в Microsoft Word, если кто не знал.

Сайты стали делать не программисты, а дизайнеры. То есть те люди, которые несут ценность не как ИТ-специалисты, все ИТ оказалось автоматизировано. Это важно.

Нечто аналогичное сейчас происходит с интернет-магазинами и маркетплейсами. Есть готовые платформы, которые после некоторой кастомизации позволяют запустить свой интернет-магазин. Скорее всего, эту нишу займут не онлайн-сервисы типа Tilda, вместо этого придут экосистемы облачной автоматизации малого и среднего бизнеса, типа 1С, СБИС, Контур и других. У вас и так в облаке на стандартном функционале уже есть бухгалтерия, складской учёт и многое другое. Вам просто дадут галочку «Добавить интернет магазин?», «Добавить интеграцию с Wildberries/Ozon?».

"Программист за 1 год"?

Помните про «Программистов за 1 год», кто-нибудь может ответить, а что стало со всеми этими людьми? Как много из них осталось в профессии? Если честно, то очень мало.

Аналогично будет и с «программистами» со Skillbox, SkillFactory и других онлайн-школ. Если бы профессиональным разработчиком можно было бы любому стать за полгода-год, то не было бы такого их дефицита на рынке, и не стоили бы они таких безумных денег.

Поэтому, тем людям, которые сейчас обращаются в онлайн-школы с целью пройти профессиональную переподготовку чтобы «Войти в ИТ», нужно обратить внимание на навыки создания ценности для бизнеса, не связанные непосредственно с написанием кода.

Сейчас появилось много онлайн-сервисов No-Code и Low-Code, например, конструктор приложений Adalo и Airtable (базы данных и таблицы). Вы можете, не являясь программистом, создавать своими руками несложные мобильные приложения.

И знаете что? На рынке большинство мобильных приложений (кроме игровой индустрии) — простые. Их разработка это не «rocket science». No-Code и Low-Code могут покрыть ощутимую долю этого рынка.

Абсолютно неверно воспринимать No-Code и Low-Code платформы, как инструмент разработчика. Это инструмент бизнесмена, который делает своими руками MVP для стартапа, либо для автоматизации чего-то в своём бизнесе. Это инструмент бизнес-аналитика и руководителя проекта, которые могут своими руками создать интерактивный прототип приложения для получения пользовательского опыта и обсуждения с заказчиком. Это инструмент бизнес-аналитика в крупных компаниях, который может в интерактивном режиме создать и отладить сложную схему бизнес-процессов.

Не стоит обсуждать преимущества No-Code и Low-Code перед другими средствами разработки. Да, есть ограничения, большие ограничения. Да, есть интерактивный режим сборки приложения, который позволяет собрать и менять что-то простое очень быстро.

Но No-Code и Low-Code это вообще не про разработчиков и не для разработчиков. Это инструменты для всех тех, кто несёт свою ценность бизнесу, не связанную с написанием программного кода.

Да, бывают сложные приложения и системы, но No-Code и Low-Code позволят позвать программистов не с самого начала, а с середины, либо с конца проекта, дав им в руки работающий прототип и сказав: «Нужно сделать лучше».

Если вы программист, который собирается специализироваться на No-Code и Low-Code, то лучше не стоит. В этой области вы должны уметь нести ценность бизнесу как-то иначе, чем написанием программного кода.

0
35 комментариев
Написать комментарий...
Вагайцев Михаил

Мне кажется, что No-Code и Low-Code нужен для создания фастфуд-приложений и сервисов, чтобы быстро и дешево на коленке протестить какую-нибудь гипотезу, после чего отдать ее в полноценную разработку

Ответить
Развернуть ветку
fffggg gggfff

типа того. если у вас нет команды и хочется потестить гипотезы не сложнее лэндоса с парой формочек. на большее это не способно.

Ответить
Развернуть ветку
Константин Митин
Автор

Не совсем так. В нашей практике получалось делать мобильные приложения с относительно сложной логикой на Adalo. Делал не программист, кстати. И это были вполне полноценные и рабочие варианты. Конечно, собирается это только из стандартных блоков, визуально выглядит топорно, расширять функционал не получится, но иногда именно этого и хватает.

Поэтому мы и говорим, что это инструмент не для разработчиков, а для тех, кому нужно простое, быстро и без разработчиков. Мелкому бизнесу, стартапам, BA, UI/UX и другим.

Ответить
Развернуть ветку
Oleg Sotnikov

Не весь no-code одинаковый. Мы в AppMaster например генерируем приложения используя языки высокого уровня - Go, JS (Vue3), Swift и Kotlin. Кодогенерация позволяет на выходе получить производительные компилируемые приложения, при этом это уже не уровень MVP. Можно масштабироваться достаточно долго и не факт что когда-нибудь придется переписывать приложения вручную.

Ответить
Развернуть ветку
Константин Митин
Автор

Смотрите, никто не говорит о том, что приложение на No-Code будут работать медленно. Но они всегда будут иметь ограничения, которую задаст платформа. Это стандартные блоки, способы связи для них и прочие. Именно это будет ограничивать потенциал развития функционала.

Да, вы можете дать возможность кастомизации, просто в какой-то момент развития окажется, что кастомизировать дороже, чем писать на нативном языке.

При этом не ограничивать пользователя вы не сможете. У вас все равно есть какая-то целевая аудитория, с какими-то понятными классами задач, которые в целом решаются одинаково. Плюс стремление оградить пользователя от ошибок, сделать систему удобнее. Именно это в итоге и задаёт систему ограничений.

Конечно, если пользователю не нужно приложение с развитым и нестандартными функционалом, то ему должно хватить ваших стандартных средств. И приложение не нужно будет переписывать.
Скажем честно, разрабатывать что-то сложное и нетривиальное приходится не часто. Вы просто можете исключить людей с такими потребностями из своей целевой аудитории, так часто и поступают. Вы же не ставите себе цель захватить 100% рынка разработки?

Ответить
Развернуть ветку
Oleg Sotnikov

Да, очевидно, что 100% кейсов нельзя покрыть одним инструментом. Даже используя один язык или стэк технологий не получится этого сделать. Верно и про компромис специализации: либо в сторону гибкости уходить, либо в сторону упрощений и прятать функционал. После года работы мы начали фокусироваться на профессиональных разработчиках и больше не смотрим в масс-маркет потому, что платформа становится сложной для неподготовленных пользователей.

Ответить
Развернуть ветку
Константин Митин
Автор

В своё время, как компания в области заказной разработки, мы смотрели в сторону No-Code и Low-Code, и рассматривали вопрос о включении в свой состав студии разработки на No-Code. Идея оказалась не очень удачной, почему так, мы написали здесь: https://habr.com/ru/post/666396/

Это не значит, что идея плохая, скорее это о том, что оно не всем подходит. Например, фрилансеры могут начать активно производить на вашей платформе, а вы можете создать их сообщество и дать заказчикам доступ к нему. То есть сформировать и потребность, и потребителей. Есть компании с конвейерной разработкой программного обеспечения, а вы по своей сути делаете конвейеры разработки.

Это как роботизированные конвейерные линии по производству автомобилей. Автозавод покупает такую линию, настраивает её и производит определённую модель автомобиля. Потом линия перенастраивается, производится другая модель автомобиля.

И, конечно, разработать конвейер, произвести конвейер, модернизировать конвейер, это совсем другая задача и история.

Ответить
Развернуть ветку
Alexander
Кодогенерация позволяет на выходе получить производительные компилируемые приложения

А как только в сгенерированный код ручками залезли, генераторы уже неприменимы? Дальше только хардкодинг? Или как это работает?

Ответить
Развернуть ветку
Oleg Sotnikov

Сгенерированный код только для спокойствия заказчика, сертификации или ухода с платформы. Во всех остальных случаях при каждом изменении мы генерируем приложения с нуля, оставляя только миграции для реляционной СУБД.

Ответить
Развернуть ветку
Bob Brown

Один из вариантов - embed points (точки вставки кастомного кода).
Этот вариант будет работать если кодогенератор написан на языке шаблонов.

Ответить
Развернуть ветку
Alexander

Константин, как тогда на ваш взгляд объяснить ситуацию, что low-code платформы прочно поселились, например, в таких решениях как кредитные конвейеры, комплаенс-процессы и многих другие банковских системах, которые в общем и целом являются наверное одними из самых сложных классов информационных-систем, требующих максимально квалифицированных инженеров и архитекторов?

Это вопрос без подвоха, интересно ваше мнение. Я сам много лет посвятил BPMS и как инженер и как предприниматель.

Ответить
Развернуть ветку
Константин Митин
Автор

Что такое No-Code и Low-Code? Это какие-то готовые блоки, которые нужно правильно расположить и связать между собой. Если вы работаете в зарегулированной области, где функционал в целом стандартный, нужно просто верно описать правила движения чего-либо по процессу, то вполне логично применение No-Code и Low-Code. Тогда, систему разворачивать будет не разработчик, а другой человек, пусть даже он прошёл дополнительное обучение. То есть шаблонные и рутинные задачи отдаются от разработчика другим специалистам, бизнес сокращает издержки, может развиваться и генерировать новые задачи для разработчиков.

Хорошим примером является 1С. Разработать с нуля бухгалтерскую систему — нетривиальная задача. А вот взять готовую конфигурацию 1С и немного настроить её под конкретное предприятие — уже проще. При этом мы понимаем, что те разработчики, которые разрабатывают платформу 1С, очень сильно отличаются от тех разработчиков, которые конфигурируют решения на 1С. В финансовой сфере — аналогично.

Ещё пример. Написать свою BPMS — это сложно и долго. Сконфигурировать нужные процессы в уже готовой BPMS — уже проще.

Смысл в том, что максимально квалифицированные инженеры и архитекторы работают один раз, а потом поддержка и развитие могут осуществляться менее квалифицированными и дорогими кадрами.

Ответить
Развернуть ветку
Alexander

Так-то вроде все верно, но те ребята которые конфигурируют BPMS стоят подчас дороже ведущих разработчиков.
А система получается с кучей черных ящиков внутри платформы, и появляется третья сторона - производитель платформы (вендор) который какбэ не участвует в проекте в конкретном заказчике но профессионализм его команды влияет на результат напрямую, т.е. зона ответственности нечеткая. Команда внедрения часто ссылается на вендора, мол это такая BPMS корявая, а вендор отвечает - это у вас руки кривые. А страдает заказчик.
Я участвовал в таких проектах. Не могу сказать что всё прям круто. Да, существенно более быстрый старт. Да один известный банк несколько лет назад порвал рынок тем что первым стал открывать счета юрикам не за 3 дня а за полчаса. А потом и кредитный конвеер ускорил процессы с нескольких дней до пары часов. Но поддержка, развитие, масштабирование всей этой машинерии крайне сильно зависит как от квалификации тех кто эту BPMS настраивает так и от вендора.

Если вы работаете в зарегулированной области, где функционал в целом стандартный

внутренние процессы банков - их конкурентное преимущество и очень охраняемая коммерческая тайна. Регулирование ЦБ там только по самым верхам.
По бухгалтерии в общем то же самое - в крупном бизнесе это во многом уникальные процессы

Ответить
Развернуть ветку
Константин Митин
Автор

Давайте попробуем разобраться, но придётся сразу выйти за ограничение темы No-Code и Low-Code.

Чем хорош пример с бухгалтерией? Он даёт понимание, что сильно уникальных процессов там нет и быть не может. Сам по себе бухгалтерский учёт — сложная и ресурсоёмкая тема, причём с жёсткими правилами и штрафами от налоговой.
Теперь представьте что правила в нём меняются раз в квартал-полгода, после чего платформы бухучёта начинают судорожно переписываться, а их пользователи начинают молиться, чтобы они успели к периоду сдачи отчётности.
В реальности поддержка «уникального процесса» в бухгалтерии будет стоить очень дорого, не важно, на платформе либо самописной системе. Но платформа возьмёт на себя затраты по адаптации под меняющиеся правила и законы.

Скорее всего, вы имели в виду область типа «управленческого учёта», которая не то чтобы не регламентированная. Не всегда удаётся с людьми договориться об общем для всех сторон содержании термина «управленческий учёт», очень по разному его понимают.

Касательно BPMS. У нас есть опыт реализации тендерной площадки с самописным work flow, есть опыт реализации и внедрения портала на базе BPMS (Camunda) в большой корпорации. Можно посмотреть на вопрос в разрезе этого опыта.

Первое, что можно отметить, BPMS очень заметно сократила затраты на разработчика. Там много чего уже готово и работает. Есть админка, есть средства мониторинга, есть возможность отладки, схемы процессов рисуются прямо в BPMN. Круто.

Второе, специалисты по Camunda. Изначально они были не из нашей компании. И с этим были реальные проблемы. Нам нужно было спроектировать архитектуру портала, необходимо было определиться где и как хранить данные. Логично было делать это в Camunda, но вот нормального контакта с разработчиками на Camunda не получилось.
Как результат. BPMN — это не какое-то тайное знание, в сети много материалов на эту тему, можно разобраться самостоятельно. Внутреннее устройство Camunda и его API тоже никто не скрывает, есть официальная документация. Недели через 2 стало понятно, что квалификация разработчиков на Camunda просто нулевая. Ещё через неделю разрабатывать на Camunda смог наш разработчик, который увидел её в первый раз, и которому я указал на конкретные места, которые ему следует изучить и где взять материал.

Нельзя не сказать о том, что с Camunda бывают проблемы. Это open source продукт, в котором после обновления может внезапно отвалится какой-то функционал. Иногда приходилось разбираться, почему у одного что-то работает, а у другого — нет. О ситуации рассказали нашим devops, они осознали, что везде, включая продуктив, должна стоять конкретная сборка, в которой мы уверены.

Ну и третье. Основные затраты пришлись не на BPMS и разработчиков. Мы внедряли новый ИТ-инструмент, который менял бизнес-процессы в компании, а это всегда кромешный ад. До нас было несколько неудачных попыток внедрения, не из-за того, что программисты не смогли, из-за того что все остальные не смогли.
Приходилось помогать «бизнес-аналитику» (политический вес у человека был много выше) заказчика собирать и систематизировать требования от всех заинтересованных сторон. Приходилось прорабатывать архитектурный ландшафт и иметь дело с кучкой сторонних систем, которые даже не знали о существовании друг друга. Представьте себе руководителе ИТ-отдела, который на встрече говорит: «О, у нас в компании и такое есть?...». Хотя ещё хуже, там была целая иерархия архитекторов, которые тоже между собой не были знакомы. Причём, проект разрабатывался и внедрялся года два, а компания вокруг быстро менялась.

Отсюда и родилась объёмная система из ряда интеграционных сервисов, сервисов-адаптеров, своих баз данных, web-морды и Camunda. В Camunda остались только процессы в BPMN, ряд переменных-параметров для условий на шлюзах и обратные вызовы API сервиса-адаптера (это немного не каноничное использование Camunda).

Нельзя сказать, что тут что-то сильно зависело от уровня квалификации программистов, которые работали с Camunda. Скорее от квалификации бизнес-аналитика, системного-аналитика, руководителя проекта и архитектора. Без них даже готовое решение внедрить очень сложно. Вот когда они плотно и успешно поработают, может начаться круто и просто.

No-Code, Low-Code, BPMS и прочие на самом деле не обещают вам быстрого и лёгкого достижения результата. Они говорят вам, что нужно построить фабрику готовых и стандартных решений, которые будет легко и просто настраивать.
Пользоваться готовой и налаженной фабрикой — просто. Построить фабрику и модернизировать фабрику — та ещё задача.

Ответить
Развернуть ветку
Alexander

Спасибо за подробности. Если обобщить, как ни крути, а вытащить сложные проекты можно только исключительно высококвалифицированными замотивированными кадрами. Технологии тоже очень важны, но всё же люди важнее

Ответить
Развернуть ветку
Alex Kluev

как говаривал один классик "Кадры решают всё" :)

Ответить
Развернуть ветку
Alex Gusev

Возможно потому, что у финансового сектора есть деньги на вот это вот всё:

"Вам нужно выработать итоговые требования, развернуть вокруг этой самой Camunda обвязку из микросервисов, большая часть из которых будет интеграционной, встроить это все в архитектурный ландшафт конкретной корпорации, реализовать интеграцию с сервисами подрядчиков и очень много других важных вопросов, где нужно думать, а не писать код."

После того, как "грядки вскопаны", можно и low-кодить. Я с BPMS работал не очень плотно (1 год, Intalio BPMS, лет 10 назад), поэтому это всего лишь моё предположение. Внутри "песочницы" можно делать очень гибко, но интегрировать "песочницу" в окружающий мир - это больно.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Херня Всё

Сколько-то десятилетий назад полагаю говорили, что высокопроизводительный высоконагруженный сервис без ассемблера не создать..

А сейчас как-то вроде справляются на более высокоуровневых языках. Причем скорее всего лучше, чем средний ассемлерист, если бы такие сейчас были.

Почему low-code не может со временем заменить кодеров с эксклюзивным знанием клингонского? Да, low-code выпускник скиллбокса не потянет нормально - но бизнес аналитики или системные аналитики вполне..

Ответить
Развернуть ветку
Shoo

Тут всё довольно просто, на самом деле.
Основная разница между языками высокого уровня и языками низкого - не в том, что первые "проще".
Асемблер гораздо более примитивен, нежели, например, плюсы.
За счёт низкого уровня ты работаешь с меньшим количеством абстракций и сущностей.
Это даёт прирост в скорости и "прямом" контроле, минус - в гибкости, читаемости и расширяемости - с этим кодом сложнее работать.

Разница между лоу-код решениями и языками программирования высокого уровня - немножко другая.
Лоу-код пытается "упростить" программирование через уменьшение количества абстракций.
Вот тебе набор блоков, собирай их как хочешь.
Это можно сравнить с ситуацией, когда взявшись использовать какой-то из фреймворков ты можешь использовать только его, без возможности расширения.

Если же предположить, что когда-то появляется лоу-код решение, дающее ту же степень гибкости и расширяемости, что бы конкурировать с языками программирования, то мы получим "конструктор" аналогичный (или превосходящий) по сложности, с единственной разницей что вместо лексических конструкций (клингонский) ты будешь оперировать графическими (можно сравнить это с иероглифами).
Станет ли от этого порог вхождения ниже? Нифига не станет.
Просто вместо изучения клингонского придется изучать мандаринский.

Ответить
Развернуть ветку
Павел Шабалин

Мне понравился конструктор сценариев в Oktell (сервер телефонии). Собираешь все квадратиками, что не Low-code? Там есть свой язык выражений, есть компоненты где можно пилить запросы SQL в MSSQL, можно даже свои квадратики на c# пилить. Только стоимость такого специалиста выше стоимости рядового программиста, и даже выше тех ребят кто делает все тоже самое на астере без всяких квадратиков. Гибкий low-code сложнее в освоении, это по сути фреймворк, а очень многие программисты так и не смогли освоить их и ходят топят за разработку с нуля. Так что чем гибче будет low-code тем он будет сложнее, так как code приставку никто не убирает =))

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Anfer

Ну почему же. Вопрос в размере квадратика. Мы двигаем мелкими, классами, функциями. Юзер побольше))

Ответить
Развернуть ветку
Константин Митин
Автор

Конечно, в целом вы правы. С другой стороны, такие прецеденты уже были. Например, платформа Lotus Notes/Domino является примером взрослой low-code платформы. В ней очень многое делалось в формате WYSIWYG и просто мышкой.
Именно на этой платформе в корпоративной среде создавались кастомные геораспределенные высоконагруженные системы. Очень многое работало из коробки, причём сразу хорошо.

Правда работать со всем этим могли только высококвалифицированные разработчики. Но это другая история.

No-Code и Low-Code это не замена обычной разработке. Это возможность заказчику понять, чего он хочет, до того как он пришел к «программистам».

Ответить
Развернуть ветку
arlekit

1) Переносим сервис в облако.
2) Готово.

Ответить
Развернуть ветку
Павел Шабалин

Материал для вставки рекламной ссылки, больше никакой пользы не несет

Ответить
Развернуть ветку
Denis Mokhin

А теперь берем low-code платформу, добавляем к ней copilot от MS или GitHub, смешиваем с GPT-3 и какой-нибудь Яндекс.Алисой и сказка становится былью. Достаточно сказать: "Алиса, сделай мне приложение с большой красной кнопкой. Нажимаешь на нее и мой банковский счет пополняется на хреналион долларов"... Прям, горшочек-вари.

Ответить
Развернуть ветку
Valentin Budaev
добавляем к ней copilot от MS

copilot и подобные вещи для таких задач не предназначены

Ответить
Развернуть ветку
Denis Mokhin

да... забыл закрыть тег </joke>
Но в целом, я имел в виду такое поведение: ты озвучиваешь цель разработки, вид приложения, машина это распознает, второй пилот (или даже первый) пишет код. Тем более, что UI из речи создать уже делались попытки.

Ответить
Развернуть ветку
Valentin Budaev
Не так давно начали массово развиваться онлайн платформы No-Code и Low-Code

Нифига себе, 30 с гаком лет назад - это не так давно?)

Ответить
Развернуть ветку
Константин Митин
Автор

Если мы говорим про онлайн платформы, то не так уж и давно.
Если про сам подход, то это уже археологические исследования. Там может быть и более 30 лет назад. )

Ответить
Развернуть ветку
Сергей Сарафанов, low-code

Не пишите того, чего не знаете. Не путайте других. Не следует сворачивать с прямой дороги в закоулок. Лучшее, что получает пользователь (разработчик) от работы с Low-code, это наслаждение от быстрого результата безо всякого тестирования и прочей муры. Можно в одиночку создавать гигантские проекты. А если программировать, то только начисто. Не умеете - не беритесь. Лучше прочитайте: на vc.ru статью "Возможности Loginom на границе применимости Excel".

Ответить
Развернуть ветку
Константин Митин
Автор

Ну как это не знаю? Наоборот, хорошо знаю и понимаю. Для меня, то что сейчас происходит с NoCode и LowCode - это далеко не первая, а просто очередная итерация одного и того же процесса.
Кроме того, я видел, что в финансовой организации могут выполнять на Excel, используя те же самые макросы, и не упираясь в объемы данных. Да, Excel не предназначен для совместной работы, поэтому на нем можно сделать не все. Не будь этого ограничения, миру бы явились поистине ужасные чудовища на Excel, все же потенциал в него заложен неплохой.
Но вот смысла заменять Excel на что-то Excel-подобное я не вижу. Можно взять Аиртейбл либо какую-нибудь из BI-систем.
Кроме этого, я же еще сложные системы разрабатывал. Поэтому хорошо понимаю удельную мощность подходов NoCode и LowCode. Для рынка это все не новость уже давным давно.

Ответить
Развернуть ветку
Лысенко Андрей

LC и NC это вполне нормальные инструменты для декларативного описания фронта и прочего UI. Лет так через 10 фронты будут делать дизайнеры или бизнес-аналитики, а может и Искины по тексту эскиз смогут делать ... и загнется Figma за ненадобностью )

Ответить
Развернуть ветку
Константин Митин
Автор

Вряд ли. Такие инструменты существуют уже не первое десятилетие, а фронт все еще приходится писать руками. Местами разработка фронтенда становится ощутимее сложнее разработки бэкенда. Разработка чего-то маленького и стандартного - возможно, серьезного - точно нет.

Плюс другой момент, о которому почему-то мало кто задумывается. Алгоритмическое описание поведения системы на машинном языке куда короче аналогичного описания на человеческом языке. Чуда все равно не произойдет.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
32 комментария
Раскрывать всегда