О no-code программировании говорят с периодической регулярностью ещё с 1980-х. В 1982 Джеймс Мартин (James Martin) даже выпускает книгу, посвященную разработке без разработчиков «Разработка приложений без программистов» (Application Development without Programmers). Создавалась масса инструментов, позволяющих разрабатывать комплексные инструменты без кода или с его минимальными вкраплением. Некоторые ниши no-code платформам уже удалось захватить. Например, Tilda — конструктор лендингов, основанный в 2014 году.
Но с момента выхода книги 42 года назад мы до сих пор видим немало вакансий разработчиков, и высокую конкуренцию на рынке труда за кадры именно в направлении классической code-разработки. Кроме всего прочего, появляются и обретают популярность новые языки программирования. Те же Go и Rust.
Почему же до сих пор нет универсальных инструментов, которые бы заменили архаичное написание кода в IDE? На мой взгляд, есть минимум шесть причин, почему эти инструменты всё ещё работают в определенных нишах, и со временем ничего не поменяется.
Первая причина — низкая производительность no-code решений
По сути каждый компонент no-code системы — это отдельный микросервис, который взаимодействует по внутреннему протоколу с другим микросервисом. И если на процессоре сложение двух чисел будет выглядеть так:
то в no-code системе так:
Чем сложнее и обширнее логика, реализованная средствами no-code программирования, тем больше мы получаем коммуникационных задержек в таких алгоритмах.
Возможное решение такой проблемы — трансляция инструкций конструктора в код и исполнение уже транслируемого кода. Однако как бы не был оптимизирован код внутри, разработчику важно понимать, как написать оптимальный алгоритм.
Так как я python-разработчик, приведу пример реализации алгоритма поиска простых чисел на этом языке. Для получения количества простых чисел в заданном диапазоне можно использовать такой алгоритм:
def is_prime(n: int) -> int:
for i in range(2, n//2+1):
if not n%i:
return 0
return 1
primes_count = 0
for i in range(2, 250001):
primes_count += is_prime(i)
print(primes_count)При этом скорость его выполнения на моём ноутбуке будет 57.7 секунд. Или оптимизировать алгоритм таким образом:
import math
def is_prime(n: int) -> int:
a=2
while a<=math.sqrt(n):
if n%a<1:
return 0
a += 1
return 1 if n>1 else 0
primes_count = 0
for i in range(2, 250001):
primes_count += is_prime(i)
print(primes_count)И выполнить его за 1.3 секунды.
На каком бы языке я не выполнил эту задачу, разница во времени выполнения этих двух алгоритмов будет существенная. И так мы понимаем, что наш no-code программист должен не просто составлять блоки в визуальном редакторе, но и понимать суть алгоритма, который он реализует.
Вторая причина — неудобство отладки no-code решений
Допустим, вы пишете no-code приложение, которое развивалось и увеличивалось годами. И есть конкретная задача: при заполнении поля, в случае, если одно из полей не указано, результаты не отправляются на e-mail, но при этом рассылаются по всем остальным источникам рассылки. Мы не знаем, откуда конкретно начинать, и смотрим на наше приложение целиком:
Кажется, у нас небольшая проблема. Возможно, наш no-code инструмент поддерживает модульность, которую использовали на протяжении всего цикла разработки и поддерживает инструменты отладки. Намного легче ли станет наша участь?
Даже если конкретный инструмент даёт возможность пошаговой отладки, менять мы сможем только состояние на входе в блоки, предоставленные no-code инструментом, и на выходе из них. Если внутри какого-то блока, который был написан не нами, мы получаем поведение, которое мы не ожидаем, понять, что в нём происходит, и почему результат отличается от ожидаемого, невозможно.
Мы можем столкнуться с похожей ситуацией, используя проприетарные компоненты в нашей системе, написанной классическим способом. Но в этом случае есть вариант воспользоваться strace и отследить ситуацию на уровне ОС, что нам вряд ли дадут сделать на сторонней платформе.
Также не стоит забывать о таком инструменте, как тесты, чтобы можно было автоматически проверять работоспособность нашего продукта и его модулей с учётом крайних случаев без привлечения ручного процесса проверки.
Третья причина — нет версионирования, сохранение состояний
В классической разработке с кодом есть системы контроля версий, и любой неудачный релиз можно быстро отозвать в пользу предыдущего, стабильного. Более того, система контроля версий позволяет разрабатывать продукт нескольким разработчикам, а то и нескольким сотням, не создавая помех друг другу. Конфликты будут решены в процессе слияния разных веток, созданных разработчиками в одну главную. А как решить вопрос разработки несколькими специалистами в no-code решении так, чтобы это не создало дефектов в итоговом продукте?
Кроме версионирования, аналог которого можно реализовать в no-code платформе, в процессе деплоя участвует не только система контроля версий, у нас может измениться структура данных в БД, источники файловых бакетов и так далее. В процессе классической разработки все тонкости релиза и возврата к предыдущему состоянию без блокировки работы приложения обычно учитываются. Какие инструменты и в каком виде будет предоставлять для этого no-code решение — большой вопрос. В любом случае, это будет большой и сложный инструментарий, в котором вам предстоит разобраться.
Четвёртая причина — сложность в использовании архитектурных паттернов
Как я уже говорил выше, когда рассуждал про отладку кода в no-code разработке, если решение было хорошо структурировано и граф компонентов не похож на «паутину пьяного паука», его будет легко отлаживать. А также легче доработать и переписать.
Для этого no-code разработчику важно понимать принципы чистой архитектуры и паттерны проектирования. Более того, невозможно будет воспользоваться какой-нибудь книжкой по DDD и повторить решение в точности как описано. После осмысления концепции DDD предстоит это на тот конкретный no-code инструмент, которым пользуется разработчик. Из чего можно сделать вывод, что no-code решения не только не упростят понимание и построение хорошей архитектуры, но ещё могут и усложнить этот процесс.
Пятая причина — невозможность запуска в другой среде
Нынешние популярные no-code платформы — это подписочные решения, не предполагающие возможности переноса результата разработки на другую площадку, другому вендору. По факту, если вы столкнетесь с какими-то ограничениями текущей платформы, которые не дадут развивать продукт, и найдёте более функциональную, на которую захотите перебраться, то придётся полностью описывать приложение на новой платформе. Никакой системы интеграции, общего языка описания и прочего в таких системах просто нет, так как вендоры попросту не заинтересованы в вашей свободе выбора.
Шестая причина — навыки no-code разработчика сравнимы с code
Получается, no-code разработчику нужно знать алгоритмизацию и как строить архитектуру приложения, чтобы её было удобно отлаживать и дорабатывать. Кроме того, no-code платформа не освобождает от таких вещей, как создание тестов, если вы хотите быть уверены в работоспособности своего продукта. Если no-code платформа будет standalone, то нужны компетенции по её развертыванию и интеграции с другими решениями, что используются в вашем продукте.
Кстати о standalone. Допустим, кто-то сделал opensource или проприетарную, но всё же standalone-платформу, которую легко установить себе на сервера. Это решит много проблем, описанных выше. Появляется возможность исследовать своё приложение с помощью strace в связке со всеми его компонентами. Вы сможете менять поставщика серверных мощностей и/или переносить код на собственные серверные мощности. Также это позволит настраивать деплой версий приложения прозрачным образом так, как вы хотите. Но при этом установка и интеграция платформы будет в зоне вашей ответственности, а значит вам (необязательно лично, возможно, на уровне компании) понадобятся компетенции devops’а.
В итоге необходимый объем знаний у вас будет почти таким же, как и у обычного разработчика. За исключением того, что вам нужно будет изучить какой-то язык программирования. Но это не означает, что изучение конкретной no-code платформы займёт меньше времени, чем изучение языка программирования. Если бы все no-code платформы были доступны без базовой подготовки каждому, фриланс-биржи не были бы полны объявлениями о создании сайтов на Tilda.
И всё-таки no-code популярен. Почему?
Так почему же последние лет 10 лет на рынке идет новая волна популярности no-code? На мой взгляд, ответ кроется в огромном количестве курсов по быстрому входу в IT. No-code подход выглядит как манящая уловка от маркетологов, продающих светлое будущее в IT. Многих пугает нагромождение непонятных слов и символов. Куда приятнее и проще для человека, никогда не занимавшегося разработкой, выглядит набор логических блоков соединенных «проводами». Эта кажущаяся простота привлекает много внимания начинающих no-code разработчиков, а большое количество неофитов в no-code привлекает всё больше вендоров, желающих создать своё no-code-решение.
Стоит ли новичку в разработке начинать с no-code?
Если вы хотите строить большие, комплексные приложения — однозначно, нет. Объем информации, который нужно будет усвоить, чтобы разрабатывать крупные проекты в no-code, будет ничуть не меньше, чем в стандартном подходе с написанием кода. Возможно, будет легче из-за отсутствия ментального барьера перед началом разработки на незнакомом вам языке. Но преодоление этого ментального барьера позволит сразу включиться в мир серьезной разработки.
Так ли плохи ли no-code решения?
Конечно, нет. No-code — это хорошее решение для ряда направлений в разработке, не требующих сложных технических знаний. В no-code можно строить базовую скриптовую логику, как пример, тут можно привести BluePrints из Unreal Engine. По этой же причине это может быть отличным решением для интеграторов, когда большой и сложный продукт надо подключить к системам заказчика, например, для сбора данных.
Кроме того, как в случае с Tilda, это хорошее решение для создания визуала приложения. Да, сайты получаются похожими друг на друга, но для конечного потребителя это даже скорее во благо, так как понятна логика навигации. Если вы выбираете направление в IT, которое закрывают существующие no-code решения, и понимаете, что вам не требуется более широкого спектра фундаментальных знаний разработчика, то можно начать свой путь в IT и с no-code платформ.
А что будет завтра?
Мы разобрались с текущим состоянием no-code разработки, но технологии развиваются. Можно ли будет писать комплексные приложения без кода, знания архитектуры и отладки?
По подсчетам литераторов в мировой литературе есть всего 36 сюжетов, и все книги — это вариации этих базовых сюжетов. Так же и количество задач, которые мы решаем посредством программирования, ограничено, а все новые задачи можно решить алгоритмами для ранее решенных задач.
Конечно, с консолидацией существующих разработок в неких центральных базах и с развитием AI, мы получим no-code платформу, в которой можно будет декларативно описывать требуемый продукт. Как это будет выглядеть: на базе построения блоков, как это делают современные no-code системы? Или на основании промптов, как это делают AI? А, может, так, как мы пока себе даже не представляем. Ведь технологии не стоят на месте, так что уверен, однажды мы придём к настоящему no-code, где вся машинерия будет выполняться на стороне техники. Ну, а пока — индустрии нужны программисты!