Я пишу ПО под заказ уже многие годы, и одна из ситуаций, которые раздражают меня больше всего – это когда клиент принимает позицию, что существует некая палочка-выручалочка, которая сократит, а то и вовсе устранит всю сложность, присущую той или иной задаче. Такое случается чаще, чем можно подумать, и знаете что? Такие клиенты почти всегда заблуждаются.

Возможно, с возрастом я становлюсь болтливее, чем следовало бы, но правда в том, что создавать программы для других людей – задача невероятной сложности. И проблема здесь не в языках программирования, инструментах и парадигмах, как склонны считать те, кто далек от практической стороны (то есть не пишет код). На самом деле, трудности возникают из-за того, что клиенты и разработчики не выделяют должного времени на то, чтобы разобраться в глубинных истоках проблемы, которую пытаются решить, и не проектируют решение исходя из тех выводов, к которым придут в процессе.

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

Тут надо прояснить: я говорю это без пренебрежения к клиентам. У них есть проблема, и они это понимают – только им может не хватать понимания, как спроектировать и реализовать наиболее разумное и подходящее решение для этой проблемы. За годы работы мне встречались такие проблемы, для решения которых вообще бессмысленно было писать код. Причина в том, что во многих случаях проблема, на самом деле, кроется в процессах. Но с точки зрения клиента, проще заплатить кому-нибудь за разработку инструмента, который якобы всё исправит, чем пытаться изменить глубоко внедрившиеся практики.

Я уже касался этой темы в 2019 году в статье под названием «Почему я не могу просто заткнуться и написать решение для вашей проблемы»:

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

В любом случае, когда все эти начальные этапы пройдены, приходит время писать код, так ведь? Ну, обычно так. И вот тут-то мы и подходим к основной теме этой статьи. Иногда клиент попадается в ловушку убеждения, что существует некая палочка-выручалочка, которая сведет к нулю любые сложности, неотъемлемо связанные с разработкой кастомного решения. В наши дни самая избитая разновидность такого подхода – это когда говорят: «Ну, пускай ChatGPT напишет мне что там надо». Чушь собачья. Кое-какие простые задачи по написанию кода ChatGPT действительно в состоянии осилить, но всё, что выходит за эти рамки, быстро превращается в не поддающийся контролю бардак.

Помимо примера с модным сейчас ИИ-чатботом вокруг нас разбросано множество других примеров гомеопатии от разработки. Все они завлекают потенциальных покупателей обещаниями стряхнуть всю шелуху и по-быстрому сколотить кастомное ПО, не вынуждая человека тратить целые годы на обучение, как это обычно бывает у профессиональных разработчиков. Самый яркий пример этого синдрома – так называемые low-code инструменты. Так сложилось, что мне приходится иметь дело с одним из таких по работе.

Этот low-code инструмент называется OutSystems, и сказать о нем я могу только одно: куча мусора. Не буду углубляться в технические обоснования своего мнения – это, пожалуй, потянет на отдельную статью. Хотя он и дает возможность людям, не имеющим отношения к разработке, создавать кастомную логику и экраны, сложность, присущая таким задачам, как проектирование структур данных на должном уровне, написание отказоустойчивого ПО и проверка качества итогового продукта, никуда не девается. Из-за того что многие из тех, кто работает с кодом при помощи таких инструментов, не имеют соответствующих знаний, на выходе получается непродуманное, хрупкое кастомное ПО, соответственно, будущей команде предстоит постоянно тушить пожары, чтобы оно хоть как-то функционировало.

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

В обоих сценариях – что с ИИ-чатботами, что с low-code инструментами – на взгляд человека, который сам разработкой не занимается, решения обещают результат в обход всех сложностей, связанных с этим процессом. В этом-то и кроется ловушка. Те, кто сам работает с кодом, знают: его написание – это самый последний шаг в длительном процессе, который требует много размышлений, обсуждений и планирования. Код, в общем случае, представляет собой конечный итог, и создавать его относительно просто, если ты по-настоящему вник в стоящую перед тобой проблему.

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

