Привет, Хабр! Меня зовут Георгий Ржавин, работаю процессным архитектором в компании GlowByte, руковожу направлением Business Process Management. В этой статье хотел бы с вами подискутировать о вечном противостоянии подходов High Code и Low Code: где сейчас находимся и кто выигрывает. Но перед тем, как мы перейдем к основной дискуссии, сразу оговорюсь, что текущее сражение я буду рассматривать применительно к сфере автоматизации процессов, в которой сам работаю и в вопросах которой немного разбираюсь.

Термины

Под High code-автоматизацией процессов мы будем подразумевать проекты, где 80% работы закрывают разработчики, а 20% остаются аналитикам.

Соответственно, Low Code-автоматизацией будем называть обратную ситуацию: 80% работ закрывают аналитики, а для 20% приглашаются разработчики. Чаще всего в таких проектах сейчас используют системы класса BPMS (Business Process Management Suite).

“Качели”

В целом рынок то и дело качает из стороны в сторону. Где-то 5 лет назад на любой конференции по автоматизации можно было услышать следующие высказывания:

• Верите ли вы в Low Code?

• Аналитики не могут автоматизировать процессы.

Сейчас с этим проблем нет. Более того, появились конференции, где в целом рассматриваются только Low Code-инструменты и проекты. Безусловно, есть объективные причины таких изменений. Во-первых, все больше и больше компаний не в теории, а на практике попробовали Low Code-инструменты. Во-вторых, самих инструментов стало намного больше. При этом часть из них очень далеко продвинулась в части “лоукодистости” (все больше и больше задач может закрыть аналитик без привлечения разработчика).

Но теперь, как мне кажется, “качели улетели” в противоположную сторону. Бытует мнение, что альтернативой Low Code-автоматизации является что-то сложное, дорогое и обязательно с армией разработчиков. Если у вас такой армии нет и вы не готовы ее нанять, то вход в High Code-проекты для вас закрыт. Хотя это не так: последние 10 лет параллельно с Low Code развивалась и разработка. Давайте посмотрим, что там произошло.

Продуктивность разработки

Проблемы, связанные с продуктивностью разработки, поднимались с самого начала зарождения индустрии по созданию программного обеспечения. Одной из самых интересных и известных работ в этом направлении является всем известная книга “Мифический человеко-месяц” Фредерика Брукса Мл.

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

Не буду пересказывать книгу, т. к. это не цель нашей статьи. Давайте возьмем несколько тезисов касательно увеличения продуктивности разработки, которые выделил Брукс:

1. Языки высокого уровня. Мало кто сейчас пишет софт на Ассемблере, кроме каких-то специфичных задач. Любой код – это определенный уровень абстракции над Ассемблером (если мы имеем в виду компилируемый язык) либо набор команд для некой виртуальной машины (если речь про интерпретируемый язык). Единственными минусами применения языков высокого уровня называли объем кода и скорость компиляции, но на сегодняшний день обе задачи решены за счет развития “железной составляющей”: никто, к счастью или к сожалению, уже не переживает особо сильно об объеме кода.

2. Интерактивное программирование. Здесь речь про использование IDE (Integrated Development Environment) в современной разработке. Кроме редактора кода, здесь есть компилятор, отладчик и различные инструменты для автоматизации сборки кода. Цель здесь одна – ускорить процесс разработки на разных этапах.

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

Open Source

А вот это явление пропустил Брукс (может, конечно, не пропустил, но я в его книге упоминания об этом напрямую не встретил) и игнорируют те, которые утверждают, что автоматизация в рамках High Code – это всегда дорого и долго. Давайте разбираться.

Сам подход родился почти одновременно с коммерческой разработкой. Еще в марте 1985 года Ричард Столлман, сотрудник Лаборатории искусственного интеллекта, опубликовал свой манифест, где сформулировал “золотое правило”: каждый должен делиться понравившейся программой с теми, кому она тоже нравится. При этом Ричард сразу сделал акцент, что речь не про бесплатное ПО, а про свободы. Вот его цитата на этот счет: “У каждого должно было быть право пользоваться программами, изучать, изменять и распространять любую их версию… дело не в стоимости, а в дозволенности: имеется в виду, например, свобода слова, а не бесплатное пиво”. Он же является автором универсальной общедоступной лицензии GNU – General Public License.

