Low code стремительно ворвался в корпоративный ландшафт, чего от него никто не ожидал. Мы думали — ну, да, занятная вещица, пусть пользователи поиграют в программистов, лишь бы работать не мешали. А сегодня куда ни глянь, все хотят, чтоб даже у серьезных энтерпрайз-решений обязательно были какие-то хотя бы элементы лоукода. Но зачем?

Хайп начался в 2021 году, когда Gartner написал: «К 2024 году 65% всех приложений будут созданы с использованием low-code технологий» — и это разлетелось по всем CIO-чатам.

Причина такого ажиотажа понятна: был ковид, нужно было срочно переводить всех на удаленку, у айтишников рук не хватало и дыры затыкали чем угодно. Эту задачу лоукод худо-бедно решал: быстренько что-то сваяли, запустили —и бизнес доволен. О том, что это придется поддерживать, развивать, совершенствовать никто не думал.

Однако, суета вокруг ковида давно прошла, а интерес к лоукоду по данным Google по-прежнему высок.

Это странно, потому что никак не коррелирует с реальным положением дел. Факты таковы, что к 2024 году только 15% предприятий используют платформы low-code для разработки критически важных приложений, признает тот же Gartner. Но тут же обещает, что уж к 2029 году этот показатель вырастет аж до 80%. Ага, верим! (См. здесь.)

Как я полюбил лоукод (и разлюбил)

Нет, я нисколько не против самой идеи лоукода, и действительно, есть кейсы, где этот подход работает. Вот, например, потоковое сканирование — четкий и понятный технологический процесс, который автоматизировать при помощи лоукода просто милое дело. Помните, была такая система — Kofax? — Практически идеальный инструмент для потокового сканирования. Там был жестко зашитый процесс: подготовка – сканирование – распознавание – валидация – верификация – генерация PDF – экспорт.

Все настраивалось визуально, а если возможностей не хватало, то можно было писать немножко кода на скриптовом языке а-ля VisualBasic. Однажды я продал эту штуку IKEA для перевода их бумажного финансового архива в электронный вид, сам настроил, а потом еще несколько лет поддерживал. Год на дворе был примерно 2006, тогда слов таких как «лоукод» никто и не знал. Но, по сути, это именно он и был. И все грабли лоукод-решений, на которые люди наступают сейчас, в этом небольшом проекте вполне проявились.

Началось с того, что бизнесу очень уж надоело перерывать тонны бумаги, чтоб найти счет или накладную пятилетней давности. Но у ИТ, как водится, ресурсов на проект не было. В общем, мы пошли по классическому партизанскому методу заноса лоукод в организацию —через потребность конкретного конечного заказчика, которому ИТ не могло или не хотело помочь. Как обычно бывает с лоукодом, первый успех пришел быстро —вжух — и заработало! А потом хлебнули всех типичных лоукодовских проблем полной ложкой.

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

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

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

Лоукод — лукавый термин

Маркетологи быстро уловили разрыв между желаниями бизнеса и возможностями ИТ. В 2014 году аналитики Forrester дали этому разрыву обтекаемое название — low-code — и пообещали, что теперь системы можно будет собирать без программистов. Бизнес поверил — и это сработало.

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

Low-code прячет сложность, но не устраняет её. Архитектура и поведение системы предопределены платформой. Простота достигается за счёт потери гибкости, а конфигурирование порой сложнее программирования. Как только задача выходит за пределы конструктора — начинается борьба с системой, а не создание приложения.

Однако на рынке произошло настоящее чудо — чудо переобувания на лету. Вчерашние вендоры СЭД, BPM и CRM-систем, языков 4GL вдруг осознали себя лоукодерами и на рынке вдруг обнаружилось несметное количество лоукод-платформ. Естественно, они не изменились внутри, всего лишь поменяли свои лозунги.

Прадедушки нынешних лоукодов

Технически low-code строится на тех же основах, что и инструменты прошлых десятилетий: визуальное моделирование, шаблоны, конфигурирование вместо программирования, декларативный подход. Всё это мы уже видели в RAD-платформах 90-х, 4GL-языках, визуальных конструкторах, ERP-системах, DSL-фреймворках. Даже в Excel с макросами есть черты low-code.

То есть, Low code — это не новая технология. Это новая упаковка старой идеи. Вот несколько примеров, чтобы не быть голословным:

