Постоянно идут разговоры о программировании без программистов.
За последние 14 лет моей работы в IT уже произошла вторая волна любви к low-code решениям.
Если вы наблюдаете за IT-рынком дольше, то наверняка помните еще парочку из этой темы.
Непрограммистов, создающих бизнес-приложения в визуальных редакторах, называют Гражданский интегратор или гражданский разработчик .
Лозунги продавцов данной темы сводятся к следующему:
.В этой статье я хочу разобраться, насколько эти обещания верны, а также где и как использовать low-code платформы, чтобы не выстрелить себе в ногу.с платформами без кода и с низким кодом каждый может создавать приложения без опыта работы с программным обеспечением, значительно быстрее и за небольшую часть затрат.
Зачем бизнесу нужны платформы с низким кодом?
Нынешний всплеск интереса к low-code, скорее всего, связан с тем, что дорогие программисты стали еще дороже, но в свободном доступе дорогих программистов вы не найдете.НеИТ-компании не могут нанять кого-то стоящего, но им все равно приходится заниматься проектами.
Даже аутсорсеров найти непросто, потому что их штат тоже размывается из-за стремления крупных компаний развивать собственные ИТ и для этого они нанимают сто , тысячи И тысячи .
Цифровая трансформация прорвалась даже к тем компаниям, которые до последнего момента пытались ее избежать.
В итоге ИТ-проекты есть, деньги есть, а рук нет. Что делать? Кажется выгодным использовать платформу с низким кодом/без кода, чтобы дешевые и многочисленные работники, не связанные с ИТ, могли создавать бизнес-приложения.
Недавно в Москве прошла встреча на эту тему.
конференция «LOW-CODE 2021» , где программный директор серии практических конференций издательства «Открытые системы» Дмитрий Волков написал следующее вступительное слово:
«Апологеты представляют low-code как основной инструмент масштабной цифровой трансформации.Я буду выступать в роли критика, но при этом опишу способ использования low-code платформы, при котором это приложение будет эффективным и оправданным.Критики указывают на разрозненность, плохую производительность, отсутствие должной интеграции, проблемы с обслуживанием собственных решений, безопасностью и надежностью.
Поэтому, прежде чем использовать low-code/no-code, посетите нашу конференцию"
Причина неудачи предыдущих подходов с низким кодом
Low-code завораживает, когда видишь реализацию простой системы без кода и понимаешь, что она создана в визуальном редакторе без программиста.И это дешево и быстро.
Возникает естественное желание масштабировать этот подход на все бизнес-задачи.
Нападка любви к low-code заканчивается тем, что low-code подход не может преодолеть проблему возрастающей сложности, которая нелинейно нарастает в процессе создания ИТ-решения.
При визуальном программировании сложность возрастает слишком быстро, и система становится неуправляемой.
До определенного момента (пока графики не пересекутся) такое решение будет опережать традиционный подход по скорости разработки, т.е.
вы быстрее выйдете на рынок.
Но преимущества визуального программирования быстро заканчиваются, и «визуальное» решение быстро превращается в неуправляемый беспорядок.
Романтика low-code разбивается на нет суровой реальностью, в которой ИТ-отделы должны помогать предприятиям создавать большие и сложные ИТ-системы с постоянно меняющимися требованиями и в то же время поддерживать множество внутренних и внешних соглашений об уровне обслуживания.
Похоже, low-code может подойти для «простых» проектов, но для «сложных» он перестает работать.
Давайте определим, что такое простая и сложная ИТ-система:
- Простая система – локальное решение для пары сотрудников.
Тётя Маша из бухгалтерии хочет, чтобы она получила СМС, когда на почту придет письмо от начальника.Она идет в Запир и «программирует» себе пару триггеров и интеграций.
Бизнес не зависит от этой автоматизации; логики минимум.
Если требования тети Маши изменятся, то изменения легко сможет внести сама тётя Маша.
Если триггер сломается, то никто в компании и среди клиентов бизнеса этого не почувствует.
- Сложная система — это критически важное для бизнеса решение.
Например это ценообразование заказов в Ozon , система управления заказами в Леруа Мерлен, логистика доставки на рынке и так далее.От этих систем зависят прибыль бизнеса и репутация бренда.
Такие системы часто меняются, и изменения нужно вносить быстро и безопасно, т. е.
уметь эффективно и быстро тестировать.
Эти системы подвержены колебательным нагрузкам, поэтому они должны иметь возможность горизонтального масштабирования.
- Рефакторинг и сокращение технического долга либо невозможно, либо сложно.
При этом изменения в бизнесе необходимо своевременно внедрять в системы.Для бизнеса систему по-прежнему создавали программисты путем написания кода или аналитики путем добавления квадратов в визуальном редакторе.
Изменения должны вноситься быстро и безопасно.
На данный момент ни одна low-code платформа не имеет инструментов рефакторинга хотя бы близкого к уровню продвинутых IDE.
- Автотестирование невозможно или крайне сложно.
Без автотестов невозможно безопасно внести изменения.Если нет автотестов, то мы возвращаемся в те доисторические времена, когда выпуск одной фичи требовал полного ручного регресса всей системы.
Бизнес, умеющий считать деньги, не будет за них платить.
- Высокие нагрузки, кастомная интеграция и безопасность.
Эти задачи требуют квалифицированных инженеров и не могут быть полностью решены с помощью визуального программирования, ориентированного на решение стандартных задач.
Отдельно надо сказать, что если система создавалась в визуальном редакторе и было решено перевести ее в обычный код, то всю систему нужно писать заново.Получается, что сложное решение на low-code платформе — это «код только для чтения» с очень высокой стоимостью внесения изменений.Если система изначально была написана в коде, то возможна частичная замена кода или рефакторинг.
Это то, что нужно бизнесу?
РДС (Россия делает сама)
Или, может быть, проблема в том, что low-code платформы слишком универсальны? Логичным ответом на это будет желание создать свою платформу, для себя.Я общаюсь с разными компаниями и вижу, что они внутри страны создают свои low-code решения.
Помимо желания создавать ПО без программистов, есть еще и естественное эволюция микросервисной архитектуры в оркестратор бизнес-сервисов .
Но при создании low-code платформы для себя появляется фактор стоимости.
Затраты на разработку такой платформы, на мой взгляд, неоправданно высоки.
Каковы затраты:
- Чтобы создать платформу программирования без программистов, нужны очень хорошие программисты и дизайнеры.
То есть изначально нужно 1) привлечь, 2) удержать, чтобы экспертиза не потерялась, и 3) оплатить на длительный срок профессиональную и дорогую команду ИТ-специалистов.
- Платформа не может остановиться на первой версии, поэтому платформу будет развивать команда.
всегда и этой команде нужно много и долго платить.
- Пользователи этой платформы также получают зарплату.
Хоть это и не перегретые программисты, но продвинутые пользователи ПО и платить им нужно соответственно.
- Поддержка пользователей и организация их обучения новым версиям также стоит денег и времени.
- Чем шире в компании используется low-code платформа, тем больше случаев она должна охватывать, т. е.
она должна становиться более универсальной и гибкой.
И чем универсальнее решение, тем оно дороже, т. е.
такая платформа будет постоянно дорожать.
Мне кажется, что единственный шанс окупить всю эту историю создания собственного решения — это продать внутреннюю low-code платформу на внешнем рынке, потому что эта платформа вряд ли когда-нибудь окупится внутри компании.
Когда использование low-code оправдано
Мы уже поняли, что сама по себе low-code платформа не принесет успеха в создании сложной ИТ-системы.Тем не менее, у low-code платформ есть важная характеристика, которую хочется использовать — визуализация алгоритма.
То, что в обычном программировании скрыто за строками кода, на платформе low-code отображается в виде диаграммы.
Это дает возможность аналитикам, владельцам продуктов, программистам и дизайнерам общаться на одном языке, глядя на диаграмму процесса.
Рабочий подход — это сочетание 1) low-code платформы визуализации процесса и 2) реализации всех функций этого процесса в виде обычного программного обеспечения.
Для этого мы используем механизмы BPMN, такие как Камунда и микросервисная архитектура.
BPMN описывает процесс, а микросервисы реализуют необходимые функции, включая интеграцию, работу с нагрузками и автотесты.
Здесь важно, что BPMN-движок не самодостаточен, он лишь организует процесс и оркестрирует. Мы не пишем код внутри Камунды, чтобы не столкнуться с отсутствием рефакторинга и автотестов.
Сочетание low-code + штатное ПО также имеет трудности.
Если подойти к процессу без должного опыта и внимания, можно создать неподкрепленную кашу из квадратов и стрелок.
Здесь нужны профессионалы, свободно владеющие нотацией BPMN, хорошие аналитики, готовые разбить процесс на части и учесть все исключительные ситуации.
Откуда тогда экономия? Экономия времени и денег достигается за счет декларативного описания процесса:
- Это видно, поэтому легче общаться внутри команды и с пользователями.
- Непрограммисты могут создать его и сделать это весьма успешно после завершения обучения работе с механизмом BPMN.
- Всегда актуальная документация в виде схемы бизнес-процессов.
Это как автодокументация, генерируемая из кода, только здесь, наоборот, код генерируется из документации.
Они никогда не могут разделиться и всегда соответствуют друг другу.
- BPMN — достаточно популярная нотация, т.е.
среди разных профессий есть специалисты.
В то же время это обозначение является всеобъемлющим; он может охватывать все, что вам нужно для вашей работы.
Заключение
На данный момент я делаю вывод, что серьезную ИТ-систему невозможно создать без хороших инженеров исключительно на low-code платформе.Low-code оправдан для простых интеграций, не критичных для бизнеса.
Однако у платформ low-code есть характеристики, которые стоит принять во внимание.
Если правильно интегрировать low-code платформу в разработку программного обеспечения, можно устранить недостатки и сэкономить деньги за счет преимуществ.
Ссылки
В опросе могут участвовать только зарегистрированные пользователи.Войти , Пожалуйста.
Какой вариант используется в вашей компании? 74,83% Без low-code 110 13,61% Low-code + вся логика в обычном коде 20 11,56% Low-code (код внутри «квадратиков») 17 Проголосовали 147 пользователей.
27 пользователей воздержались.
Теги: #Инженерные системы #Микросервисы #Анализ и проектирование систем #проектирование и рефакторинг #Визуальное программирование #low-code #it-архитектура
-
Использование Статей С Автоответчиками
19 Oct, 24 -
Всегда Старайтесь Быть Незаменимым
19 Oct, 24 -
Ньютипы Великой Силы
19 Oct, 24 -
Полноценный .Net-Клиент Для Sphinx
19 Oct, 24 -
Взлет И Падение Начинающего Фрика
19 Oct, 24
