Здравствуй, уважаемый Хабр!
Пролог
Меня зовут Ростислав, я работаю в IT с 2007 года. Начинал системным аналитиком, а последние 10 лет руководил проектами заказной разработки.
Мое представление о low-code платформе мечты сформировано прежде всего на основе опыта работы системным аналитиком, которым я никогда не переставал быть, хотя последние годы занимаюсь в основном управленческими задачами.
Традиционный процесс разработки
На иллюстрации представлен «традиционный», или «упрощенный стандартный» процесс разработки – заказчик формулирует высокоуровневые требования, аналитик их декомпозирует, программист выполняет требования в коде, тестировщик проверяет корректность работы, DevOps занимается обновлениями стендов и сопровождением.
Управление этим процессом мы выносим за скобки. Также я не стал делить аналитиков на бизнес и системных, т.к. на мой взгляд бизнес-анализ – частный случай анализа системного. При наличии системных аналитиков, бизнесовые, имхо, не нужны.
Итак, мы обозначили проблему и показали процесс, в рамках которого она живет.
Предлагаемое решение (упрощенное)
В качестве решения я хотел бы предложить свое видение.
В моем представлении, low-code платформа - инструмент прежде всего для работы системных аналитиков.
Аналитики смогут моделировать предметные области с помощью визуального конструктора сущностей в виде дерева классов и объектов, а набор генераторов платформы позволит создавать из этих моделей различные информационные производные, начиная от исходных кодов работающих веб-приложений, заканчивая проектной документацией, описывающей готовые решения.
Созданные аналитиками сгенерированные приложения при необходимости могут быть дополнены разработчиками.
Как видно, на иллюстрации из команды представлен только аналитик. Сразу всех успокою – представлено упрощение, другие участники процесса появятся дальше. Но на этом этапе я бы хотел показать, что для решения некоторых классов задач, при наличии подобной платформы и большом желании, можно обойтись одним толковым системным аналитиком и минимальными сроками.
За счет чего мы этого добьемся?
Аналитик, имея на входе информацию от заказчика, может не тратить время на подробное документирование требований, т.к. в нашей концепции он сам их будет в основном реализовывать и проверять – соответственно передавать знания дальше по процессу нет необходимости, достаточно иметь их в голове. Документация (в этом идеальном мире) потребуется только для согласования ожиданий с заказчиком и определения бюджета.
Разработка решений для некоторых классов задач станет доступна с помощью платформы аналитику. Подробнее об этом в следующих разделах статьи.
Необходимость в регресс-тестирование сгенерированных приложений отпадет, т.к. при наличии ошибок в генераторах, они будут «сквозить» по всему приложению, соответственно их будет просто отловить и отладить.
Для публикации приложения в облаке аналитику достаточно будет указать доступный сервер и url, все остальное платформа должна сделать сама.
Предлагаемое решение (больше похожее на правду)
На самом деле, конечно, результаты программирования без программистов и тестирования без тестировщиков на этом этапе оставляют желать лучшего и у нейросетей, и у системных аналитиков.
Вот как будет выглядеть процесс разработки на нашей платформе в реальности:
Заказчик формулирует высокоуровневые требования.
Аналитик фиксирует границы и основные требования.
Аналитик создает каркас приложения (описания БД, бэка, фронта и их связей) с помощью платформы.
Архитектор проводит ревью каркаса приложения.
Архитектор и аналитик описывают требования для наполнения тел методов классов и объектов в виде комментариев.
В зависимости от типа требований, задачи на разработку выполняются либо непосредственно аналитиком (простые логика и вычисления), либо разработчиками SQL/C#/JS с помощью встроенного редактора методов.
Готовая веб-страница собирается и публикуется после выбора доступного сервера и указания url.
Тестировщик и аналитик проверяют корректность работы, при необходимости процесс возвращается на шаг 6.
Каркас приложения
Каркас приложения в нашем случае будет представлять собой набор элементов, описывающих структуру БД, бэкенда, фронтенда и их взаимосвязей. Набор элементов будет представлен в виде дерева/графа классов и объектов, унаследованных из ограниченного набора базовых классов.
Формирование каркаса будет происходить примерно следующим образом:
Создается набор таблиц БД, их колонок и связей, ключей и индексов.
При необходимости обработки данных на уровне БД, создается функция, для нее указываются входящие и исходящие параметры.
Описывается набор API, предназначенных для работы со структурой БД и функциями, указываются входящие и исходящие параметры, производится их маппинг.
Создается объект страницы, в редакторе интерфейса приводится набор элементов UI, предназначенных для работы с описанными API, производится их маппинг.
Возможен и обратный порядок, но в случае с учетными системами Data-Driven-Development на моем опыте является оптимальным подходом.
Дополнение каркаса
Я уже писал выше, что без программистов в разработке пока не обойтись. Но определенные задачи доступны и системным аналитикам – например, возможность передать айдишник из одного запроса в другой, чтобы получить или сохранить связанные сущности с помощью типового набора CRUD API, уже позволит создать что-то функциональное.
По мере развития платформы, набор классов задач, доступных для решения аналитиком, будет расширяться.
В случае, если речь идет о какой-то сложной логике, процессах, либо вычислениях, платформа должна позволить дополнить созданный аналитиком каркас непосредственно программистам, на любом из уровней стека.
Резюме
Представленное видение - приглашение к диалогу. Сейчас на рынке все больше и больше решений, которые предназначены для упрощения разработки ПО, давайте попробуем вместе разобраться в этом.
