программирование без кода

внешний интерфейс
программирование без кода

После мидл-офиса нет программирования кода.

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

Новое приложение должно взаимодействовать с большим количеством сторонних (не принадлежащих собственной команде) сервисов. Постоянные изменения между сервисами привели к изменениям у соответствующих пользователей. Постоянно меняющийся бизнес привел к постоянным изменениям в дизайне стойки регистрации. Чтобы справиться с внешними службами Quick Talk, промежуточный этап был создан на внутреннем уровне, чтобы обеспечить возможности быстрого реагирования. С дальнейшим осаждением среднего этапа он имеет тенденцию быть стабильным в той или иной форме, в то время как стойке регистрации все еще нужно быстро реагировать.

Итак, как фронтенд-разработчик, мы продолжаем дорабатывать и повторно использовать код, думая о паттерне из предыдущей статьи.7~8 способов уменьшить объем кодаупоминается в:

  • строительные леса
  • Библиотека компонентов
  • библиотека шаблонов
  • Шаблоны и шаблонные приложения

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

Другими словами: нам нуженпередний центр, это программирование без кода/с низким кодом.

Что такое программирование кода?

No-code/low-code — это метод создания приложений, который позволяет разработчикам быстро разрабатывать приложения с минимальными знаниями в области программирования. Его можно использовать для сборки и настройки приложений в графическом интерфейсе с помощью визуального моделирования. Разработчики могут просто пропустить всю инфраструктуру и сосредоточиться только на реализации бизнес-логики с помощью кода.

Конечно, с точки зрения разработчика, для уменьшения количества кода это может быть:

  1. Сама структура справляется со сложностью. после всего«Сложность, как и сила, не исчезает, она не возникает из воздуха, она всегда переходит из одного предмета в другой или из одной формы в другую».
  2. Генерация кода снижает нагрузку. Копирование и вставка занимает больше времени.

обработать

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

低代码编程流程

С моей точки зрения, я делю программирование без кода на две части:

  • Редактор для создания пользовательского интерфейса - онлайн-инструмент для создания пользовательского интерфейса и создания страниц с помощью перетаскивания.
  • Поточный редактор для написания бизнес-логики — написание бизнес-кода (в основном обработка данных) посредством потокового программирования

UI-программист. Чтобы спроектировать наш конструктор пользовательского интерфейса, нам нужно подготовить ряд инфраструктуры:

  • UI-программист. Для Drag-and-Drop Design Design.
  • Пустые леса. Полное применение с жизненным циклом проекта, но это пустой элемент - добавить компоненты и код мы в процессе построения пользовательского интерфейса, в любое время, в любом месте.
  • Система дизайна. Нам нужна полная библиотека компонентов, большое количество шаблонов страниц и определенное количество шаблонных приложений, чтобы уменьшить количество соответствующих инструментов разработки.
  • Набор фрагментов кода. Кроме того, он создает библиотеку компонентов в системе проектирования в виде фрагментов кода и динамически редактирует код через интерфейс командной строки после редактирования.
  • DSL (доменный язык, опционально). Промежуточная генерация для изоляции рамы от конструкции.

потоковый программист. Впоследствии, чтобы

  • потоковый программист. Для перетаскивания введите и напишите бизнес-код.
  • серверная служба. Если вы не можете предоставлять готовые серверные службы, вам необходимо иметь стандартную спецификацию API и соответствующий фиктивный сервер.
  • библиотека шаблонов. Содержит соответствующий код бизнес-обработки, такой как общий вход в систему, сбор данных, взаимодействие с пользовательским интерфейсом и т. д.
  • DSL (доменный язык, опционально). То же

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

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

Исходя из описанного выше процесса, программирование без кода также имеет следующие характеристики:

  • Перетащите интерфейс. Или визуальная модель - на основе узлов и стрелок
  • Дизайн на основе видения.
  • Масштабируемый дизайн. Например, серия поддержки плагинов, магазинов плагинов и сообществ.
  • Кроссплатформенная функциональность. Поддержка разработки веб-приложений для ПК, инфраструктура мобильных приложений и другая поддержка.
  • После мощного развертывания. То есть платформа содержит весь жизненный цикл приложения.
  • Имеет богатую поддержку интеграции. Вы можете найти необходимые компоненты по желанию, а также соответствующие фоновые службы.
  • Настраиваемый. Это также означает множество пользовательских настроек.
  • Язык, специфичный для домена Homebrew (необязательно). Используется для оптимизации времени сборки.

