Привет! Меня зовут Георгий Ржавин, работаю процессным архитектором в компании 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.