Прежде всего, хочу отметить, что я с командой разрабатываем инструмент no‑code, и считаю, что no‑code платформа имеет хорошие перспективы своего развития.
Однако в последнее время появилось множество не совсем точной, а часто и мифологической, информации о платформе. Это способствует завышенным ожиданиям у новичков. Такие мифы продуцируются как разработчиками no‑code, так и всевозможными курсами по обучению. И носят скорее рекламный характер, чем реальные характеристики инструментов.
Прежде чем анализировать мифы рассмотрим цикл разработки приложений на коде. 1) разработка UX дизайна (40 часов), 2) разработка UI дизайна (40 часов), 3) программирование бэкенда (120 часов), 4) программирование приложения для андроида (100 часов), 5) программирование приложения для iOs (100 часов), 6) тестирование (40 часов). Здесь трудоемкость каждого вида работ дана в часах для несложного приложения в 10 — 15 экранов. Естественно при увеличении количества экранов пропорционально будет увеличиваться и трудоемкость. Здесь мы не учитываем работу PM (прожект менеджера).
Эти цифры средние по нескольким украинским аутсорсинговым IT компаниям. Порядок выполнения работ параллельно‑последовательный: последовательно выполняются UX дизайн, UI дизайн, программирование (все три типа параллельно с некоторым опережением бэкенда), тестирование. Таким образом, общая трудоемкость составляет 440 часов, а продолжительность разработки составляет 240 часов.
Сразу отметим, что здесь не рассматриваются конструкторы основанные на шаблонах типа AppsGeyser. Они создают приложение за три шага: 1) Выбрать шаблон из 30 — 50 возможных (несколько кликов); 2) Добавить контент, например, логотип приложения, название, текст и ссылки, чтобы настроить ваше мобильное приложение (порядка 10 минут); 3) Загрузить приложение в Google Play Store. Здесь действительно практически не нужны знания, получается нативное приложение. К сожалению количество шаблонов десятки, а приложений нужно разрабатывать миллионы.
Теперь рассмотрим основные мифы.
Миф 1. Для разработки приложений не нужны специфические знания
Это утверждают как всевозможные курсы no‑code, так и сайты некоторых конструкторов приложений. Например, на сайте университет зерокодинга сообщают: «Вы можете легко освоить no‑code инструменты и понять как зарабатывать на этом уже через пару недель» а на сайте конструктора Unicorn Platform (https://unicornplatform.com/) пишут «Zero skills required».
Обоснования этого заключается в том, что нужно просто перетащить нужные элементы на экран, а конструктор это мгновенно реализует.
И именно так выглядит процесс проектирования приложений на видео, демонстрирующих работу того или иного конструктора. И всевозможные курсы учат, как перетаскивать элементы в том или ином конструкторе. Вроде никакого обмана.
Но вспомним, что в цикле разработки приложений имеется разработка UX и UI дизайна. Вкратце:
UX‑дизайн (User Experience — «пользовательский опыт») отвечает за то, как приложение работает.
UI‑дизайн (User Interface — «пользовательский интерфейс») отвечает за то, как интерфейс выглядит.
При плохом UX‑дизайне с приложением будет сложно работать и не каждый пользователь сможет получить нужный результат. При плохом UI‑дизайне приложение выглядит по крайней мере некрасиво и тоже затруднена работа с ним.
Каждому виду дизайна посвящены десятки книг. Поэтому если разработчик хочет получить удобное, красивое приложение он должен знать и уметь выполнять UX / UI дизайнерские работы.
Обучают UX/UI в некоторых ВУЗах. Также существует большое множество курсов. Время на освоение навыков UX/UI дизайна с нуля на курсах занимает порядка одного года.
Кроме общих знаний по UI дизайну для разработки мобильных приложений необходимы и специфические знания. Для iOs это Human Interface Guidelines, а для Android это Material Design.
Стоит отметить, что практически все конструкторы приложений не предоставляют функционал для UX дизайна. Наверное, исключением является GoodBarber (https://www.goodbarber.com/) — «конструктор приложений без кода для людей, серьезно относящихся к дизайну и UX». А также IDE DePro в которой выделяется функционал как для UX так и для UI дизайна. DePro сейчас находится в альфа тестировании.
Кроме дизайна имеется еще больший пласт необходимых знаний — базы данных. Хотя большинство конструкторов имеют свои средства работы с таблицами и убеждают пользователей, что это не сложнее таблиц Excel. Но это не совсем так. Это кустарная реализация микроскопической части баз данных. В конструкторах предоставляется функционал для описания таблиц и наполнения их информацией (ввод данных, удаление, замена). Кстати, эти функции более полно и качественно реализованы в каждой СУБД. Вне поля внимания остаются такие аспекты БД как проектирование, запросы (SQL) и пр. Нормальное обучение работе с базами данных осуществляют ВУЗы. Хотя очень поверхностное представление можно получит на курсах за пару недель, Но делать ничего не сможете, зато будет понятно сколько нужно всего учить.
И последний гвоздь. Многим конструкторам, например Bubble, для реализации некоторых фич нужны знания языков программирования. В частности бабл использует JavaScript.
Интересно, что компании, занимающиеся no‑code разработкой, при приеме на работу предъявляют к кандидатам реальные требования. Например, в телеграмм чате «Airtable Chat & Community» компания UDTech искала no‑code dev [mid; senior], со «стеком технологий: конструкторы — Bubble/Adalo/Flutter Flow, AirTable, Tilda; данные — DB, SQL, noSQL, микросервисы, REST API; языки — JS,.Net, Python».
Таким образом, после курсов по конструкторам вы сможете (не факт) разрабатывать простые плохо и медленно работающие, некрасивые приложения. И это будет до тех пор пока не освоите указанные выше знания.
Миф 2. Конструкторы позволяют в 10 и более раз ускорить и удешевить разработку приложений
Действительно, конструкторы позволяют ускорить разработку, но не в 10 – 20 раз.
Для оценки реального ускорения вспомним цикл разработки приложений на коде.
Из него видно, что общая длительность будет 80 (UX/UI) + 120 (программирование бэкенда) + 40 (тестирование) = 240 часов. При использовании конструкторов (которые позволяют разрабатывать и бэкенд) у нас время разработки будет только 80 часов. Итого мы в 3 раза быстрее разработаем с помощью no-code конструктора, чем на коде.
Оценим насколько дешевле разрабатывать конструкторами. В этом случае общие трудозатраты составят 440 часов. Т.е. с no-code будет дешевле в 5 с половиной раза.
Это предельные цифры. Дальнейшее ускорение разработки возможно лишь за счет уменьшения времени на выполнение UX/UI дизайна. Но в этом случае будет ухудшаться качество приложения, вплоть до отказа его использовать.
Еще одним мифом из области скорости разработки являются сообщения на некоторых курсах no-code, что по завершению обучения будет написана копия airbnb (Uber, Amazon Marketplace, …). В компании Airbnb служба IT составляет более 500 человек, которые постоянно совершенствуют продукт. И никто не собирается заменить их "преподавателем" с курсов.
Миф 3. Приложения, созданные конструкторами, не уступают нативным на разработанным на коде
Сравнивать приложения можно по различным параметрам. Мы будем сравнивать по функциональности, которую можно характеризовать количеством (разнообразием) функций доступных при разработке приложений и качеством выполнения этих функций приложением.
Качество выполнения функций зависит от технологии на основе которой построен конструктор мобильных приложений. Основными технологиями являются:
PWA (Progressive Web Application). Применяют такие конструкторы как Bubble, Glide.
Кроссплатформенные фреймворки типа React Native, Flutter. Использует такие конструкторы как Adalo, Andromo.
Нативный код. Swift для iOS и Kotlin для Android. Нативный код формирует, например, AppMaster, IDE DePro.
PWA при всех его достоинствах все‑таки разрабатывается WEB средствами и выполняется в браузере. Поэтому как бы не были визуально его элементы похожи на соответствующие в нативных приложениях, они функционируют по‑другому (не так плавно работают, нет многих возможностей и т. п.). Также не поддерживаются жесты широко используемые в нативных приложениях.
Конструкторы, использующие кроссплатформенные фреймворки создают приложения, работающие с нативными элементами. Но эти приложения имеют недостатки: размер приложений больше чем у нативных; производительность — ниже; безопасность — невысокая; увеличенный разряд аккумулятора. При этом React Native существенно уступает Flutter по производительности и размеру приложений.
По какой бы технологии не строились конструкторы все они имеют ограничение по разнообразию функционала. Все они ориентированы на создание MVP. т. е. существенно уступают нативным приложениям. Наверное, исключением является IDE DePro, которая, предположительно, может разрабатывать приложения уровня написанных на коде.
Миф 4. Легко масштабировать и расширять
Многие (наверное, каждый третий) конструкторы заявляют, что с их помощью легко масштабировать и расширять приложения. Масштабируемость предполагает возможность приложения увеличивать производительность пропорционально дополнительным ресурсам. А расширяемость — способность увеличивать функциональность приложения.
По факту конструкторы с собственным блоком обработки данных не обладают свойством масштабируемости. Даже лучшие, такие как Адало и Bubble, с использованием собственных инструментов работы с данными начинают очень медленно работать при росте количества пользователей более 1000. Для обеспечения работы с большими наборами данных конструкторы используют сторонние инструменты. Но не все конструкторы БД обладают свойством масштабируемости. Кроме того применение сторонних инструментов ведет к дополнительной стоимости.
Одним из активно применяемых в последнее время no‑code инструментов для разработки бэкенда является Xano. На сайте задекларировано масштабируемость, в т.ч. горизонтальная. Однако в документации нет описания для реализации этого свойства (возможно пока). Контекстно подразумевается масштабируемость за счет использования PostgreSQL. Горизонтальное масштабирование, возможно, понимается возможность динамически менять регион сервера. Однако полноценной масштабируемости пока не достигнуто. Вертикальная и горизонтальная масштабируемость задекларирована и на сайте IDE DePro.
Еще хуже с расширяемостью. Фаворитами среди конструкторов являются Glide, Adalo, Bubble. Все остальные менее эффективны и не имеют значительной клиентской базы. Но даже эти конструкторы между собой не конкурируют. Каждый используется в своем диапазоне сложности приложений, которые с их помощью можно создать. И если возможностей какого ни будь конструктора недостаточно просто переходят на другой конструктор и, в конце концов, после MVP на код.
Миф 5. No-code разработчиков – миллионы
Например, на сайте конструктора bravostudio (https://www.bravostudio.app ) указано, что у них 100+ тысяч пользователей. Время разработки приложения — несколько недель. Значит, в течение года они создадут порядка миллиона приложений. Andromo (https://www.andromo.com/) — «более миллиона пользователей», они «создают несколько приложений в кратчайшие сроки». Адало на своем сайте вообще прямо заявляет, что ее пользователи создали более миллиона приложений. Существует множество и других конструкторов. И суммарно можно ожидать, что на no‑code разработано несколько миллионов приложений.
Однако, как известно, сейчас в Google Play Store каждый год добавляется около 1 миллиона приложений (включая игры). Еще больше приложений удаляется. Это связано с внедрением новых политик и правил безопасности и более автоматизированной проверкой приложений, которая часто удаляет даже нормальные и легальные программы. В результате в Google Play Store сейчас порядка 2,6 млн. приложений. Еще меньше приложений в App Store.
Что характерно, в статистике поступления в сторы новых приложений нет никаких всплесков увеличения их количества. Значит в Google Play Store доля приложений, разработанных с помощью конструкторов, очень маленькая.
Поэтому и количество no‑code разработчиков и количество разработанных ими приложений очень сильно завышено.
Заключение
1. No‑code инструменты разработки мобильных приложений будут совершенствоваться и займут свою нишу среди остальных инструментов.
2. Маркетинговые мифологемы возможностей no‑code инструментов приводят к завышенным ожиданиям потенциальных клиентов и, как следствие, разочарованию и отказу от них.