Преимущества и недостатки

Соответственно, он имеет следующие характеристики:

  1. Эффективный.不用多说，节省时间和开发成本。
  2. Ограниченная ошибка, безопасность.
  3. бюджетный. Требуемый бюджет очень ограничен.
  4. Простота использования (в зависимости от конструкции).
  5. Развитие идет быстрее.
  6. ИИ в разработке.
  7. Низкая стоимость обслуживания.

Соответствующие соответствующие недостатки:

  1. Навыки программирования по-прежнему необходимы.
  2. Ограниченные возможности настройки.
  3. Новым вопросом стала масштабируемость.
  4. Интеграция ограничена.

В настоящее время платформы разработки с низким кодом обычно делятся на две большие категории:

  • Для внешних: создавайте простые продукты, такие как мобильные веб-приложения.
  • Для внутреннего использования: создавайте бизнес-приложения для своей команды или предприятия.

Простые сервисы, такие как использование только CRUD, форм, проверки, простой агрегации, разбиения на страницы и т. д. Наиболее распространенным примером является создание форм. Такие приложения, как Golden Data, можно создавать напрямую путем перетаскивания элементов. Соответствующей реализацией с открытым исходным кодом является jQuery Form Builder. Для разработчиков нам нужно только определить модель данных, а затем перетащить, чтобы определить положение элемента. С этой точки зрения, пока можно использовать приложения и службы, созданные с помощью Serverless, можно напрямую использовать модель разработки с низким кодом.

Сравнение процесса разработки

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

  1. Анализировать, проектировать, проверять, планировать требования
  2. Архитектура системы проектирования
  3. Создавайте front-end и back-end проекты. Выберите стек технологий, создайте его с нуля или создайте из шаблонов.
  4. Создайте непрерывную интеграцию.
  5. Создайте линейную блок-схему и высокую точность.
  6. Разработайте модель данных и определите внешние и внутренние контракты, т. е. API URI, методы, поля и т. д.
  7. Front-end и back-end реализуют бизнес-логику.
  8. Внешний интерфейс реализует страницу пользовательского интерфейса.
  9. Интегрируйте сторонние серверные службы.
  10. Тестирование функциональных требований (DEV, QA, ST, UAT)
  11. Кросс-функциональное тестирование требований (безопасность, производительность и т.д.)
  12. Развертывание в производственной среде.

Однако процесс разработки с низким кодом:

  1. Анализировать, проектировать, проверять, планировать требования
  2. Выберите нужный сторонний API
  3. Нарисуйте рабочий процесс вашего приложения, модель данных и пользовательский интерфейс в визуальной среде IDE.
  4. API подключения — обычно с использованием сервиса, обнаружения функций.
  5. Напишите бизнес-логику (необязательно). Добавьте ручной код во внешний интерфейс или настройте автоматически сгенерированный SQL-запрос.
  6. Приемочное тестирование пользователей.
  7. Развертывание в производственной среде.

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

Применимая сцена

На данный момент программирование без кода на самом деле является очень предсценарным режимом. Следовательно, он имеет определенные применимые сценарии:

  • Разработка на основе модели.
  • Быстрая сборка пользовательского интерфейса.
  • Минималистичные бизнес-функции. Использование таких инструментов также означает, что наша
  • Ограниченные ИТ-ресурсы. В случае ограниченных ресурсов наиболее важно быстро разрабатывать приложения, отвечающие потребностям бизнеса.

С точки зрения процесса, для некоторых приложений мы не можем достичь программирования без кода - есть некоторые бизнес-различия. следовательно,В большинстве сценариев реализовано только программирование с низким кодом..

Если вам нужно настоящее программирование без кода, вам нужны более конкретные сценарии:

  • Форма проектирования (входные данные)
  • Создание отчетов (организация данных)
  • Рутинное планирование и автоматизированные процессы (манипулирование данными)

Прорабатываются дополнительные сценарии.

