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-код» с очень высокой стоимостью внесения изменений. Это ли надо бизнесу?