Угрожает ли 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 инструменты.
Любой кто работал в разработке более-менее крупных систем понимает, что никаких подобных конструкторов там никогда не будет. Периодически в мире всегда возникало желание избавиться от кодинга, ручного ввода разметки и т.п. в сторону подобных решений. И к чему это привело? Помню, про Dreamviewer в свое время яростно кричали как про инструмент, который позволит избавиться от написания html/css и т.п. На выходе в результате получили почти unsupported решения. Вспомним примеры из Desktop: Winforms предлагал создавать приложения для Win при помощи подобного конструктора со стандартными элементами. Потом все равно ушли в сторону WPF с XAML-разметкой, так как это гораздо более гибко, с ужесточением требований заказчиков и расширением возможностей по разработке, усложнением дизайнов использовать типовые элементы редактора стало просто нереально. И куча таких примеров. Это если ещё не вдаваться в подробности про back-end (архитектура, нагрузка, интеграция, масштабирование и т.п ). Для мелкого бизнеса может и подойдут простенькие конструкторы, которые, к слову, есть и сейчас. Но для серьезных решений это всегда будет только кодинг. Причем команда разработки - это не только программисты, это дизайн, аналитика, тестирование, нагрузка... Это все конструктором просто не заменить. А учитывая, что иногда требования заказчика даже формализовать сложно, то ни о каких конструкторах речи вообще идти не может ) Да что говорить, все профессиональные инструменты для разработки сейчас уходят в сторону командных строк, а не визуальных интерфейсов (менеджеры пакетов и т.п.)
Не совсем согласен. Есть, например, Microsoft Access, на котором можно сделать законченное многопользовательское СУБД под многие задачи без кодирования на VBA. А если по ODBC прикрутить какую-нибудь SQL - то масштабировать можно до уровня среднего предприятия. Dreamviewer был вполне себе нормальным WYSIWYG в своё время - уж получше Microsoft FrontPage.
FrontPage - признайтесь, вы Тирекс, Брахиозавр или более древний вид? :-)))
А Кофекап помните, гы?
Можно, но парадокс в том, что на том же самом акцессе пользуясь VBA многие задачи решить банально проще, чем пытаясь всё сделать исключительно на формочках, отчётах и визуальном редакторе запросов. Там, где достаточно написанной за полчаса простой функции на пол экрана - могли бы потребоваться несколько дней ковыряния и экспериментов методом тыка в визуальных редакторах, а на выходе может получиться совершенно не поддающаяся пониманию (а значит и поддержке) мешанина из очень навороченных sql-запросов.
На моём опыте тот же Access позволяет сократить в разы написания кода - при всём знании sql/vba и т.д. А в большинстве случаев хватает просто подключить внешние таблицы со связями и правилами заполнения по odbc и научить пользователей как их заполнять.
Какие удивительные решения вы вспоминаете. Access, серьезно? На нем с самого начала нельзя было ничего нормального разработать. А сейчас данных стало ещё больше