[Перевод] Low-code инструменты для разработки ПО — сплошной обман
Я пишу ПО под заказ уже многие годы, и одна из ситуаций, которые раздражают меня больше всего — это когда клиент принимает позицию, что существует некая палочка-выручалочка, которая сократит, а то и вовсе устранит всю сложность, присущую той или иной задаче. Такое случается чаще, чем можно подумать, и знаете что? Такие клиенты почти всегда заблуждаются.
Возможно, с возрастом я становлюсь болтливее, чем следовало бы, но правда в том, что создавать программы для других людей — задача невероятной сложности. И проблема здесь не в языках программирования, инструментах и парадигмах, как склонны считать те, кто далек от практической стороны (то есть не пишет код). На самом деле, трудности возникают из-за того, что клиенты и разработчики не выделяют должного времени на то, чтобы разобраться в глубинных истоках проблемы, которую пытаются решить, и не проектируют решение исходя из тех выводов, к которым придут в процессе.
Мало просто разработать такой инструмент, какой описывает клиент. Самый первый шаг, предшествующий написанию кода — подтверждение существования проблемы в принципе и уточнение деталей. Большинство проектов, связанных с разработкой, начинаются с того, что клиент осознает, что у него возникла проблема, и заказывает код, который, на его взгляд, сможет ее решить. Но в реальности основная масса клиентов не ищет решения для проблем на профессиональном уровне, в то время как разработчики занимаются именно этим. Таким образом, именно на наши плечи ложится ответственность за валидацию подхода, предлагаемого клиентом, прежде чем начнем тратить и его время, и деньги, причем, возможно, впустую.
Тут надо прояснить: я говорю это без пренебрежения к клиентам. У них есть проблема, и они это понимают — только им может не хватать понимания, как спроектировать и реализовать наиболее разумное и подходящее решение для этой проблемы. За годы работы мне встречались такие проблемы, для решения которых вообще бессмысленно было писать код. Причина в том, что во многих случаях проблема, на самом деле, кроется в процессах. Но с точки зрения клиента, проще заплатить кому-нибудь за разработку инструмента, который якобы всё исправит, чем пытаться изменить глубоко внедрившиеся практики.
Я уже касался этой темы в 2019 году в статье под названием «Почему я не могу просто заткнуться и написать решение для вашей проблемы»:
Проще всего выразить мое отношение к этому так: я профессионально решаю проблемы, и мой основной инструмент для этого — код. Люди приходят ко мне и просят какой-нибудь код не потому, что у них всё на мази. Напротив — они приходят и просят написать решение для тех сложностей, которые испытывают в данный момент.
В любом случае, когда все эти начальные этапы пройдены, приходит время писать код, так ведь? Ну, обычно так. И вот тут-то мы и подходим к основной теме этой статьи. Иногда клиент попадается в ловушку убеждения, что существует некая палочка-выручалочка, которая сведет к нулю любые сложности, неотъемлемо связанные с разработкой кастомного решения. В наши дни самая избитая разновидность такого подхода — это когда говорят: «Ну, пускай ChatGPT напишет мне что там надо». Чушь собачья. Кое-какие простые задачи по написанию кода ChatGPT действительно в состоянии осилить, но всё, что выходит за эти рамки, быстро превращается в не поддающийся контролю бардак.
Помимо примера с модным сейчас ИИ-чатботом вокруг нас разбросано множество других примеров гомеопатии от разработки. Все они завлекают потенциальных покупателей обещаниями стряхнуть всю шелуху и по-быстрому сколотить кастомное ПО, не вынуждая человека тратить целые годы на обучение, как это обычно бывает у профессиональных разработчиков. Самый яркий пример этого синдрома — так называемые low-code инструменты. Так сложилось, что мне приходится иметь дело с одним из таких по работе.
Этот low-code инструмент называется OutSystems, и сказать о нем я могу только одно: куча мусора. Не буду углубляться в технические обоснования своего мнения — это, пожалуй, потянет на отдельную статью. Хотя он и дает возможность людям, не имеющим отношения к разработке, создавать кастомную логику и экраны, сложность, присущая таким задачам, как проектирование структур данных на должном уровне, написание отказоустойчивого ПО и проверка качества итогового продукта, никуда не девается. Из-за того что многие из тех, кто работает с кодом при помощи таких инструментов, не имеют соответствующих знаний, на выходе получается непродуманное, хрупкое кастомное ПО, соответственно, будущей команде предстоит постоянно тушить пожары, чтобы оно хоть как-то функционировало.
И это я еще не дошел до самого интересного: ценник у подобных инструментов высокий, а их создатели обычно формулируют лицензию и условия оплаты так, что платить приходится до тех пор, пока используется ПО, созданное при помощи их инструмента. Вдобавок все эти инструменты обычно предполагают, что вы в той или иной мере соглашаетесь на привязку к поставщику. Таким образом, чем больше времени вы на них тратите, тем крепче они держат вас за горло.
В обоих сценариях — что с ИИ-чатботами, что с low-code инструментами — на взгляд человека, который сам разработкой не занимается, решения обещают результат в обход всех сложностей, связанных с этим процессом. В этом-то и кроется ловушка. Те, кто сам работает с кодом, знают: его написание — это самый последний шаг в длительном процессе, который требует много размышлений, обсуждений и планирования. Код, в общем случае, представляет собой конечный итог, и создавать его относительно просто, если ты по-настоящему вник в стоящую перед тобой проблему.
Если вкратце обобщить сказанное: на самом деле, наиболее сложная часть процесса разработки ПО — это проектирование решения, которое на что-то будет годиться. Low-code инструменты обманывают своих пользователей, представляя дело так, будто самое трудное — это написать код. Правда же такова: нет на свете такого low-code инструмента, который избавил бы вас от необходимости неспешно и как следует продумать, как будет устроено ваше кастомное ПО, или уберег бы от последствий создания решения, спроектированного как придется.
