Почему бы просто не перейти на no-code — мнения Reddit

Недавно на Reddit появился новый кейс. Клиент предложил автору использовать no-code вместо классической разработки:

Я разработчик с многолетним опытом в Java (в основном использую Spring и Java EE). Новый клиент предложил нам использовать no-code для серверной части вместо разработки.

Есть ли у вас похожий опыт работы? И если да, то с какими проблемами вы столкнулись? Я вижу несколько:

• привязка к решению;
• производительность;
• недостаточная функциональность;
• стоимость.

Вот что рассказали на эту тему эксперты.

Одни предлагают не отвергать идею

_jetrun

Я думаю, нормально указывать на потенциальные подводные. Но кто сказал, что они станут проблемой для вашего клиента?

Попробуйте не отвергать его предложение сразу — если только вы не безупречно понимаете проблему клиента возможности no-code решений. Предложите создать прототип приложения «без кода», возможно, все получится, и вы сможете сэкономить. Но уточните, что если идея не сработает, вы перейдете на классическую разработку (при этом заказчик потеряет часть времени и денег).

simonsays1111

Все здесь советуют не использовать no-code, но если вы хотите, чтобы клиент вас послушал, не отклоняйте его предложение сразу.

No-code существует не без причины. Поэтому сперва расскажите клиенту, для каких решений он подойдет, например, для прототипирования или приложений, которые потом не нужно кастомизировать и поддерживать. Скорее всего, после этого клиент сам скажет, что его приложение не такое, и no-code не для него.

Ну, или с небольшой долей вероятности это «тот самый» случай, и тогда, правда, лучше обойтись без классической разработки.

BrandonMartinez-jar

Решение простое, у вашего клиента есть 3 варианта:

• Напишите бэкенд на базе no-code решения. Поначалу это может сработать, но по мере масштабирования и привлечения большого числа пользователей повлечет за собой дополнительные расходы — из-за проблем с производительностью и обслуживанием.
• Напишите бэкенд на Java. Это займет больше времени и потребует больше ресурсов. Но с хорошей документацией любые возникающие проблемы, вероятно, будет проще решать, что, несомненно, поднимет производительность.
• Создайте демоверсию на базе no-code решения, чтобы закрыть основные потребности пользователей. И перейдите к разработке более сложного продукта на Java.

RepliesOnlyToIdiots (разработчик no-code платформы)

<…> No-code платформы заботятся о многом за вас.

<…> Мы можем обновлять пакеты, при этом нашим клиентам не приходится шевелить и пальцем. То есть у вас почти нет потребности в техобслуживании: провайдер no-code решение делает что-то один раз, и все клиенты получают обновление. Провайдер также отслеживает и обрабатывает CVE за вас. <…>

Наконец, по крайней мере, наша платформа позволяет вам переходить на язык программирования при необходимости — например, для работы со специфическими, старыми системами или новинками, которые выпустили пять минут назад.

Другие — перечисляют недостатки no-code по сравнению с обычной разработкой

sqlphilosopher

Проблема в законе дырявых абстракций. No-code — абстракция очень высокого уровня, которая часто «протекает».

То есть рано или поздно, когда вы попытаетесь сделать что-то нестандартное и сложное, то обязательно полезете смотреть, что находится внутри платформы, и будете писать код. <…>

nekokattt

Добавьте к своим аргументам:

• медленный;
• сложно использовать повторно;
• куда менее развит, чем классическая разработка;
• выходит из строя, когда вы пытаетесь сделать что-то «непреднамеренное»;
• продукт не такой прозрачный, что приводит к проблемам с безопасностью.

Просто посмотрите на все no-code сайты, которые писали раньше. И вспомните, как приходится страдать разработчикам, когда дело доходит до их обслуживания и миграции.

catom3

Я бы сказал, что проблема no-code решений в том, что они редко покрывают все бизнес-требования. Слишком много людей не понимают этого или отказываются признавать.

Начинать с no-code довольно просто, и это вводит многих в заблуждение. Когда неспециалист видит презентацию, в которой парень создает несколько рабочих форм в течение нескольких часов, то думает, что нашел Грааль. И начинает спрашивать, почему разработчики тратят на них так много времени. Но со временем настройки любого продукта становятся сложными, поддерживать их без классической разработки становится все труднее.

И к сожалению, рано или поздно, мы сталкиваемся с требованиями, которые невозможно исполнить без классической разработки:

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

<…> Всего раз мне было удобнее использовать no-code. Мы не стали делать что-то, что напрямую не поддерживалось инструментом. Получалось без проблем создать новую форму или обработать небольшой объем данных.