Здравствуй, уважаемый Хабр!
Пролог
Меня зовут Ростислав, я работаю в IT с 2007 года. Начинал системным аналитиком, а последние 10 лет руководил проектами заказной разработки.
Мое представление о low-code платформе мечты сформировано прежде всего на основе опыта работы системным аналитиком, которым я никогда не переставал быть, хотя последние годы занимаюсь в основном управленческими задачами.
Традиционный процесс разработки
На иллюстрации представлен «традиционный», или «упрощенный стандартный» процесс разработки – заказчик формулирует высокоуровневые требования, аналитик их декомпозирует, программист выполняет требования в коде, тестировщик проверяет корректность работы, DevOps занимается обновлениями стендов и сопровождением.
Управление этим процессом мы выносим за скобки. Также я не стал делить аналитиков на бизнес и системных, т.к. на мой взгляд бизнес-анализ – частный случай анализа системного. При наличии системных аналитиков, бизнесовые, имхо, не нужны.
Итак, мы обозначили проблему и показали процесс, в рамках которого она живет.
Предлагаемое решение (упрощенное)
В качестве решения я хотел бы предложить свое видение.
В моем представлении, low-code платформа - инструмент прежде всего для работы системных аналитиков.
Аналитики смогут моделировать предметные области с помощью визуального конструктора сущностей в виде дерева классов и объектов, а набор генераторов платформы позволит создавать из этих моделей различные информационные производные, начиная от исходных кодов работающих веб-приложений, заканчивая проектной документацией, описывающей готовые решения.
Созданные аналитиками сгенерированные приложения при необходимости могут быть дополнены разработчиками.
Как видно, на иллюстрации из команды представлен только аналитик. Сразу всех успокою – представлено упрощение, другие участники процесса появятся дальше. Но на этом этапе я бы хотел показать, что для решения некоторых классов задач, при наличии подобной платформы и большом желании, можно обойтись одним толковым системным аналитиком и минимальными сроками.
За счет чего мы этого добьемся?
Аналитик, имея на входе информацию от заказчика, может не тратить время на подробное документирование требований, т.к. в нашей концепции он сам их будет в основном реализовывать и проверять – соответственно передавать знания дальше по процессу нет необходимости, достаточно иметь их в голове. Документация (в этом идеальном мире) потребуется только для согласования ожиданий с заказчиком и определения бюджета.
Разработка решений для некоторых классов задач станет доступна с помощью платформы аналитику. Подробнее об этом в следующих разделах статьи.
Необходимость в регресс-тестирование сгенерированных приложений отпадет, т.к. при наличии ошибок в генераторах, они будут «сквозить» по всему приложению, соответственно их будет просто отловить и отладить.
Для публикации приложения в облаке аналитику достаточно будет указать доступный сервер и url, все остальное платформа должна сделать сама.
Предлагаемое решение (больше похожее на правду)
На самом деле, конечно, результаты программирования без программистов и тестирования без тестировщиков на этом этапе оставляют желать лучшего и у нейросетей, и у системных аналитиков.
Вот как будет выглядеть процесс разработки на нашей платформе в реальности:
Заказчик формулирует высокоуровневые требования.
Аналитик фиксирует границы и основные требования.
Аналитик создает каркас приложения (описания БД, бэка, фронта и их связей) с помощью платформы.
Архитектор проводит ревью каркаса приложения.
Архитектор и аналитик описывают требования для наполнения тел методов классов и объектов в виде комментариев.
В зависимости от типа требований, задачи на разработку выполняются либо непосредственно аналитиком (простые логика и вычисления), либо разработчиками SQL/C#/JS с помощью встроенного редактора методов.
Готовая веб-страница собирается и публикуется после выбора доступного сервера и указания url.
Тестировщик и аналитик проверяют корректность работы, при необходимости процесс возвращается на шаг 6.
Каркас приложения
Каркас приложения в нашем случае будет представлять собой набор элементов, описывающих структуру БД, бэкенда, фронтенда и их взаимосвязей. Набор элементов будет представлен в виде дерева/графа классов и объектов, унаследованных из ограниченного набора базовых классов.
Формирование каркаса будет происходить примерно следующим образом:
Создается набор таблиц БД, их колонок и связей, ключей и индексов.
При необходимости обработки данных на уровне БД, создается функция, для нее указываются входящие и исходящие параметры.
Описывается набор API, предназначенных для работы со структурой БД и функциями, указываются входящие и исходящие параметры, производится их маппинг.
Создается объект страницы, в редакторе интерфейса приводится набор элементов UI, предназначенных для работы с описанными API, производится их маппинг.
Возможен и обратный порядок, но в случае с учетными системами Data-Driven-Development на моем опыте является оптимальным подходом.
Дополнение каркаса
Я уже писал выше, что без программистов в разработке пока не обойтись. Но определенные задачи доступны и системным аналитикам – например, возможность передать айдишник из одного запроса в другой, чтобы получить или сохранить связанные сущности с помощью типового набора CRUD API, уже позволит создать что-то функциональное.
По мере развития платформы, набор классов задач, доступных для решения аналитиком, будет расширяться.
В случае, если речь идет о какой-то сложной логике, процессах, либо вычислениях, платформа должна позволить дополнить созданный аналитиком каркас непосредственно программистам, на любом из уровней стека.
Резюме
Представленное видение - приглашение к диалогу. Сейчас на рынке все больше и больше решений, которые предназначены для упрощения разработки ПО, давайте попробуем вместе разобраться в этом.
Комментарии (10)
SADKO
17.01.2023 10:40+2Ну это-жж какая-то жесть, с самого начала, кому и на фига такой no-code нужен, бизнесу или outsource галерам для экономии на гребцах ;-)
Всё было ране, ничего не ново, вы посмотрите как работал и работает бизнес.
Почему манагерам некогда зашли электронные таблицы, они были просты и понятны, человек мог сам что-то сделать, не привлекая внимания санитаров ;-) Лотус и Ёксель первый в мире no-code, всем был хорош, многим и сегодня нравится, но есть ньюансы объема и многопользования. Ответом на который стали юзерфрэнливые датабэйзы вроде FoxPro, Access-a и прочего. В прочем не все системы с визуальными конструкторами манагерам зашли, они и шарик-то прохладно встретили но...
Нужно понимать что время идёт, дефолтные компетенции менеджеров растут, они не такие-же как тридцать лет назад, и тут как говорил один знакомый топ, "если менеджер не умеет разбираться в элементарных вещах, на фига нам такой в команде"...
Пытаться впарить государству\бизнесу колхоз, это конечно возможно в частных не рыночных скажем так кейсах. Но отхватить какую-то долю реальной жизни, это вряд ли.
Большие высоконагруженные решения, требуют соответствующих компетенций, а простые и не сложные делаются самими менеджерами, которые если соответствуют своей позиции, имеют экспертизу процесса на своём уровне, и способны не просто внятно объяснить, обрисовать, но и в ряде случаев сделать, если им дать подобающий инструмент.
Который запрограммирован, протестирован, обслуживается IT организации.
oracle_schwerpunkte
17.01.2023 12:09+1LOW -Code - идеально подходит для миграции из экселя в классическое внутреннее бизнес WEB-приложение, такое с тысячью полей и сотней формочек. Здесь все преимущества раскрываются во всей красе и все довольны. Разработчик, он же аналитик решает бизнес задачи не не думает о сортировке пузырьком. Заказчик получает релизы через день и может без задержек дать обратную связь. Если концепция изменилась, и переделать с нуля можно относительно быстро. Оснавную ценность в этом случае представляет не само приложение а знания бизнес процессов и деталей, то есть документация и опыт.
И масштабировать удобно вертикально - это же не рождественская распродажа, даже в международных корпорациях редко бывает больше 10000 пользователей одновременно. Проще пару процессоров прикупить.Бэкап опять же, это для бизнеса важно.SADKO
17.01.2023 12:47Если заказчику нужно напилить денег то да, и за каждую переделку этой несчастной формочки, ну идеально-же как асфальт или трамвайные рельсы в Москве ;-) и low code-тут сокращает издержки на взрослых разработчиков.
Правда на определённом уровне особо толстые заказчики на low code не запариваются, им не слабо менять бордюрный камень без нужды...С реальным бизнесом это не имеет ничего общего, там время деньги и сами с усами.
yirk
17.01.2023 12:11Очень много проблем возникает на стыке негибкости low-code платформы, дурацких требований заказчика и неумения аналитика с ними работать. И, в итоге, бОльшую часть времени разработчик тратит не на сложную бизнес-логику, а на борьбу с платформой, чтобы сделать выравнивание колонок по ширине или перенести кнопки слева направо.
SADKO
17.01.2023 13:03+1Вооот, а теперь сравните это всё с энтерпрайз решениями тех-же мелкомягких, где можно публиковать сводные таблицы, и кнопочки двигать мышкой оставаясь менеджером!
Там есть свои косяки и нюансы, которых производители low-code не замечают, иначе бы пестрили во всех промо материаллах...
...но есть и способ решения, в виде внутренних it консультантов, помогающих организовывать информационные процессы в компании и предотвращающих отстрел конечностей менеджеров ;-)
Glays
17.01.2023 13:29Было такое на практике. Заказчику сильно нужны были отчёты именно в его формате, но ближайший попавшийся под руку человек, который что-то мог слепить в акцессе не смог сделать именно так. В итоге, когда я сделал отчёт на FastReport 1 в 1, заказчик был просто счастлив, не смотря на то что это был отдельный бюджет.
Гибкость же может быть в разных местах. Если бизнес достаточно гибкий, его можно и на коробочный продукт натянуть и весь лоукод будет заключаться в галочках в настройках. Если бизнес не гибкий, но кошелёк можно растянуть на команду разработки (которая на самом деле может состоять и из 1 человека), то будет полноценный энтерпрайз продукт. Между этими полюсами разнообразные "интеграторы" с напильниками.
Мне кажется единственная ниша для ноу/лоукода по гибкости, это как раз упрощение интеграций. Но для этого лоукод должен быть частью интегрируемой платформы, а не заменой среды разработки.
ggo
18.01.2023 10:00Low code - это Excel, G Spreadsheets, и т.д.
А всякие построители форм плюс процессные движки - не low code. Хоть там и не пишут как бы код, а мышкой двигают, все же это специализированный инструмент, для которого нужно специалисты. Да, заточеность инструмента под конкретный домен, в некоторых случаях ускоряет разработку.
зы
конечно, апологеты "low-code" платформ с этим яростно несогласны ;). ну да бог им судья.
AlexeyPolunin
18.01.2023 15:21+1Мои соображения (на правах разрабатывающего подобного типа платформу):
— Идея оставить одного аналитика работает.
— Чисто визуальная штука с конструированием всего мышкой очень ограничена по возможностям тк мышкой не сделать сложную логику — поэтому нужен код!
— Если сказать аналитику «а теперь выучи JS, что бы пользоваться платформой» то это уже будет не аналитик, а программист.
— Мы сделали свой упрощенный код для неразработчиков и он работает, но это дорого для нас, как для разработчиков платформы, и это маркетинговая бомба, пока у вас нет миллиона пользователей.
— Учиться и повышать свой скилл в инструменте аналитику неизбежно придется.
— Иногда, что бы получить хорошую архитектуру, ему нужна помощь архитектора (в нашем случае это либо более опытный спец, либо консультация у нас, как у разработчиков платформы).
— Если нет критических ошибок в архитектуре — решение нормально масштабируется. Для внутренних корпоративных задач достаточного простого вертикального масштабирования, да и горизонтальное можно, но до этого еще никто не доходил.
— Что бы использовали крупные корпорации — этим надо специально заниматься. К нам несколько раз обращались (типа хотим использовать), но через их внутреннюю бюрократию не пролазит — теперь мы им прям сразу на входе говорим «забудьте».
sergeyns
не поверите, большинство проблем на большинстве проектов можно было бы обойти (и при минимальных сроках), если бы на них с самого начала наличиствовал толковый аналитик (а некоторые проекты даже пришлось бы свернуть, так и не дойдя до остальных участников процесса)...
codecity
Хороший аналитик может свернуть всю нашу жизнь.