VisualAge — это серия визуальных сред разработки от IBM из 1990-х, позволявших собирать приложения с помощью перетаскивания компонентов и генерации кода, задолго до появления современных low-code платформ. Особенно известна версия VisualAge for Java, ставшая основой для будущей Eclipse IDE. Хотя VisualAge опережал своё время идеей визуального программирования, он был слишком тяжёлым и ориентированным на разработчиков, чтобы стать по-настоящему массовым решением.

Visual Basic появился в 1991 году как инструмент быстрой разработки приложений (RAD) от компании Microsoft. Слово «Visual» в названии отражает ключевую особенность платформы — визуальное проектирование пользовательских интерфейсов с помощью перетаскивания элементов (кнопок, полей ввода, списков) прямо на форму, что значительно упрощало создание интерфейсов по сравнению с традиционным программированием. Несмотря на удобство визуального дизайна, Visual Basic не является low-code платформой в современном понимании, потому что для реализации бизнес-логики и взаимодействия с приложением всё равно требовалось писать код на языке Visual Basic.

PowerBuilder — один из ветеранов мира быстрой разработки бизнес-приложений, родился в начале 90-х в Sybase и долгое время был мечтой корпоративных разработчиков. Это был мощный визуальный конструктор форм с собственным скриптовым языком, который позволял создавать сложные клиент-серверные приложения гораздо быстрее, чем писать всё с нуля. PowerBuilder до сих пор жив и поддерживается, хотя в эпоху облаков и low-code платформ уже не на острие прогресса, но для многих организаций — это надёжный рабочий инструмент с богатой историей.

Как мы видим, история лоукода началась задолго до того, как появился сам термин. VisualAge, Visual Basic, PowerBuilder — все они по-своему стремились упростить разработку, спрятать рутину за визуальными инструментами и сократить время до готового продукта. Но у каждого из них был предел: как только дело доходило до нестандартных требований, разработчику всё равно приходилось «нырять под капот».

Нынешние лоукод-платформы унаследовали ту же двойственность: обещание простоты — и скрытую сложность, возвращающуюся на следующем уровне. Разница лишь в том, что теперь вокруг старой идеи выстроен современный маркетинговый фасад и целая методология цифровой трансформации. Новые термины, старые механизмы — и те же самые проблемы.

Что, если совсем без кода?

Вслед за low-code поднялась новая волна — no-code, как более радикальная версия той же идеи. По сути, это один и тот же подход, просто доведённый до предела: никакого кода вообще, даже намёка на программирование. Только мышка, готовые блоки, визуальный редактор и мечта о том, что теперь бизнес сам себе сделает всё, что нужно.

Идея выглядит красиво: любой сотрудник сможет собрать рабочее приложение, автоматизировать процесс, сделать небольшую CRM. Реальность же — как обычно. Пока задача простая и линейная — типа собрать лендинг в Tilda, сделать опрос в Typeform или настроить интеграцию в Zapier — всё работает. Но стоит бизнес-процессу выйти за рамки конструктора — и начинается квест: API не хватает, логики не хватает, валидации нет и так далее. А главное — нет понимания, как это действительно работает.

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

Low-code хотя бы честен: кода будет меньше, но он нужен. В no-code обещают, что не нужен вовсе. Только забывают уточнить, что не нужен до тех пор, пока вам не надо что-то настоящее: масштабируемость, контроль версий, тестирование, сложная логика, безопасность.

К счастью, на эту уловку бизнес не повелся и no-code не досталось места под корпоративным солнцем. Его удел —это коленочные решения, которые не претендуют на что-то серьезное. Собрать небольшой сайт, автоматизировать простенький процесс в малом бизнесе и всякое такое. В общем, про no-code можно забыть, если мы говорим о серьезных системах.

Парадокс Less Code

Думаю, не открою Америки, если скажу, что большинство разработчиков терпеть не могут лоукод и всё, что с ним связано. Это особенно забавно, ведь те же разработчики обожают инструменты, которые избавляют их от рутины и шаблонного кода, и охотно пользуются высокоуровневыми абстракциями, чтобы писать меньше кода вручную.

Впрочем, кода в больших проектах меньше не становится — ведь сложные вещи невозможно описать парой строк. Просто теперь разработчикам не нужно тратить время на однообразные задачи: библиотеки, умные IDE, фреймворки и, наконец, AI-ассистенты берут на себя всю рутину, позволяя сосредоточиться на действительно интересных задачах. Но о возможностях AI — в следующий раз.

