Вечная битва High Code и Low Code
Привет, Хабр! Меня зовут Георгий Ржавин, работаю процессным архитектором в компании 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-автоматизации является что-то сложное, дорогое и обязательно с армией разработчиков. Если у вас такой армии нет и вы не готовы ее нанять, то вход в High Code-проекты для вас закрыт. Хотя это не так: последние 10 лет параллельно с Low Code развивалась и разработка. Давайте посмотрим, что там произошло.
Продуктивность разработки
Проблемы, связанные с продуктивностью разработки, поднимались с самого начала зарождения индустрии по созданию программного обеспечения. Одной из самых интересных и известных работ в этом направлении является всем известная книга «Мифический человеко-месяц» Фредерика Брукса Мл.
«Мифический человеко-месяц» Фредерика Брукса Мл.
Первое издание вышло аж 45 лет назад, но оно по-прежнему актуально, к тому же вышли переиздания, где есть анализ и опровержение ряда гипотез, которые заложил автор в своей первоначальной книге.
Не буду пересказывать книгу, т. к. это не цель нашей статьи. Давайте возьмем несколько тезисов касательно увеличения продуктивности разработки, которые выделил Брукс:
Языки высокого уровня. Мало кто сейчас пишет софт на Ассемблере, кроме каких-то специфичных задач. Любой код — это определенный уровень абстракции над Ассемблером (если мы имеем в виду компилируемый язык) либо набор команд для некой виртуальной машины (если речь про интерпретируемый язык). Единственными минусами применения языков высокого уровня называли объем кода и скорость компиляции, но на сегодняшний день обе задачи решены за счет развития «железной составляющей»: никто, к счастью или к сожалению, уже не переживает особо сильно об объеме кода.
Интерактивное программирование. Здесь речь про использование IDE (Integrated Development Environment) в современной разработке. Кроме редактора кода, здесь есть компилятор, отладчик и различные инструменты для автоматизации сборки кода. Цель здесь одна — ускорить процесс разработки на разных этапах.
Безусловно, существуют и другие инструменты и подходы, которые повлияли на скорость разработки, но Брукс в своей работе выделил именно эти два. Но, как мне кажется, сейчас мы переживаем еще одну трансформацию, которая значительно влияет на скорость разработки. Об этом далее.
Open Source
А вот это явление пропустил Брукс (может, конечно, не пропустил, но я в его книге упоминания об этом напрямую не встретил) и игнорируют те, которые утверждают, что автоматизация в рамках High Code — это всегда дорого и долго. Давайте разбираться.
Сам подход родился почти одновременно с коммерческой разработкой. Еще в марте 1985 года Ричард Столлман, сотрудник Лаборатории искусственного интеллекта, опубликовал свой манифест, где сформулировал «золотое правило»: каждый должен делиться понравившейся программой с теми, кому она тоже нравится. При этом Ричард сразу сделал акцент, что речь не про бесплатное ПО, а про свободы. Вот его цитата на этот счет: «У каждого должно было быть право пользоваться программами, изучать, изменять и распространять любую их версию… дело не в стоимости, а в дозволенности: имеется в виду, например, свобода слова, а не бесплатное пиво». Он же является автором универсальной общедоступной лицензии GNU — General Public License.
Ричард Столлман, основатель движения свободного ПО
Ну и, конечно, у истоков стоял всем известный Линус Торвальдс — в то время 21-летний студент Университета Хельсинки. О его детище Linux теперь знают все ИТ-специалисты.
Линус Торвальдс, создатель ОС Linux
С тех самых давних пор open source не просто живее всех живых, но и вовсю цветет и пахнет. Дошло уже до того, что большие коммерческие компании отказываются от написания и поддержки собственного коммерческого софта в пользу создания дополнительных плюшек над open source`ом. Т. е. вы можете самостоятельно собрать похожее ПО, но при обращении в компанию вся сборка будет максимально автоматизирована.
На всякий случай сделаю акцент для коллег, которые не погружены непосредственно в современную разработку. Сейчас при наличии большого количества различных библиотек и фреймворков, доступных для бесплатного использования, вам не нужно, например, с нуля писать некий алгоритм сортировки, а достаточно подключить нужную библиотеку или использовать встроенную функцию sort. Именно за счет этого мы получаем выигрыш в разработке.
Но на этом индустрия не остановилась. На сегодняшний день почти во всех языках и по всем направлениям разработки существуют различные абстракции и абстракции над абстракциями, которые позволяют дополнительно ускорять разработку.
Разберем это явление на примере двух языков JavaScript и Python.
Фреймворки над фреймворками
Современный фронтенд уже никто не пишет на чистом JavaScript, HTML и CSS. Для этих целей используют некую абстракцию над ними (да простят меня разработчики этих библиотек и фреймворков). Самые известные из них — React, Vue и Angular. Добавляем сюда фреймворки UI-компонент — и разработчик не пишет 10, а то и 100 строчек кода, он лишь добавляет тег
Но на этом рынок не остановился. В настоящее время нам доступны абстракции над абстракциями, которые позволяют писать еще меньше кода. Речь про Next для React и Nuxt для Vue. Авторы этих фреймворков автоматизировали еще больше стандартной рутины, которую ранее фронтенд-разработчик был вынужден повторять из проекта в проект. А это значит, что на выходе мы имеем еще меньше кода и еще больше преимуществ в скорости разработки.
Аналогичные процессы происходят и на участке бэкенд-разработки. Никто (почти никто) не берет чистый Python и не пишет бэкенд, начиная с самых простых и необходимых для бэка функций (например, вычитки и корректной обработки запроса). Вместо этого берут по аналогии с фронтом готовые бесплатные библиотеки и собирают нужный функционал из них. Сюда же добавим готовые фреймворки, например, Django. В результате разработчик может сосредоточиться на уникальной бизнес-логике, не тратя при этом время на повторное написание рутинного кода из проекта в проект.
За счет этого современная разработка разительно отличается от того, что было еще 10 лет назад. Теперь все быстрее и эффективнее.
Вместо выводов
Итого, если сравнить в лоб High Code-автоматизацию с Low Code-автоматизацией и разбить на стандартные этапы, вот что мы имеем на сегодня:
Реализация модели процесса и бизнес-правил. Здесь оба подхода идут бровь в бровь, т. к. в обоих случаях есть возможность создать модель процесса в нотации BPMN 2.0 и передать ее на исполнение (без кодирования) либо BPMS, либо BPM-движку.
Модель данных. Здесь я бы то же не давал пальму первенства ни одному из подходов, т. к. в одном случае аналитик мышкует модель данных в BPMS, а во втором подходе разработчик создает такой же плоский список, используя технологию ORM (object-relational mapping). Другими словами, в зависимости от подхода меняется специалист, но скорости у обоих похожие.
Интерфейсы пользователя. В случае Low Code аналитик в конструкторе форм мышкует интерфейс, а в случае High Code-автоматизации обычно подключается фронт-разработчик и дизайнер. Скорость на стороне Low Code, но есть и плата за это: пока вы работаете в рамках предоставленного конструктора, все хорошо, но, как только вам необходимо выйти за его пределы, трудозатраты возрастают кратно. При этом в случае High Code-разработки не все так страшно, как это было 10 лет назад: при использовании различных фреймворков трудозатраты на разработку значительно сокращаются.
Интеграции с другими системами. Аналогично с предыдущим пунктом. Low Code-инструменты уже зашли в эту сферу, и на сегодняшний день аналитик действительно получил возможность мышковать различные интеграции: например, самостоятельно прикрепить к процессу сервис по отправке SMS-сообщений. Но и классическая разработка не отстает. В свое время, примерно 2 года назад, я записал ролик «Как создать веб-сервис за 15 минут». Недавно, закрывая похожую задачу, я увидел, что этот же сервис теперь можно создать минут за 5, используя более современные библиотеки Python (речь про FastAPI). При этом на выходе будем иметь сервис с большим функционалом, чем ранее.
Резюмируя, фактически на 2023 год победителя пока нет. И любое декларирование, что «теперь только так и все» является перегибом. От себя посоветовал бы всегда на равных рассматривать оба метода и, добавляя ваш уникальный контекст (кто будет автоматизировать, что будете автоматизировать, какой стек предпочтительней и т. д.), выбирать тот или иной подход, а на следующем этапе — и инструмент (набор инструментов).
