Low Code: волна будущего или взрыв из прошлого?

Одним из ИТ-трендов 2016 года является Low Code, обещающий возможность быстро удовлетворить потребности клиентов без больших армий дорогостоящего ИТ-персонала. Фактически, инструменты Low Code могут использоваться кем угодно, так называемыми «гражданскими программистами». Это очень удобно, поскольку разработчиков стоит дорого, их трудно найти, и им часто не хватает опыта в бизнесе. Звучит знакомо? Если вы работали в сфере ИТ в 1980-х и 1990-х годах, скорее всего, вы слышали те же обещания о технологиях 4GL, которые были распространены около двух десятилетий, но в конечном итоге потерпели неудачу. Обречен ли Low Code исчезнуть, как 4GL, или он извлечен из истории?

Что такое Low Code?

Термин Low Code популяризировал Forrester, который также оценивает лучших поставщиков Low Code. Он определяет Low Code как:

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

Итак, если кодирования очень мало, как вы разрабатываете приложения на этих платформах? Повторюсь, Форрестер, это:

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

Визуальная «композиция» - один из ключевых элементов Low Code, но он также немного вводит в заблуждение. Действительно, нет большого количества сложного на вид текста (он же код), что делает среду разработки более доступной, но то, что происходит, по-прежнему является программированием. Это означает, что такие вещи, как логика, алгоритмы, математика, модели данных и т. Д., По-прежнему задействованы, даже если для их ввода используется мышь вместо клавиатуры. Также стоит отметить, что эти платформы действительно требуют некоторой формы традиционного кода: отсюда и название Low Code (а не, скажем, No Code). Этот код часто написан на общем языке, таком как Java или JavaScript, или иногда на специальном языке, таком как SalesForce Apex.

Эти два фактора означают, что мои коллеги и я (которые анализируют и консультируют по сотням программных систем каждый год) встречаются лишь с очень небольшим количеством гражданских программистов, использующих эти технологии. Большинство из них являются разработчиками на полную ставку и, как правило, имеют техническое образование, как и в случае с большинством технологий. Похоже, Forrester даже называет тот факт, что платформы Low Code являются для гражданских разработчиков мифом:

Мы редко встречали таких гражданских разработчиков в нашем исследовании.

Кто эти провайдеры Low Code? Forrester упоминает Appian, Mendix, OutSystems и SalesForce как лидеров в этой области, но также традиционные громкие имена, такие как Microsoft и Oracle, имеют предложения Low Code.

А 4GL, что это было?

Название 4GL означает язык программирования 4-го поколения. Это относится к концепции, согласно которой языки программирования эволюционировали от низкоуровневых и подробных (1-е поколение, машинный код) к более высокому уровню абстракции с большей мощностью (3-е поколение, большинство языков программирования, которые мы все еще знаем сегодня). Таким образом, название 4GL предполагало больше абстракции и большей мощности. Было бесчисленное количество поставщиков 4GL, включая Oracle (Forms), Progress, Clipper и Informix.

Как и сегодня Low Code, 4GL должен был дать возможность непрограммистам создавать приложения. В книге 1982 года под названием Разработка приложений без программистов Джеймс Мартин утверждает, что некоторые конечные пользователи вполне способны создавать приложения самостоятельно, и выступает за использование для этого ранних технологий 4GL (таких как RAMIS и FOCUS). . Такие заявления быстро помогли 4GL стать популярными, даже если на практике очень мало приложений создавалось, не говоря уже о поддержке, непрограммистами.

Хотя приложения 4GL все еще используются во многих компаниях по всему миру, их популярность с момента их появления пошла на убыль. Технологии в основном используются для существующих приложений, и очень мало новых разработок ведется. Причины исчезновения тесно связаны с тремя типичными рисками для 4GL, о которых я писал в 2014 году. Применимы ли эти риски также к платформам Low Code? А есть ли новые риски?

Риск 4GL №1: плохая поддержка больших систем

Чтобы система постоянно изменялась и расширялась, необходимо, чтобы изменения оставались максимально локализованными. Технологии 4GL плохо справлялись с этой задачей из-за отсутствия поддержки таких понятий, как абстракция и разделение задач.