Комментарии (19)


  1. medwed
    21.04.2023 10:36
    +7

    И после проектирования еще упираешься в ограничения low-code инструмента, которые зависят от видения его разработчиков. Что в итоге выливается в потерю времени или проект на костылях.


    1. CrushBy
      21.04.2023 10:36
      +3

      Да, поставщики Low-code мягко говоря "преувеличивают" про то, что кто угодно сможет разрабатывать решения. Однако, это не повод кидаться в крайности, и говорить, что давайте вернемся все на Ассемблер. Повышение уровня абстрагирования в любом случае дает много преимуществ. Например, мы на фактически Low-Code инструменте lsFusion делаем сложнейшие ERP системы. Да, конечно же и там есть свои ограничения, но они компенсируются скоростью и дешевизной разработки.


      1. NitroJunkie
        21.04.2023 10:36
        +3

        Многие люди не понимают, что обеспечить low code можно только фундаментальным повышением уровня абстракций, не "программированием мышкой". При "программировании мышкой" кода меньше не становится, он просто вводится по другому.


        1. medwed
          21.04.2023 10:36

          По сути, ты перетаскиваешь куски готового кода в UI оболочке, и количество этих движений зависит от атомарности low-code решения. Чем она выше, тем больше движений, но и гибкости больше (ближе к чистому кодированию). И наоборот, гибкость падает с увеличением размеров готового "куска кода".


        1. arTk_ev
          21.04.2023 10:36

          Ну подобные решение еще имеют смысл, когда граф транслируется в код и наоборот.

          И такие решения хотя бы тьюринг полны. Тот же ui делать или сценарии.

          А вот решения наподобие blueprint только повышают сложностью, намного проще выучить язык и платформу.


  1. fiego
    21.04.2023 10:36
    -3

    Oracle Apex - хорош для определённых задач


  1. aborouhin
    21.04.2023 10:36
    +5

    Проблема же не в инструменте, а в попытке применить его не по назначению. Если сразу принимать и осознавать, что NoCode/LoCode решение будет на определённом этапе неизбежно выкинуто на помойку и заменено нормальным - почему нет?

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

    Или если я хочу потенциальным пользователям показать "вот так примерно оно будет выглядеть - удобно?"

    Ну или ниша, которую Retool занимает - внутренние инструменты, которые по природе своей могут быть несколько корявыми и неидеальными, но лучше, чем ничего.


  1. ihouser
    21.04.2023 10:36
    +4

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

    Идеальный пример лоу-коде инструмента - exel таблицы. Еще ни один инструмент не смог повторить его успех.


  1. alpha_Dog
    21.04.2023 10:36
    +2

    А что там Cuba.Platform? Жива еще?


    1. CrushBy
      21.04.2023 10:36
      +1

      Cuba Platform никогда не позиционировала себя как Low-Code инструмент, а скорее как RAD. Они всегда говорили, что у них порог входа выше даже чем у 1С.


  1. SadOcean
    21.04.2023 10:36

    А потом все равно приходится писать в них код


  1. sofa3376
    21.04.2023 10:36
    -1

    Как же я люблю Scratch


  1. VirtualProgramer
    21.04.2023 10:36

    да, привязка, прчем иногда извращенная, если не заплатил вовремя, то уже готовое в гугл-плэй приложение перестанет работать. И пока не видел ни одного которое вызвало бы вау-эффект, везде надо немало документации изучить (соптавимой по объему и сложности с базовым уровнем напимер SQL или С#)


  1. Hafmaer
    21.04.2023 10:36
    +1

    Проблема людей в том, что лоукод ныне можно считать очередным панацелином.

    Это конечно же не так... Ничего личного, только маркетинг.

    Лоукод решения применяются уже давно в нишевых инструментах, но не везде и всюду. Всему своё место.


  1. JArik
    21.04.2023 10:36
    +1

    Без конкретных примеров из жизни в основном вода которую можно в 1о предложение уместить - "no-code гавно". Хотелось бы конкретики, и что-нибудь из опыта


  1. mbolsh
    21.04.2023 10:36
    -6

    Согласен с Вашим взглядом на low code. Ознакомьтесь, пожалуйста, с моей статьей на медиуме по данной теме https://mikebolshakov.medium.com/being-a-low-code-skeptic-dff6a7102655


  1. evseevvd
    21.04.2023 10:36
    +3

    No/low code вполне себе годиться для MVP, но надо понимать что после MVP это выкидывается в помойку или переписывается потому что заказчик такое начинает генерить в бэклог ????????????. Иногда важно очень быстро релизнуть MVP что бы показать/доказать бизнес ценность продукта.


  1. KongEnGe
    21.04.2023 10:36
    +1

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


  1. asnow
    21.04.2023 10:36

    ChatGPT это не low-code, с чего вообще вдруг? GPT это как раз ЯП, просто ещё сырой и не освоенный, по сути уиверсальный DSL. А вот low-code это присплсоба для решения стандартных задач, оно нацеленно на упрощения и это не универсальный молоток. Сложность в принципе никуда не девается просто в онтологии появляются новые понятия, которые проще оперируют стандартными случаями. Все имеет право на существование и выполняет свои функции. Инструменты никого не обманывают, обманывают люди. Вот вы лучше конкретно пишите, кто вас обманывает и в чем или идите с ними беседуете, какой-то инфантилизм закидывать это в сообщество