Ну и, конечно, у истоков стоял всем известный Линус Торвальдс – в то время 21-летний студент Университета Хельсинки. О его детище Linux теперь знают все ИТ-специалисты.

С тех самых давних пор open source не просто живее всех живых, но и вовсю цветет и пахнет. Дошло уже до того, что большие коммерческие компании отказываются от написания и поддержки собственного коммерческого софта в пользу создания дополнительных плюшек над open source`ом. Т. е. вы можете самостоятельно собрать похожее ПО, но при обращении в компанию вся сборка будет максимально автоматизирована.

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

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

Разберем это явление на примере двух языков JavaScript и Python.

Фреймворки над фреймворками

Современный фронтенд уже никто не пишет на чистом JavaScript, HTML и CSS. Для этих целей используют некую абстракцию над ними (да простят меня разработчики этих библиотек и фреймворков). Самые известные из них – React, Vue и Angular. Добавляем сюда фреймворки UI-компонент – и разработчик не пишет 10, а то и 100 строчек кода, он лишь добавляет тег <btn> и настраивает его. На выходе на форму добавляется красивая кнопка с кучей нужного функционала. Вот этот тег я и называю абстракцией над JavaScript, HTML, CSS.

Но на этом рынок не остановился. В настоящее время нам доступны абстракции над абстракциями, которые позволяют писать еще меньше кода. Речь про Next для React и Nuxt для Vue. Авторы этих фреймворков автоматизировали еще больше стандартной рутины, которую ранее фронтенд-разработчик был вынужден повторять из проекта в проект. А это значит, что на выходе мы имеем еще меньше кода и еще больше преимуществ в скорости разработки.

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

За счет этого современная разработка разительно отличается от того, что было еще 10 лет назад. Теперь все быстрее и эффективнее.

Вместо выводов

Итого, если сравнить в лоб High Code-автоматизацию с Low Code-автоматизацией и разбить на стандартные этапы, вот что мы имеем на сегодня:

1. Реализация модели процесса и бизнес-правил. Здесь оба подхода идут бровь в бровь, т. к. в обоих случаях есть возможность создать модель процесса в нотации BPMN 2.0 и передать ее на исполнение (без кодирования) либо BPMS, либо BPM-движку.

2. Модель данных. Здесь я бы то же не давал пальму первенства ни одному из подходов, т. к. в одном случае аналитик мышкует модель данных в BPMS, а во втором подходе разработчик создает такой же плоский список, используя технологию ORM (object-relational mapping). Другими словами, в зависимости от подхода меняется специалист, но скорости у обоих похожие.

3. Интерфейсы пользователя. В случае Low Code аналитик в конструкторе форм мышкует интерфейс, а в случае High Code-автоматизации обычно подключается фронт-разработчик и дизайнер. Скорость на стороне Low Code, но есть и плата за это: пока вы работаете в рамках предоставленного конструктора, все хорошо, но, как только вам необходимо выйти за его пределы, трудозатраты возрастают кратно. При этом в случае High Code-разработки не все так страшно, как это было 10 лет назад: при использовании различных фреймворков трудозатраты на разработку значительно сокращаются.

4. Интеграции с другими системами. Аналогично с предыдущим пунктом. Low Code-инструменты уже зашли в эту сферу, и на сегодняшний день аналитик действительно получил возможность мышковать различные интеграции: например, самостоятельно прикрепить к процессу сервис по отправке SMS-сообщений. Но и классическая разработка не отстает. В свое время, примерно 2 года назад, я записал ролик “Как создать веб-сервис за 15 минут”. Недавно, закрывая похожую задачу, я увидел, что этот же сервис теперь можно создать минут за 5, используя более современные библиотеки Python (речь про FastAPI). При этом на выходе будем иметь сервис с большим функционалом, чем ранее.

Резюмируя, фактически на 2023 год победителя пока нет. И любое декларирование, что “теперь только так и все” является перегибом. От себя посоветовал бы всегда на равных рассматривать оба метода и, добавляя ваш уникальный контекст (кто будет автоматизировать, что будете автоматизировать, какой стек предпочтительней и т. д.), выбирать тот или иной подход, а на следующем этапе – и инструмент (набор инструментов).