Почему бы просто не перейти на no-code — мнения Reddit
Собрали мнения специалистов на тему, можно ли полностью отказаться от разработки и перейти на no-code сервисы.
343 открытий2К показов
Недавно на Reddit появился новый кейс. Клиент предложил автору использовать no-code вместо классической разработки:
Я разработчик с многолетним опытом в Java (в основном использую Spring и Java EE). Новый клиент предложил нам использовать no-code для серверной части вместо разработки.
Есть ли у вас похожий опыт работы? И если да, то с какими проблемами вы столкнулись? Я вижу несколько:
- привязка к решению;
- производительность;
- недостаточная функциональность;
- стоимость.
Вот что рассказали на эту тему эксперты.
Одни предлагают не отвергать идею
Я думаю, нормально указывать на потенциальные подводные. Но кто сказал, что они станут проблемой для вашего клиента?
Попробуйте не отвергать его предложение сразу — если только вы не безупречно понимаете проблему клиента возможности 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. Мы не стали делать что-то, что напрямую не поддерживалось инструментом. Получалось без проблем создать новую форму или обработать небольшой объем данных.
343 открытий2К показов