8 вещей, которые не нравятся разработчикам в Low-Code и No-Code

Производители инструментов с низким кодом и без кода (LC / NC) сталкиваются с трудной борьбой, пытаясь убедить людей, особенно профессиональных разработчиков, использовать или даже просто попробовать их инструменты и платформы. Несколько платформ проникли на этот рынок, но большая часть разработки программного обеспечения, несомненно, по-прежнему выполняется профессионалами, пишущими код.

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

Я разговаривал с разработчиками, читал статьи и просматривал дискуссионные форумы, чтобы получить ответы на эти вопросы, и сопоставил некоторые из выдвинутых причин.

Это не помогает их карьере

Изучение инструментов low-code может потребовать значительных затрат времени и усилий, но профессиональная ценность изучения конкретного инструмента LC/NC невелика. Даже в том редком случае, когда компания по разработке программного обеспечения использует инструмент LC/NC, навыки, которые разработчик приобретает при изучении этого инструмента, скорее всего, не потребуются следующему работодателю.

Большинство вакансий в сфере разработки требуют глубоких знаний и опыта работы с широко используемыми языками и фреймворками, и ни один инструмент с низким кодом не используется так широко, как React, Angular, Python, Java или C#.

Очень немногие рабочие места разработчиков требуют знания инструментов LC/NC, и вероятность того, что разработчик найдет лучшую работу или заработает больше денег, зная инструмент LC/NC, очень мала. Таким образом, разработчикам лучше потратить время на изучение и совершенствование одного из бесчисленного множества навыков, фреймворков и языков, пользующихся большим спросом на рынке труда.

Разработчики годами учились писать код

Почти 70% разработчиков, принявших участие в Опросе разработчиков Stack Overflow 2021, заявили, что имеют степень бакалавра или выше в области компьютерных наук или смежных дисциплин. Это означает, что большинство разработчиков потратили годы на изучение программирования, изучение различных языков, системных архитектур и вообще на практику и совершенствование искусства написания кода. Использование инструментов LC/NC часто означает отказ от преимуществ, которые представляют их с трудом заработанный опыт и инвестиции. Поэтому неудивительно, что большинство разработчиков предпочитают делать ставку на бесценные навыки, которые они уже с трудом приобрели.

Если инструменты LC/NC действительно обеспечат то, что они обещают, то в будущем больше не потребуется писать код для создания приложений. Программирование перейдет на более высокий уровень абстракции, и приложения будут собираться из существующих компонентов, а не кодироваться. Таким образом, программисты, по сути, угрожают сделать свои с трудом заработанные навыки излишними, используя и поддерживая более широкое использование инструментов LC/NC. Поэтому на самом деле в их интересах, чтобы инструменты LC/NC не увенчались успехом.

Разработчики меньше заботятся о скорости

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

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

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

Таким образом, маркетинг скорости разработки инструментов LC/NC для разработчиков может не иметь ожидаемого эффекта.

Разработчики любят программировать

Люди расплывчаты и эмоциональны. У них противоречивые приоритеты, они часто неуверенны, неточны и лгут. Часто они даже не знают, что они делают и почему они это делают. Люди могут быть очень запутанными. Компьютеры намного проще. Компьютер просто следует инструкциям, данным ему программистом, и если эти инструкции неверны, программа не работает. Точность в определении набора задач и наблюдение за их немедленным и точным выполнением дает многим людям чувство безопасности и радости.

В кодировании есть творческий элемент, который действительно нравится многим разработчикам. Программирование — это очень сложная головоломка, полная головоломок, состоящая из десятков модулей, нескольких слоев и тысяч строк кода. Одно веб-приложение может легко включать пять или более разных языков, работающих вместе (например, HTML, JS, CSS, C#, SQL). Создание сложных объектов, состоящих из взаимосвязанных движущихся частей, и наблюдение за тем, как они работают в тонких циклах, когда они разыгрывают последствия встроенной в них логики, может быть захватывающим и приносить сильное чувство выполненного долга.

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

Разработчики не выбирают технологические стеки

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

Одна из стратегий, которую производители программного обеспечения используют для уменьшения потери знаний, заключается в использовании технологий, которые широко используются и хорошо известны в сообществе разработчиков. Использование хорошо известных стеков упрощает поиск квалифицированных специалистов для работы. Это также помогает этим людям изучить все тонкости приложений, созданных с их помощью. Разработчики могут влиять на решение о том, какие технологии использовать для проекта, но обычно старшие инженеры или даже руководство принимают решение о стеках, используя эти критерии. Таким образом, маркетинг инструментов LC/NC для разработчиков может оказаться нецелесообразным.

Делать ставку на инструмент рискованно

Клиентам, как правило, трудно определить, куда они могут обратиться в будущем. Это понятно, поскольку будущее очень трудно предсказать. Таким образом, владельцы приложений должны адаптироваться к изменяющимся потребностям, чтобы обеспечить коммерческий успех приложения. Часто это означает изменение бизнес-моделей и изменение технологий, обеспечивающих такие модели. Опытные разработчики знают это и любят создавать открытые системы, которые можно адаптировать к изменяющимся потребностям в будущем. Лучший способ создать такие адаптируемые системы — написать их с использованием хорошо поддерживаемых языков и фреймворков.

Многие инструменты LC/NC являются новыми, незрелыми и имеют значительные технические ограничения. Эти ограничения обычно не афишируются и часто лишь скудно документируются. Единственный способ, с помощью которого производители программного обеспечения действительно могут найти эти ограничения, — это опробовать инструмент и создать реальное приложение. Большинство ограничений становятся очевидными только после значительных затрат времени и усилий. Разработка программного обеспечения и так дорога и рискованна, и эти неизвестные еще больше увеличивают риск для разработчиков, производителей программного обеспечения и их клиентов.

Блокировка закрывает сделку

Многие платформы не позволяют экспортировать приложения, созданные на этой платформе, в общие редактируемые форматы. Они блокируют приложения, тем самым либо привязывая разработчика к платформе, либо заставляя их перестраивать свое приложение с нуля. Учитывая, что будущие требования неопределенны и что ограничения инструментов LC/NC часто остаются скрытыми до конца проекта, неудивительно, что разработчики могут быть чрезвычайно осторожны, чтобы не застрять в них.

LC/NC в прошлом много раз терпел неудачу

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

Любой, кто сделал ставку на любой из этих инструментов, потратил время и энергию на их изучение и убедил клиентов создавать свои проекты с помощью любого из них, проиграл эту ставку. Эта история говорит о том, что маловероятно, что какой-либо из инструментов, с которыми мы сталкиваемся сегодня, все еще будет использоваться через десять лет. Многие разработчики могут внимательно рассмотреть эти факты и решить, что LC/NC — это тупик.

Что теперь?

Итак, является ли LC/NC безнадежным делом, и нет ли места для LC/NC в мире серьезной разработки программного обеспечения? Могут ли производители инструментов для LC/NC как-то преодолеть эти барьеры и мотивировать больше разработчиков использовать продукты LC/NC?

Многие разработчики предпочитают код из-за отсутствия доверия к инструментам LC/NC и маркетинговым коммуникациям, которые их рекламируют. Чтобы убедить любого профессионала использовать платформу LC/NC, производители платформ требуют, чтобы разработчики им доверяли. Чтобы завоевать это доверие, производителям инструментов следует прислушиваться к опасениям, высказанным разработчиками и производителями программного обеспечения, и учитывать их при планировании функций платформы и при общении с целевыми группами.

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