Проблемы программирования без кода

Программирование без кода, помимо необходимости подготовки ряда инфраструктур, упомянутых выше, неизбежно столкнется с рядом проблем.

  • Кто будет писать эту часть кода?
  • Подготовка клиентской инфраструктуры.
  • Построение сервисной платформы на стороне сервера.
  • Унифицированный пользовательский интерфейс. Разработайте ряд компонентов, которые можно легко комбинировать, и соответствующие шаблоны страниц. При этом они также могут быть адаптированы к разным стилям, то есть поддерживаться разнообразной тематикой.
  • Дизайн пайплайна DevOps. Программирование с низким кодом опирается на ряд автоматизированных инструментов для создания, отладки, развертывания и обслуживания, а также тестирования приложений.
  • Дизайн доменного языка.
  • автоматизированный тест. Если наш интерфейсный код генерируется автоматически, нужно ли нам его тестировать? Это хороший вопрос, и если код генерируется автоматически, тесты тоже должны генерироваться автоматически. Ведь для обеспечения качества платформы необходимо написать большое количество автоматических тестов на платформе.

Некоторые из них немного сложнее, и мы, вероятно, сможем их изучить.

Кто будет писать эту часть кода?

Первый вопрос, который мы должны рассмотреть при создании такой платформы и инструмента: для кого мы пишем этот инструмент?

  • Люди без опыта программирования. Например, деловой персонал, он / они имеют очень богатый опыт работы с бизнес-системами. Это также означает, что мы
  • Кто-то со знанием программирования, но без опыта.
  • Разработчики с небольшим опытом.
  • Опытные разработчики. Для профессионалов автоматизация означает отсутствие гибкости. Даже они тратят больше времени на исправление сгенерированного кода, чем на его самостоятельное написание.

Очевидно, что для достаточно опытных разработчиков этот инструмент не обязательно то, что им нужно.

клиентская инфраструктура

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

В то же время, из-за различных уровней разработчиков, инструменты, которые нам нужно делать, также разные:

  1. Поддержка облачной сборки и отладки.
  2. Приложение для программирования с графическим интерфейсом.
  3. генерация кода.
  4. Архитектура проектной системы. Создание библиотеки компонентов, создание шаблона приложения и т.д.
  5. …

Еще сложнее то, что разработчиков легко заставить использовать генерацию кода.

Сервер

Что касается платформы с низким исходным кодом, она должна соответствовать серверной части:

  1. Доступно множество существующих сервисов. Аутентификация, безопасность, возможности push-уведомлений, карты и многое другое
  2. Быстро создавайте серверные службы. Если есть внутреннее решение Serverless или FaaS, можно сказать, что оно лучше.
  3. Простая интеграция со сторонними сервисами.
  4. гибкость. Поддержка нескольких языков и т. д.

Унифицированный API бэкэнд-сервиса, для бэкэнд-сервисов нам нужна общая парадигма. Все API должны быть разработаны в соответствии с этой парадигмой. Однако, как потребитель API, у нас может не быть таких возможностей, но мы можем использоватьШаблон декоратораЭто сторонние пакеты API в единый способ. С этой целью, как мы используем, остается:

  • договор. Как и в случае с пользовательским интерфейсом Swagger, создать простой в использовании сервис несложно.
  • лучший друг То есть мы инкапсулируем эти сторонние приложения одно за другим в соответствии с нашими потребностями.
  • язык запросов. Вместо того, чтобы писать BFF самостоятельно, проще использовать:GraphQLТакой серверный язык запросов является более удобным и более гибким в режиме.

В период проектирования перед разработкой нам необходимо сначала спроектировать соответствующую модель предметной области.

Дизайн доменного языка

Использование среды с низким кодом (графика)язык моделированиядля указания поведения всей системы и продукта. Это значит:

  1. Применяйте структуры данных и шаблоны предметной области ко всем уровням программы.
  2. Интегрируйте бизнес-правила и решения в приложение (иерархию).

Это также означает, что нам нужно разработать модельный язык. И на самом деле для нас это предметно-ориентированный язык (DSL). Вот простой пример DSL, описывающий используемые компоненты:

  {
    'style': '',
    'id': 2,
    'blocks': [
      {
        'content': {
          'content': 'content',
          'title': 'hello'
        },
        'type': 'card'
      }
    ]
  }