Это проблема, от которой страдают многие фреймворки программирования высокого уровня, и Low Code тоже (см. Обсуждение закона Дитцлера Нилом Фордом). Тем не менее, современные производители Low Code предлагают два улучшения по сравнению со своими предками 4GL:

  1. Признана необходимость поддержки абстракции и разделения задач, и во многих средах Low Code предлагаются такие функции, как наследование, модуляризация и инкапсуляция. Это позволяет системам оставаться более удобными в обслуживании и гибкими по мере их роста. Однако по сравнению с традиционными языками программирования некоторые из этих функций все еще ограничены.
  2. Как отмечалось ранее, все поставщики Low Code действительно используют традиционное программирование как часть своего решения. Поставщики Low Code теперь обычно открыто говорят о том, где код лучше, чем их собственная технология. Однако во многих решениях этот код скрыт. Я видел решения Low Code, в которых в среде визуального программирования были скрыты десятки тысяч строк кода. Хотя это не отменяет выбор технологии как таковой, в этих приложениях определенно не было недостатка в коде.

Риск 4GL №2: инструменты не поддерживают передовые методы разработки
Инструменты, доступные разработчикам 4GL, были ограничены и предлагались только поставщиком технологии. В большинстве случаев эти инструменты не поддерживали общие методы разработки, такие как контроль версий, автоматическое тестирование, сборка или развертывание, что приводило к тому, что на выполнение таких задач вручную уходило много времени.

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

Я рад сообщить, что некоторые платформы Low Code теперь предлагают API, которые позволяют третьим сторонам предоставлять дополнительную поддержку. Например, мы в SIG использовали API Mendix для создания Монитора качества приложений, который помогает разработчикам и менеджерам создавать приложения Mendix с высокой степенью поддержки.

Риск 4GL №3: нет библиотек

Программисты часто используют сторонние библиотеки для выполнения общих задач, таких как вызов веб-служб или чтение XML-документов. Это означает, что им не нужно самостоятельно программировать эту функцию, и они часто также предлагают лучшее качество. Технологии 4GL имеют очень небольшое количество библиотек и в основном предлагаются самим поставщиком платформы.

Поставщики Low Code определенно улучшили это и активно поддерживают сторонние компоненты, обычно в форме магазинов приложений, таких как Appian App Market, Mendix App Store и SalesForce AppExchange. Некоторые из этих магазинов процветают и предлагают большое количество бесплатных и платных сторонних компонентов, но другие (пока) в основном заполнены компонентами, предоставленными поставщиком, что дает небольшое улучшение по сравнению с 4GL.

Новый риск: зависимость от поставщика

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

Это также относится к поставщикам Low Code, но зависимость от поставщика еще сильнее. Во многих случаях все или большая часть инструментов доступна только в Интернете, а сами приложения развертываются в облаке поставщика. Хотя это дает много преимуществ, это также снижает гибкость. Использование других инструментов в (визуальном) коде, как правило, невозможно, и размещение приложения у другого поставщика редко бывает возможным. Возможно, сегодня это не проблема, но что, если ваш любимый продавец внезапно поднимет цены, упадет или прекратит использование технологии, которую вы используете?

Заключение

Глядя на поставщиков Low Code, кажется, что большинство из них хотя бы немного изучали историю и знают, какие проблемы преследуют технологии 4GL. Они пытались исправить эти проблемы в своих системах. Но в целом они не смогли полностью снизить эти технологические риски.

Как применить эти знания на практике? Рассматривая возможность использования технологии Low Code для нового приложения, выполните следующие два шага:

  1. Определите, подходит ли Low Code для вашего приложения. Не существует волшебной формулы, но у многих поставщиков Low Code есть четкая функциональная или техническая «золотая середина». Обычно плохо подходят системы, которые, как вы ожидаете, вырастут или будут долгоживущими, несмотря на улучшения по сравнению с их предшественниками 4GL, как и системы с большим объемом вычислений или алгоритмов. Отсутствие гибкости в развертывании (только в облаке поставщика) также может быть недопустимым в зависимости от ваших требований.
  2. Если вы выбрали Low Code, обязательно проанализируйте поставщиков. Перед тем, как выбрать одного из поставщиков, убедитесь, что знаете следующее:
  • Какие функции, поддерживающие абстракцию и разделение проблем, они предлагают?
  • Какие задачи обычно возлагаются на традиционный код на их платформе и как этот код поддерживается?
  • Позволяют ли их инструменты использовать методы разработки, которых вы придерживаетесь?
  • Есть ли у них сообщество библиотек и насколько оно активно?
  • Насколько вероятно, что поставщик и технология переживут ваше приложение?
  • Сколько опытных разработчиков доступно на рынке?

Я что-нибудь пропустил? Поделитесь своими предложениями или опытом по выбору поставщика Low Code.