Угрожает ли no-code классической разработке?

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

Меня зовут Вячеслав Гримальский, я основатель конструктора сайтов Creatium. Очевидно, являюсь заинтересованной стороной, но постараюсь быть объективным.

Кратко о No-code

No-code (ноукод, зерокод) — это решение задач, которые обычно решают программисты, без самого программирования, то есть разработка без кода, с помощью конструкторов.

Есть две крайности

Будучи сторонником No-code я не могу удержаться от дискуссий на эту тему, и часто встречаю две противоположные крайности.

В одной люди говорят, что No-code ни на что не годен, хайп стихнет, а люди продолжат себе спокойно программировать, как делали это всегда.

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

Только ситхи возводят все в абсолют, поэтому я хочу расставить все по своим местам.

Почему No-code становится популярным?

Причин много, приведу несколько.

Первая причина — современное бизнес-образование.

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

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

Поэтому если у вас есть идея, вам нужно собрать MVP (минимально жизнеспособный продукт), и протестировать его на реальных клиентах. Убедитесь, что они готовы за него платить, и только после этого начинать полноценную разработку в коде, зная, что вы идете в верном направлении.

Вторая причина — стоимость профессиональных разработчиков.

У многих в голове есть бизнес идеи, но зарплаты программистов настолько высокие, что без инвестиций реализовать их невозможно.

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

Третья причина — скорость разработки.

Когда речь заходит о тестировании гипотез, важна скорость, а качество остается на втором месте.

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

Все это в совокупности создает спрос на разработку без кода. Но не все так гладко, как может показаться.

Актуальные проблемы No-code

Давайте взглянем на обратную сторону, и для симметрии приведем три недостатка, которые могут заставить вас отказаться от No-code.

Первый недостаток — зависимость от конструкторов

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

У вас нет доступа к коду, и если по какой-то причине не работает конструктор, то и ваш проект тоже работать не будет. Другими словами, проблемы конструктора — и ваши проблемы тоже.

Второй недостаток — ограниченные возможности

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

Приходится идти на компромиссы и искать обходные пути, либо совсем отказываться от разработки без кода.

Третий недостаток — плохая масштабируемость

Чем сложнее проект, тем больше вероятность потерпеть фиаско, реализуя его на конструкторах. И тем медленнее он будет работать, а средств оптимизации у вас мало, поскольку нет доступа к коду.

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

Со временем No-code решения становятся более надежными, масштабируемыми и гибкими, но минусы все равно есть.

Может ли No-code заменить программирование?

По моей субъективной оценке, из того, что может сделать профессиональный разработчик, повторить в No-code можно только несколько процентов. Я сам разработчик, и представляю разницу.

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

Из недавнего
Из недавнего

Аргумент справедливый, но тут неправильной поставлен сам вопрос.

Правильный вопрос выглядит так:

А может ли программирование заменить No-code?

Когда кто-то решает свою задачу на конструкторе, в мире становится одной задачей меньше для программистов. Это может показаться каплей в море, но это то, что происходит.

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

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

Остановится этот процесс только если хорошие программисты вдруг станут намного дешевле. Тогда потребность в No-code может упасть, а до тех пор спрос будет расти, поскольку для целого ряда задач это быстрее и дешевле.

Никто никого не заменит

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

В конце концов кто-то должен разрабатывать сами No-code инструменты.

Если вам интересна тема No-code, присоединяйтесь к телеграм-каналам «Программист без кода» и «Зерокодер».

35
64 комментария

Любой кто работал в разработке более-менее крупных систем понимает, что никаких подобных конструкторов там никогда не будет. Периодически в мире всегда возникало желание избавиться от кодинга, ручного ввода разметки и т.п. в сторону подобных решений. И к чему это привело? Помню, про Dreamviewer в свое время яростно кричали как про инструмент, который позволит избавиться от написания html/css и т.п. На выходе в результате получили почти unsupported решения. Вспомним примеры из Desktop: Winforms предлагал создавать приложения для Win при помощи подобного конструктора со стандартными элементами. Потом все равно ушли в сторону WPF с XAML-разметкой, так как это гораздо более гибко, с ужесточением требований заказчиков и расширением возможностей по разработке, усложнением дизайнов использовать типовые элементы редактора стало просто нереально. И куча таких примеров. Это если ещё не вдаваться в подробности про back-end (архитектура, нагрузка, интеграция, масштабирование и т.п ). Для мелкого бизнеса может и подойдут простенькие конструкторы, которые, к слову, есть и сейчас. Но для серьезных решений это всегда будет только кодинг. Причем команда разработки - это не только программисты, это дизайн, аналитика, тестирование, нагрузка... Это все конструктором просто не заменить. А учитывая, что иногда требования заказчика даже формализовать сложно, то ни о каких конструкторах речи вообще идти не может ) Да что говорить, все профессиональные инструменты для разработки сейчас уходят в сторону командных строк, а не визуальных интерфейсов (менеджеры пакетов и т.п.)

43
Ответить

Не совсем согласен. Есть, например, Microsoft Access, на котором можно сделать законченное многопользовательское СУБД под многие задачи без кодирования на VBA. А если по ODBC прикрутить какую-нибудь SQL - то масштабировать можно до уровня среднего предприятия. Dreamviewer был вполне себе нормальным WYSIWYG в своё время - уж получше Microsoft FrontPage.

1
Ответить

Верно, разработчикам пока не о чем переживать

1
Ответить

Ну окей, я работаю в компании, которая разрабатывает системы ДБО. Достаточно сложно? 
И вот последнее время при реализации каких либо новых банковских продуктов в системе все чаще используется внутренний конструктор документов. Изначально он был придуман под нужды заказчиков, чтобы они могли на нем сочинять какие либо свои нестандартные банковские документы, впоследствии его допилили до возможности создать полноценные новые документы, справочники, с контролем реквизитов и всякое такое. Как итог - разработка и вывод в прод нового функционала значительно ускорилась
Понятно, что никто не будет целиком и полностью разрабатывать системы целиком на подобном подходе, но упростить жизнь разработке такие инструменты более чем способны.

Ответить

Комментарий недоступен

7
Ответить

Действительно похоже! Google переводчик не избавил мир от профессиональных переводчиков, но все-таки значительную часть работы по переводам во всем мире взял на себя.

12
Ответить

Как по мне no/low-code хрень полнейшая. Если запиливать всякие сайтики или помойные приложения-однодневки — да, шансы ещё есть. Когда же требуется нормальный бэкэнд написать для производства, то это выглядит как минимум смешно.

В своём лучшем исполнении no/low-code может в максимуме достичь аналогов фреймворков по работе с БД, где знание SQL не обязательное. Но производительность такого куска кода будет не высокой. Если бизнес устраивают такие издержки, то будет и жизнь у no/low-code.

7
Ответить