Ситуация

Необходимость в выборе новой low‑code платформы у нас в учебном процессе МЭИ появилась после того, как компания Oracle объявила о своем уходе из России. До этого учебный процесс цикла дисциплин начиная от баз данных и заканчивая разработкой клиентских приложений строился исключительно на технологиях Oracle. В частности, для выполнения практических работ и курсовых проектов дисциплины «Разработка информационных систем» использовалась связка Oracle DB + Oracle Application Express (APEX).

С вопросом замены СУБД проблем не возникло. Без вариантов была выбрана хорошо известная СУБД PostgreSQL и адаптированные на ее основе российские разработки. А вот замена APEX вызвала заметные трудности.

За год мы рассмотрели несколько, представленных на отечественном рынке low‑code платформ, а две из них даже попытались опробовать на пилотных группах студентов, однако все попытки внедрить их в учебный процесс оказались неудачными. Наконец я обратил внимание на платформу ХИ‑квадрат, и вот тут произошло стопроцентное попадание в точку.

История поиска решения

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

Причина кроется в самом подходе к построению таких платформ. Как правило эти платформы имели собственную методологию создания информационных систем, достаточно жестко «прошитую» в средства разработки. Фактически платформа такого рода представляет собой набор средств создания объектов, предусмотренных этой методологией. Создается впечатление что Low‑code представляет собой ядро более крупной информационной системы, оставшейся после разработки. Не пропадать же добру! С небольшой адаптацией это ядро может быть предложено рынку в качестве независимого проекта.

Кстати, нетрудно «вычислить» какой проект «родил» платформу поскольку именно этот аспект как правило наилучшим образом методологически проработан в платформе. Например, если встречаются такого типа объекты как «персонал» или «орг. структура», то похоже платформа является результатом разработки системы управления персоналом. Ели же мы видим проекты, задачи и так далее то похоже родительский проект был посвящен системе управления проектами.

Главным отличительным признаком таких low‑code платформ является запрет на непосредственный доступ к предметной базе данных. Вы можете создавать экземпляры мета‑объектов предусмотренной методологией платформы и настройка их взаимодействия через GUI интерфейс разработчика или с помощью системы API команд, но никогда не сможете увидеть, что реально при этом происходит в базе данных. Мало того, в таких системах, непосредственный доступ к базе данных опасен, так как любое вмешательство в структуру или данные может сказаться не только на бизнес‑логике, но и на работоспособность системы в целом.

Какие же негативные моменты несет в себе использование таких систем в учебном процессе?

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

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

ХИ‑квадрат свободен от этого недостатка и не накладывает каких‑либо методологических ограничений на структуру данных. База данных может разрабатываться независимо от платформы без учета каки либо специфических особенностей платформы.

Сравнение ХИ‑квадарт и Oracle APEX

Конечно же, имея многолетний опыт с Oracle APEX я невольно сравниваю средства разработки Хи‑квадрат с предыдущим инструментом.

Если быть более точным, то функциональным аналогом Oracle APEX является отдельный компонент ХRAD. Именно он предназначен для проектирования и реализации клиентского приложения.

Какие же особенности и характеристики хочется отметить сравнивая эти два продукта.

  1. Неоспоримым преимуществом платформы Хи‑квадрат является тот факт, что это отечественная платформа, внесенная в реестр отечественно ПО. Разумеется, исключаются ситуации, с которыми мы столкнулись, используя линейку продуктов Oracle.

  2. Вторым преимуществом явился тот факт, что в отличии от APEX продукты Хи‑квадрат (в том числе и XRAD) способны работать с базами данных разных вендоров. В список входят как отечественный postgres, так и такие лидеры мирового рынка СУБД как MS SQL и Oracle DB. APEX же работает исключительно с Oracle DB, что является достаточно сильным ограничением для его использования.

  3. При первом знакомстве с XRAD бросается в глаза схожесть подходов и интерфейсных решений обоих продуктов. Похоже, что разработчики платформы вдохновлялись решениями уже реализованными и апробированными в APEX. В моем конкретно случае это явилось ключевым фактором выбора платформы Хи‑квадрат, поскольку позволило воспользоваться уже накопленным в APEX опытом и трансформировать его применительно к новой платформе, тем самым сократив затраты на освоение нового продукта. Более того это позволило легко адаптировать уже имеющиеся учебные программы к новому продукту, практически не меняя структуры дисциплины.

  4. Однако не обошлось и без «культурного шока». Используя APEX, я мог без труда создавать для студентов изолированные друг от друга рабочие пространства (workspace), где студенты могли создавать приложения, регистрировать других пользователей, распределять роли и так далее. Каково же было мое удивление, когда я не обнаружил workspace в XRAD. Мало того и понятия приложения там нет. Один инстанс XRAD соответствует одному приложению.

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

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

Заключение

Остановив свой выбор на платформе ХИ‑квадрат мне кажется было лучшим решением в создавшейся ситуации. Описанный опыт может быть полезен не только при выборе low‑code платформы для учебного процесса, но и в реальных проектах.

Какие же основные советы я могу дать тем, кто встал перед подобным выбором?

  1. Если вам необходимо разработать клиентские приложения к уже функционирующей базе данных, или предполагается интеграция с другими системами на уровне базы данных, сразу обращайте внимание на возможность low‑code платформы работать с внешней базой данных. Выбирая «закрытые» с точки зрения базы данных платформы, вы теряете универсальность и вынуждены следовать навязанной вам методологии проектирования.

  2. Если у вас есть опыт работы с Oracle APEX рекомендую вам обратить внимание именно на линейку продуктов Хи‑квадрат и конкретно XRAD. Это позволит осуществить комфортный и быстрый переход на новый инструмент разработки.