Вот, например, Lombok — чем не лоукод? Несколько аннотаций вместо монотонного стучания по клавишам, когда нужно написать конструкторы, геттеры-сеттеры и прочую стандартную обвязку, но без которой ваш код просто не работает. Lombok экономит сотни строк и часы времени — и делает это на уровне языка, оставаясь прозрачным для разработчика. IntelliJ IDEA делает в принципе то же самое, позволяя эту обвязку сгенерить парой кликов — и это хорошо, у разработчика есть выбор.

А великий и ужасный Spring? Он действительно инкапсулирует сложность и забирает на себя контроль за управлением бинами, но взамен предлагает разработчику чёткие правила и богатый набор возможностей. Он говорит: «Я настрою за тебя окружение, подключу нужные компоненты, обеспечу транзакционность — просто опиши, что тебе нужно, а не как именно это должно работать».

Итак, современные инструменты делают все, чтобы разработчик меньше писал код и больше думал. То есть, именно их надо было по праву назвать low-code, но слово было уже занято. Пришлось как-то выкручиваться и придумали термин «Less Code», не столь прозрачный и звучный, но зато честный. Less code — это про экономию усилий без иллюзии, что код больше не нужен. Это про повышение уровня абстракции, автоматизацию рутинных действий и упор на выразительность. Разработчик по-прежнему пишет код, но делает это быстрее, чище и с помощью мощных инструментов: DSL, шаблонов, генераторов, аннотаций, умных IDE, так далее.

Фундаментальная разница между low-code и less code в том, что в первом случае вы действительно пишете немного кода, но все остальное — это для вас «черный ящик», это компоненты платформы, в которые нельзя заглянуть и что-то изменить; во втором случае — это все код, будь он написан вручную или сгенерирован какими-то инструментами. Даже сам фреймворк — это тоже код, который можно посмотреть и при необходимости модифицировать.

А потом просто компилируете и запускаете свое приложение, так же, как и «Hello, world!» В случае low-code приложение запускается в собственной runtime-среде, которую вы тоже не контролируете.

То есть, в отличие от low-code, less code не обещает, что любой сможет «собрать приложение за вечер». Он просто говорит: ты остаёшься программистом, но сэкономишь время на повторяемом. И это честная сделка — без обманчивых обещаний и без потери контроля.

Ирония в том, что настоящий прогресс разработки идёт именно по пути less code, а не low-code. Но рынок любит громкие названия, и low-code звучит более революционно. Хотя в реальности он скорее про смену упаковки, а не сути.

Заключение

Low-code — это не зло и не панацея. Это инструмент. Хороший — в нужных руках и при правильных ожиданиях. Проблема не в том, что он существует, а в том, что ему приписали слишком много: простоту, универсальность, скорость, самостоятельность, даже некую революционность. Но это все маркетинговые иллюзии:

1. Иллюзия простоты

Лоукод кажется простым — пока не выйдешь за рамки конструктора. Сложность не исчезает, она просто уходит в тень. Но она все равно вернется и мало не покажется. Да, лоукод снижает порог входа, это так. Однако, потом все равно придется погружаться с головой в какой-то проприетарный продукт.

2. Иллюзия "гражданских разработчиков"

Лоукод обещает, что справится любой — любой специалист может стать гражданским разработчиком . На деле — профессиональные разработчики всё равно приходят: позже, но по тревоге. Разбираться, чинить, переписывать. Теоретически можно наладить разделение труда между гражданскими и профессиональными разработчиками, но на практике такое встречается редко.

3. Иллюзия скорости

Лоукод уверяет, что все можно сделать быстро. Да, если сценарий типовой. Но в нестандартных задачах всё усложняется: конфигурации, ограничения платформы — всё это пожирает время. Думайте заранее о границах применимости лоукода, чтобы не завязнуть в проекте навечно.

4. Иллюзия низкой стоимости

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

5. Иллюзия универсальности

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

6. Иллюзия упрощения поддержки

Лоукод предлагает собственные инструменты развертывания и доставки приложений. Это классно, пока вам не требуется встроить все это в корпоративный конвейер DevOps — вот тут-то и начинается веселье. Зрелые платформы частично решают эту проблему — но цена интеграции с DevOps всё равно остаётся высокой.

7. Иллюзия революционности

Лоукод приходит как передовая технология. Однако, это старая идея под новым названием. RAD, 4GL, визуальные конструкторы — всё это уже было. Просто у лоукод маркетинг лучше.

Поэтому главный совет — не соблазняйтесь иллюзиями. Используйте low-code там, где он действительно уместен. А где нужна надёжность, масштаб и гибкость — лучше остаться на стороне профессиональных инструментов less code.

Подписывайтесь на наш телеграм-канал BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.