Антихрупкость в IT - Александр Васильевич Бындю

Непрограммистов, которые создают бизнес-приложения в визуальных редакторах, назвали Citizen Integrator или Citizen Developer[86]. Слоганы продавцов этой темы сводятся к следующему:

…with no-code/low-code platforms, anyone can build applications without software expertise, significantly faster, and at a fraction of the cost.

Давайте разберёмся, насколько правдивы эти обещания, а также где и как стоит применять low-code платформы, чтобы не выстрелить себе в ногу.

Зачем бизнесу low-code платформы?

Текущий всплеск интереса к low-code, скорее всего, связан с тем, что дорогие программисты стали ещё дороже, но и дорогих в свободном доступе на рынке не найдёшь. Не-IT-компании не могут нанять вообще никого стоящего, а проекты при этом делать надо. Даже аутсорсеров найти непросто, потому что их кадры тоже размываются из-за желания крупных компаний развивать собственное IT, и для этого идёт найм сотнями и тысячами.

Цифровая трансформация прорвалась даже в те компании, которые до последнего момента пытались обходить её стороной. В итоге IT-проекты есть, деньги есть, а рук нет. Что делать? Кажется выгодным использовать low-code/no-code платформу, чтобы дешёвые и многочисленные неайтишники могли создавать бизнес-приложения.

На эту тему в Москве недавно прошла конференция «LOW-CODE 2021»[87], где программный директор серии практических конференций издательства «Открытые системы» Дмитрий Волков написал такую вводную:

«Апологеты преподносят low-code как главный инструмент масштабной цифровой трансформации. Критики указывают на лоскутность, низкую производительность, отсутствие должной интеграции, проблемы с обслуживанием доморощенных решений, безопасностью и надёжностью. Поэтому, прежде чем применять low-code/no-code, посетите нашу конференцию».

Я побуду в роли критика, но заодно опишу способ применения low-code платформы, при котором это применение будет эффективно и оправданно.

Причина провала предыдущих подходов к low-code

Low-code подкупает, когда видишь реализацию простой системы без кода и понимаешь, что её создали в визуальном редакторе без программиста. А это дёшево и быстро. Возникает естественное желание масштабировать этот подход на все задачи бизнеса.

Приступ любви к low-code заканчивается тем, что low-code подход не может преодолеть проблему увеличения сложности, которая нелинейно растёт во время создания IT-решения. В случае с визуальным программированием сложность растёт слишком быстро и система становится неуправляемой (рис. 58).

Рис. 58. Зависимость сложности системы от количества фич при стандартном и low-code подходах

До определённого момента (до пересечения графиков) такое решение будет обгонять обычный подход по скорости разработки, то есть вы быстрее выйдете на рынок. Но плюсы визуального программирования быстро заканчиваются, и «визуальное» решение стремительно переходит в неуправляемое месиво.

Романтика low-code разбивается о суровую действительность, где IT должно помогать бизнесу создавать большие и сложные IT-системы с постоянно меняющимися требованиями и при этом выдерживать множество внутренних и внешних SLA.

Выглядит так, что для «простых» проектов low-code может подойти, а для «сложных» перестаёт работать. Давайте определим, что такое простая и сложная IT-система.

1. Простая система: решение локального уровня для пары сотрудников. Тётя Маша из бухгалтерии хочет, чтобы ей приходила СМС, когда в почту прилетает письмо от шефа. Она идёт в Zapier и «программирует» себе пару триггеров и интеграций. Бизнес от этой автоматизации не зависит, логики минимум. Если требования тёти Маши поменяются, то изменения можно будет легко внести самой тёте Маше. Если триггер сломается, то никто в компании и среди клиентов бизнеса этого не ощутит.

2. Сложная система: (критичное) решение на уровне бизнеса. От этих систем зависит прибыль бизнеса и репутация бренда. Такие системы часто меняются, и изменения нужно вносить быстро и безопасно, то есть быть готовым качественно и быстро тестировать. Эти системы подвергаются колебательным нагрузкам, их нужно уметь горизонтально масштабировать.

Простые системы можно и нужно делать на low-code платформах без программистов, а вот со сложными возникают проблемы, которые никак не могут решить создатели low-code платформ:

1. Рефакторинг и уменьшение технического долга (раздел ll, глава 5) или невозможны, или затруднены. Бизнесу всё равно, сделали систему программисты, написав код, или аналитики, накидав квадратиков в визуальном редакторе. Изменения нужно вносить быстро и безопасно. На данный момент ни одна low-code платформа не имеет средств рефакторинга, хотя бы приближённых к уровню продвинутых IDE.

2. Автотестирование невозможно или крайне затруднено. Без автотестов невозможно безопасно вносить изменения. Если нет автотестов, то мы возвращаемся в те доисторические времена, когда для релиза одной фичи нужен полный ручной регресс всей системы. Заказчик, который умеет считать деньги, не будет за это платить.

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

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

Получается, сложное решение на low-code платформе – это «readonly-код» с очень высокой стоимостью внесения изменений. Это ли надо бизнесу?

РДС (Россия делает сама)

А может, проблема в том, что low-code платформы слишком универсальны? Логичным ответом на это будет желание создать свою платформу, под себя.

Я общаюсь с разными компаниями и вижу, что они создают собственные low-code решения. Такие решения могут появляться в следствие естественной эволюции микросервисной архитектуры в оркестратор бизнес-сервисов (раздел ll, глава 1).

При создании low-code платформы для себя появляется фактор стоимости, которую придется заплатить за создание полноценного IT-продукта. Затраты на разработку такой платформы, на мой взгляд, неоправданно высокие. Давайте рассмотрим, из чего состоят затраты.

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

2. Платформа не может остановиться на первой версии, поэтому команда будет разрабатывать платформу… всегда, и платить этой команде нужно много и долго.

3. Пользователи этой платформы тоже получают зарплату. Их зарплаты ниже, чем у «перегретых» программистов, но это все же продвинутые пользователи ПО, и платить им нужно соответственно.

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

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

При этом