Кроме того, нам также необходимо разработать соответствующий макет DSL, например:

H:[circle1(circle1.height)] // set aspect-ratio for circle1
HV:[circle2..5(circle1)]    // use same width/height for other circles
H:|[circle1]-[circle2]-[circle3]-[circle4]-[circle5]|
V:|~[circle1..5]~|          // center all circles vertically

Наконец, нам также нужно преобразовать код потока в реальный код проекта. Все три типа DSL вместе взятые не являются простым инструментом.

Прототипирование

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

  1. Войти успешно.
  2. Отменить вход.
  3. Авторизация не удалась. Для клиента может рассматриваться отмена входа в систему. Для сервера это может быть ошибка пароля, имя пользователя не существует, учетная запись заблокирована и т. д.

Соответствующие вышеуказанным сценариям, есть некоторая общая логическая обработка:

  1. Авторизация успешна. Сохраните токен и вернитесь на страницу истории.
  2. Авторизация не удалась. Появится окно подсказки для пользовательского содержимого.

Коды похожи.

Интерфейсный прототип

В некоторых простых интерфейсных приложениях:

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

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

  • Загружайте страницы бесконечно. Просто привяжите API, а затем управляйте отображением и скрытием элемента.
  • форма. Определенные поля являются типами, и доступна соответствующая логика внешнего и внутреннего интерфейса. Кроме того, нам также необходимо настроить для них общие правила, такие как регулярные выражения. И как только между формами есть связь, дизайн этого компонента становится более проблематичным.
  • Элементы карточного стиля.
  • Формы и табличные представления.
  • Общие графики. На самом деле, уже существует ряд инструментов построения диаграмм, и мы просто инкапсулируем их дважды, превращая их в форму доменного языка.
  • Расширенный адаптивный макет. В отличие от макета независимой разработки каждого приложения, платформа с низким кодом должна предоставлять набор мощных настраиваемых и адаптивных макетов, то есть соответствовать общему режиму мобильного терминала, а также соответствовать общему режиму настольная версия. Например, для больших объемов данных на десктопной стороне используется разбиение на страницы, а на мобильной — бесконечная прокрутка.

Бэкенд-прототип

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

Это также означает:

  • Микросервис. Каждая серверная служба должна быть как можно меньше.
  • Нормализация API. То есть он принимает унифицированный формат API и принимает унифицированное управление разрешениями.
  • Большое количество API сервисов.
  • Быстро интегрируйте сторонние сервисные решения. Интеграция сторонних сервисов — неизбежная ситуация при разработке приложений. Чтобы решить эту проблему, нам нужно подготовить соответствующую логику службы создания, передать параметры, требуемые сторонней службой, а затем напрямую сгенерировать нашу службу пересылки.

Итак, вопрос в том, можем ли мы в этом случае предоставить индивидуальный инструмент? Разрешить каждому создавать свой поток компонентов?

Очевидно, да.

доказательство концепции

Итак, в недавно разработанном PoC (доказательстве концепции) использовался фреймворк Anguar. Соответствующая основная идея состоит в следующем:

  1. Используйте Material Design в качестве библиотеки компонентов и используйте Drag CDK для реализации функции перетаскивания. Каждый перетаскиваемый компонент, называемый элементом, создается ElementDispatcher в соответствии с данными. Перетаскиваемая часть состоит из двух частей:макет + элемент.
  2. После создания пользовательского интерфейса создается соответствующий DSL, в настоящее время использующий JSON. В конце концов, структуры данных — это простейшие предметно-ориентированные языки.
  3. Эта часть DSL анализируется Angular Schematics для создания соответствующего кода проекта.

разное

Связанные проекты с открытым исходным кодом:

Использованная литература:

  1. www.process.st/low-code/
  2. medium.com/@Stefan.Electric…
  3. medium.com/@Stefan.Electric…
  4. woohoo.out systems.com/blog/what-i…
  5. medium.com/@Stefan.Electric…
  6. Woohoo Quora.com/what-is-low…
  7. программирование без кода
Категории