Бизнес-руководителям нравится идея средств разработки, которые требуют минимального объема написания кода (Low-Code) или даже совсем не требуют (No-Code). Меньше кода, значит — меньше работы, проекты реализуются быстрее за меньшие бюджеты, а в конечном счете топ-менеджеры быстрее получают премии. Кому такое не понравится?
Например, разработчикам. Нет, в теории это должно их привлекать (меньше работы и т. д.), но теория далека от реальности, которая с приближением дедлайнов проявляется в том, что подобные инструменты оказываются не совсем такими, как было обещано.
И тем не менее, у решений, которые сводят кодирование к минимуму, есть свои применения. Программисты ценят их за возможность выпустить работоспособную систему за короткое время с меньшими трудозатратами. Инструменты Low-Code позволяют, в частности, создавать эффективные средства поиска, сортировки и других манипуляций с табличными данными. Поэтому когда это действительно уместно, разработчики готовы пользоваться такими инструментами.
Но в то же время им не хочется быть загнанными в угол присущими средам Low-Code ограничениями, в том числе необходимостью отработки всех граничных случаев и обхода ситуаций, с которыми система не справляется нужным образом автоматически. Программистам приходится возиться с недоработками и недокументированными возможностями таких систем и прикладывать усилия, изобретая способы выполнения пользовательских запросов об изменении поведения стандартных функций.
Разработчики оказываются в ловушке, когда маркетинговые обещания оказываются далекими от реальности: работа с инструментами Low-Code происходит медленнее и может вызывать больше сложностей, чем реализация всей функциональности путем написания кода.
Перечислим девять причин, по которым программисты недовольны инструментами, призванными экономить их время.
1. Проблемы сопровождения и развития
Самая сложная часть работы с решением категории Low-Code обычно ждет вас через несколько лет после внедрения созданной в нем системы. Она прекрасно работает, но постепенно накапливаются запросы на исправления и усовершенствования. Нередко эти доработки выходят за пределы возможностей системы с минимумом кодирования, в связи с чем выполнить их непросто. Если бы в вашем распоряжении был исходный код, его можно было бы частично переписать, но его нет. И если бы разработчики знали, что в дальнейшем понадобится такая-то возможность, они бы, вероятно, изначально приняли другие решения, например воспользовались бы совершенно иным фреймворком. Но этого не произошло и теперь вы — в тупике.
2. Все получают одно и то же
Есть в ресторанах одной и той же сети — это для тех, кто не любит удивляться. Бизнес-модель таких сетей состоит в том, чтобы экономить, предлагая во всех заведениях единое меню, оформление и стандарты обслуживания, но заманчивее они от этого не становятся.
Так и системы, созданные при помощи одного и того же инструментария Low-Code, выглядят сделанными «под копирку». Имея минимальный опыт, разработчик может беглым взглядом определить, какой именно инструмент использовался для разработки системы — движок «проглядывает» сквозь нее независимо от настроек, заставок и CSS-«обложек». Часть пользователей это устраивает, если для них лучше, чтобы интерфейс выглядел привычным, но другим нужен элемент новизны.
3. Универсальных инструментов не бывает
Производственники отдают предпочтение серийной продукции, поскольку для нее проще организовать конвейер. Многие покупатели же, напротив, ненавидят «штамповку», желая, чтобы уважали их индивидуальность.
Решения Low-Code просты в использовании, но одинаковы в своей ограниченности. Вам доступно мало возможностей изменения, настройки и написания кода — вам приходится работать с тем, что есть, и с этим ничего не поделаешь. В итоге недовольны и программисты, и пользователи.
4. Иногда написать код проще, чем выполнить настройку
Практика принижения объема трудозатрат на настройку программного обеспечения — стратегическая ошибка. Она может быть обусловлена принципом оплаты за строку написанного кода или тем, что руководство привыкло искать компромисс между созданием нового кода и покупкой готового продукта. Так или иначе, но бытует представление о том, что изменение параметров в конфигурационных файлах платформы или инструментария не составляет особого труда.
О том же заявляют и поставщики инструментов Low-Code: вы не пишете код, когда выбираете алгоритмы, соединяетесь с базой данных и вводите параметры. Это просто настройка, а как все знают, настройку можно выполнить даже на смартфоне, находясь в шумном баре. На самом деле возня с конфигурационными файлами может занять дни и недели прежде чем будет достигнут нужный результат, однако поставщики систем пытаются убедить заказчиков в том, что это «не работа», даже если она отнимает больше времени, чем написание кода.
5. Полет вслепую
Программисты привыкли пользоваться средствами отладки, которые позволяют остановить выполнение программы в любой точке, чтобы просмотреть состояние переменных и уточнить, что происходит внутри алгоритма. Инструменты Low-Code же для «простоты» скрывают внутренности программы от разработчика.
Если решения на базе Low-Code ведут себя, как ожидалось, проблем с этим нет. Но часто бывает так, что при минимальных неполадках работа застревает, так как нет возможности уточнить, что происходит внутри «черного ящика» — вы словно ведете самолет без приборов, летя наудачу.
6. Нельзя добавлять функции корректировки данных
Половина работы программиста состоит в написании связующего кода для предотвращения ошибок при обработке данных. К примеру, даты могут быть в формате ISO 8601, а могут соответствовать региональным предпочтениям, числа время от времени нужно преобразовывать в строки или наоборот и т. д.
В системах Low-Code для подобных задач могут быть предусмотрены фильтры или переключатели, и обычно этого достаточно. Но когда нет, вам не повезло. Для поставщиков малокодовых сред это тоже непростая ситуация. Некоторые из них экспериментировали с возможностью добавления произвольных фрагментов кода, но это чревато дырами безопасности, если кто-то находит способы злоупотребления. К примеру, из Drupal убрали возможность включения фрагментов кода PHP, чтобы закрыть потенциальную брешь безопасности и улучшить производительность кэширования.
7. Cистемы Low-Code, как правило, неэффективны
Инструменты Low-Code сулят возможность «понимать», чего вы хотите, и волшебным образом исполнять ваши желания. Но цена этого «чтения мыслей» — увесистый стек кода, в котором предусмотрены варианты на все случаи жизни.
Допустим, ваша компания хранит все данные только в CSV-файлах. Но разработчики среды Low-Code должны все предусмотреть и также обеспечить поддержку JSON, YAML, XML версий 1.0 и 1.1 и т. д. Существует масса всевозможных форматов данных, и отдел маркетинга поставщика среды Low-Code будет настаивать на том, чтобы она поддерживала все из них — ведь нужно как можно больше галочек в таблице функциональности.
В результате появляется впечатляющий образец инженерной работы, внушительный, как дредноут, и такой же «маневренный» и «быстрый», как военный корабль времен первой мировой.
Как следствие, созданный продукт работает медленнее и менее эффективно, чем могла бы. Если вы стеснены жесткими сроками и обрабатываемый вашей системой набор данных не слишком велик, неэффективность можно замаскировать, добавив мощностей. Но рано или поздно «счет» за излишки в коде вам будет выставлен в любом случае.
8. Нужны специальные навыки
Многие платформы с открытым кодом разработаны на популярных языках программирования, широко преподаваемых в университетах. Есть немало специалистов, которые способны разобраться в коде стеков, реализованных на Java, JavaScript, Python, PHP и т. д.
Но работе с инструментариями Low-Code студентов не учат, поскольку в теории это и не нужно. Конечно, подобные инструменты нередко тоже написаны на распространенных языках, но проблема не совсем в этом, а в сложности структуры фреймворков Low-Code. Вы платите не только за саму систему — в дальнейшем, если ее нужно будет доработать или расширить, членам вашей команды придется потратить дополнительное время на изучение ее устройства.
9. Зависимость
Внедрение платформы Low-Code напоминает попадание в толпу — присоединиться легко, а выбраться непросто. Цена уменьшения объема выполняемой вами работы — зависимость от гигантов, которые подпирают своими плечами ваши системы. Пока гиганты двигаются, вы двигаетесь вместе с ними. А если они останавливаются или падают, вас ждут проблемы.
