Comments 21
low-code экспертиза при написании статьи соответствует low-code ожиданиям от использования low-code.
В частности, график "поколений" языка и фич за пределами добра и зла. Альтернативная реальность просто.
Поделитесь своей, правильной реальностью. В моей реальности человека, который писал на Ассемблере, а потом на C++, было именно так. Да, где-то на Западе Паскаль появился на 2 года позже C (70, 72), а C++ в 85ом, но я и мои сверстники до Страуструпа добрались где-то со второй половины 90-х. Я же не об исторической точности, не это смысл графика и статьи. Смысл в том, что повышается уровень абстракции. И по логике, завтра он тоже должен повыситься.
low-code это инструмент. Его использование в существенном числе кейсов неудобное, об этом и пишут: что там с отладкой? как версионировать? а как с навигацией, когда проект большой? на тестирование часть платформ забили, как без этого? а сложность проекта как снизить (идея ООП, да и вообще разделение кода на функции как раз об этом)?
Пока то, что я видел в битрикс — превращалось в ад при росте сложности логики. И поэтому возвращаются обратно к подходу code first, т.к. там есть много отработанных инструментов снижения сложности.
Как только low-code найдет решение этих проблем — будет отличная вещь, но пока что увы — очень нишевая штука.
Пока то, что я видел в битрикс — превращалось в ад при росте сложности логики. И поэтому возвращаются обратно к подходу code first, т.к. там есть много отработанных инструментов снижения сложности.
Как только low-code найдет решение этих проблем — будет отличная вещь, но пока что увы — очень нишевая штука.
Кажется, вы не видели в глаза LCDP. Посмотрите.
Версионирование и всё CI/CD — легко гуглится.
Mendix например www.mendix.com/evaluation-guide/app-lifecycle/cicd
Ну и у других точно так же.
Битрикс это не LCDP, уясните же уже. Так же как low-code это не инструмент, а философия, концепция. У которой есть свои реализации — где похуже, где получше.
Версионирование и всё CI/CD — легко гуглится.
Mendix например www.mendix.com/evaluation-guide/app-lifecycle/cicd
Ну и у других точно так же.
Битрикс это не LCDP, уясните же уже. Так же как low-code это не инструмент, а философия, концепция. У которой есть свои реализации — где похуже, где получше.
"Как только low-code найдет решение этих проблем" он станет не low-code.
Если бы у бабки были яйца, то была бы она не бабкой, а дедкой.
У лоукода есть своя ниша, он решает другие задачи — совсем не те, что нужно через решать code first. В своей нише очень даже полезно. Как вы верно заметили, это ниша в которой можно пренебречь тестированием (кроме тестирования собственно самого решения на котором базируется все), не грозит перспектива роста, нет ожиданий что усложнится навигация и ещё горсть других условий...
>не грозит перспектива роста
Я бы даже так сказал — пока нет нормального версионирования, любой системе рост противопоказан. Потому что рано или поздно вы просто не сможете понять, почему вот в этом месте сделано вот так, когда в истории проекта произошло это изменение, что было раньше, чем это изменение вызвано, и какую задачу оно решало. Потому что без всего этого сложные системы не сопровождаются.
Я бы даже так сказал — пока нет нормального версионирования, любой системе рост противопоказан. Потому что рано или поздно вы просто не сможете понять, почему вот в этом месте сделано вот так, когда в истории проекта произошло это изменение, что было раньше, чем это изменение вызвано, и какую задачу оно решало. Потому что без всего этого сложные системы не сопровождаются.
Назовите мне ну хотя бы одну крупную LCDP без версионирования!
Из того что вы тут упоминали, я видел лично ESB Talend и Pega. У меня и в целом-то от них впечатления не сильно хороши, а версионирование по сравнению с решениями на основе кода просто никуда не годится (с поправкой на то, что оба продукта смотрел достаточно давно).
Причем я бы сказал, что это идеологические трудности, а не какие-то технические вещи, которые можно поправить. Ну так, упрощенно — если у вас в приложении нет текста (которым обычно является код), то у вас нет поиска по этому тексту. Ну т.е. там, где я могу просто найти нужные мне слова, комментарии и т.п., в случае отсутствия текста я что буду искать? И это так выглядит с поиском по проекту вообще, ну и по истории, естественно. Если проект состоит из квадратиков и стрелочек, как мне найти нужный кусок, как я опишу поисковой машине, что именно нужно найти? Ну т.е. тривиальная операция поиска по ключевому слову (названию класса в ООП, или там функции, и т.п.) превращается непонятно во что. Точнее — понятно во что, в листание страниц в IDE, зум туда, зум сюда, клик по компонентам, выход обратно. Поиск глазами, иначе говоря.
Это совершенно не значит, что этим всем нельзя пользоваться. Можно. У нас вот некоторые любят информатику BDM, скажем. Только вот что характерно — чем дальше развивается проект, тем больше я замечаю, что люди из оной информатики переходят на обычный код, кто на питон, кто на скалу, начинают писать ETL на спарке, ну и так далее.
Причем я бы сказал, что это идеологические трудности, а не какие-то технические вещи, которые можно поправить. Ну так, упрощенно — если у вас в приложении нет текста (которым обычно является код), то у вас нет поиска по этому тексту. Ну т.е. там, где я могу просто найти нужные мне слова, комментарии и т.п., в случае отсутствия текста я что буду искать? И это так выглядит с поиском по проекту вообще, ну и по истории, естественно. Если проект состоит из квадратиков и стрелочек, как мне найти нужный кусок, как я опишу поисковой машине, что именно нужно найти? Ну т.е. тривиальная операция поиска по ключевому слову (названию класса в ООП, или там функции, и т.п.) превращается непонятно во что. Точнее — понятно во что, в листание страниц в IDE, зум туда, зум сюда, клик по компонентам, выход обратно. Поиск глазами, иначе говоря.
Это совершенно не значит, что этим всем нельзя пользоваться. Можно. У нас вот некоторые любят информатику BDM, скажем. Только вот что характерно — чем дальше развивается проект, тем больше я замечаю, что люди из оной информатики переходят на обычный код, кто на питон, кто на скалу, начинают писать ETL на спарке, ну и так далее.
Во-первых, статья не про конкретные инструменты. Но если вам действительно важно разобраться, а не покричать, то я вам тут Америку не открою — код ревью в LCDP действительно визуально отличается от код ревью в традиционной разработке (на самом деле, конфигурацию можно читать, но конечно никто этого в здравом уме делать не будет).
Ревью, в силу принципиально другого уровня абстракции, проходит иначе. Нужно просто попытаться понять эту специфику. В классической разработке вы точно так же будете визуально проверять bpms в Camunda или jBPM, потому что проверять diff xml можно, но зачем.
Версионирование Talend www.youtube.com/watch?v=nR-afMng3KQ
Поиск по ключевым словам возможен очень разнообразно, как по неймингу компонентов, так и по коду (хотя джобы и схемы, преобразованные в код, читать проблематично). Если же мы говорим о фронтенд LCDP, то там все преобразовывается в код, который можно читать (например, Reify)
Ревью, в силу принципиально другого уровня абстракции, проходит иначе. Нужно просто попытаться понять эту специфику. В классической разработке вы точно так же будете визуально проверять bpms в Camunda или jBPM, потому что проверять diff xml можно, но зачем.
Версионирование Talend www.youtube.com/watch?v=nR-afMng3KQ
Поиск по ключевым словам возможен очень разнообразно, как по неймингу компонентов, так и по коду (хотя джобы и схемы, преобразованные в код, читать проблематично). Если же мы говорим о фронтенд LCDP, то там все преобразовывается в код, который можно читать (например, Reify)
>Версионирование Talend www.youtube.com/watch?v=nR-afMng3KQ
Я бы никогда не купил такой продукт. Это сильно лучше того, что было в моей практике в BPM, но это сильно хуже того, что я имею в коде. Ну т.е., все вот эти диаграммы ETL, они в принципе прекрасно представляются в виде кода, достаточно посмотреть например на Apache Camel, пишутся в виде обычного кода на Java, Groovy, или в xml, вполне неплохо читаются во всех этих видах, в случае Java и Groovy сопровождаются подсказками в IDE, что именно можно ввести в том или ином месте, сразу же в IDE компилируются, и проверяются.
Ну т.е. как человек ниже написал — по сути, было всего одно-два изменения, изменили тип компонента, и пару параметров — а простыня различий на экран не влезает.
Я бы никогда не купил такой продукт. Это сильно лучше того, что было в моей практике в BPM, но это сильно хуже того, что я имею в коде. Ну т.е., все вот эти диаграммы ETL, они в принципе прекрасно представляются в виде кода, достаточно посмотреть например на Apache Camel, пишутся в виде обычного кода на Java, Groovy, или в xml, вполне неплохо читаются во всех этих видах, в случае Java и Groovy сопровождаются подсказками в IDE, что именно можно ввести в том или ином месте, сразу же в IDE компилируются, и проверяются.
Ну т.е. как человек ниже написал — по сути, было всего одно-два изменения, изменили тип компонента, и пару параметров — а простыня различий на экран не влезает.
>Во-первых, статья не про конкретные инструменты.
Ну кстати. Если бы она была про конкретные, тот же Talend, скажем, возможно это было бы интереснее, во всяком случае лично мне. Хотя я прекрасно понимаю всю сложность написания такой статьи.
Ну кстати. Если бы она была про конкретные, тот же Talend, скажем, возможно это было бы интереснее, во всяком случае лично мне. Хотя я прекрасно понимаю всю сложность написания такой статьи.
Эка вы лихо функциональное программирование поставили на графике эволюции фич, после как этап после машинного кода и до ООП… Сразу видно высокий уровень low code пропагандиста: побольше умных слов, авось прокатит.
Во-первых, статья не об этом (она о том, что уровень абстракции растет).
Во-вторых, в моей картине мира всё начиналось с перфокарт и ассемблера (да, я в курсе про существование функциональных языков еще до моего рождения) а сегодня — это развитые фреймворки. И что-то будет дальше. Очень жаль, что вместо обсуждения сути вы кинулись в обсуждение несущественных деталей.
Во-вторых, в моей картине мира всё начиналось с перфокарт и ассемблера (да, я в курсе про существование функциональных языков еще до моего рождения) а сегодня — это развитые фреймворки. И что-то будет дальше. Очень жаль, что вместо обсуждения сути вы кинулись в обсуждение несущественных деталей.
Аргумент про мидлов и сеньеров: " Разрыв по доходам — в 3–4 раза, и это не случайность." ну совсем уж не соответсвует действительности.
И дефицит именно мидлов и сеньеров, которых ни курсы, ни индия, ни институты не выпускают готовых.
И дефицит именно мидлов и сеньеров, которых ни курсы, ни индия, ни институты не выпускают готовых.
Индия ежегодно поставялет 1 млн человек. Вы давно с разработчиками из Индии коммуницировали? 15 лет назад я сам говорил «а что они умеют». А они уже умеют многое.
Из одного миллиона, понятно, до мидла дойдет не много. Но этот прирост ежегодный (и это хорошо). Плохо же не то что мало разработчиков или много — это данность. Вопрос о том, куда это приведет индустрию.
Из одного миллиона, понятно, до мидла дойдет не много. Но этот прирост ежегодный (и это хорошо). Плохо же не то что мало разработчиков или много — это данность. Вопрос о том, куда это приведет индустрию.
Low-code не содержит традиционных средств контроля, привычных разработчику (code review...
Так как все-так выглядит решение вопроса "что тут у нас изменилось с прошлой версии процесса?" покажите картинку
Ну и, за компанию — как выглядит собственно ревью к этим изменениям "вот тут нужно было делать не так, а вот так..", коль скоро утверждается, что
Это миф. Вы найдёте эти компоненты в подавляющем большинстве платформ.
Вот сравнение джобы в Таленде www.youtube.com/watch?v=nR-afMng3KQ (создание версии, сравнение версии). Аналогично c Pega, Mendix, Powerapps ну и далее по списку.
По поводу код ревью — аналогично проверке в обычной среде. Ведь код ревью опирается на некую культуру (которая может быть упакована в регламенты и рекомендации, в статанализ и т.п.). Нет у меня золотой инструкции про то, как понять качество. Это всегда зависит от конкретного контекста и уровне абстракции самого проверяющего. Инженер, если он развивается, собственный мерджреквест через полгода зареджектит. Даже находясь в одном и том же проекте с одними и теми же правилами. silver bullet тут нет.
По поводу код ревью — аналогично проверке в обычной среде. Ведь код ревью опирается на некую культуру (которая может быть упакована в регламенты и рекомендации, в статанализ и т.п.). Нет у меня золотой инструкции про то, как понять качество. Это всегда зависит от конкретного контекста и уровне абстракции самого проверяющего. Инженер, если он развивается, собственный мерджреквест через полгода зареджектит. Даже находясь в одном и том же проекте с одними и теми же правилами. silver bullet тут нет.
Хотелось бы какие-то конкретные исследования.
Например: берем проф. разработчика, даём ему современный фреймворк, техлида/архитектора и проблему, просим накидать код. Дальше берем "продвинутого пользователя", low code систему, программиста для доработок конструктора, и смотрим, кто быстрее справится с задачей, учитывая в том числе время, затраченное на коммуникацию/процессы.
Ну или, может быть, есть success stories.
Вы исходите из предпосылки, что можно выбрать, кто будет делать — разработчик или бизнес. На мой взгляд, такого выбора нет, потому что:
1. Разработчиков не хватает, дефицит сохраняется.
1.1. Да и те, кто называет себя разработчиками — не всегда таковые. К нам на собесы иногда залетают «синьоры», которые не знают примерно ничего, включая систему контроля версий. А ещё я знаю продуктовые IT компании, в которых на прод заливают через FTP. Так что нужно сравнивать нормального разработчика и нормального «гражданского»
1.2. С учетом дефицита, задача удержать разработчика на типовых неинтересных задачах становится нетривиальной.
2. Я лично у себя в компании с помощью ряда инструментов могу накидать бизнес-процесс мышкой (и периодически пользуюсь такой возможностью). Только подумайте, как много мыслей в процессе построения бизнес-процессов («о, а тут текст некрасивый», «а тут наверное лучше другое количество дней» и т.п.), мне лично страшно представить тот стресс, который бы испытывали разработчики, попроси их делать это вместо меня. Вот реальный кейс — я уехал в отпуск, а HR команда сама поменяла чуть-чуть бизнес-процессы. Для разработчика эти правки ну супер неинтересные, мне бы даже было бы стыдно к инженеру с таким обращаться. Бизнес-процессы, формы и т.п. должны делать те, кто этим пользуется, а не разработчики. У меня прошлый БП вместе со всеми правками занял наверное пару дней. Если бы делали разработчики, то у меня было бы меньше возможностей для итераций и пристрелок, мне пришлось бы ждать в очереди из общего бэклога. Я не знаю как выразить этот простой деньгами даже в моей компании, но он был бы очень значительным.
1. Разработчиков не хватает, дефицит сохраняется.
1.1. Да и те, кто называет себя разработчиками — не всегда таковые. К нам на собесы иногда залетают «синьоры», которые не знают примерно ничего, включая систему контроля версий. А ещё я знаю продуктовые IT компании, в которых на прод заливают через FTP. Так что нужно сравнивать нормального разработчика и нормального «гражданского»
1.2. С учетом дефицита, задача удержать разработчика на типовых неинтересных задачах становится нетривиальной.
2. Я лично у себя в компании с помощью ряда инструментов могу накидать бизнес-процесс мышкой (и периодически пользуюсь такой возможностью). Только подумайте, как много мыслей в процессе построения бизнес-процессов («о, а тут текст некрасивый», «а тут наверное лучше другое количество дней» и т.п.), мне лично страшно представить тот стресс, который бы испытывали разработчики, попроси их делать это вместо меня. Вот реальный кейс — я уехал в отпуск, а HR команда сама поменяла чуть-чуть бизнес-процессы. Для разработчика эти правки ну супер неинтересные, мне бы даже было бы стыдно к инженеру с таким обращаться. Бизнес-процессы, формы и т.п. должны делать те, кто этим пользуется, а не разработчики. У меня прошлый БП вместе со всеми правками занял наверное пару дней. Если бы делали разработчики, то у меня было бы меньше возможностей для итераций и пристрелок, мне пришлось бы ждать в очереди из общего бэклога. Я не знаю как выразить этот простой деньгами даже в моей компании, но он был бы очень значительным.
Вся проблема в том, что Low-code рассматривают как новый инструмент для разработчика. Но ведь нет… Low-code платформы – это инструмент для продвинутого бизнес-аналитика, который программировать почти или совсем не умеет, но умеет моделировать процессы и данные, разбирается в бизнес-правилах, эргономике и UI/UX. Какой плюс для разработчиков? Они могут скинуть кучу бизнесовых запросов бизнес-аналитикам с Low-code инструментом в руках. Да, просто «скинуть» не получится – нужно организовать совместную работу. Но это уже не разработчика забота, а ИТ-директора. Есть ли у вас такой и насколько он готов в это «впрягаться» – это другой вопрос. Если кому интересно, в этой инфографике Comindware предложили шпаргалку по организации сотрудничества ИТ-отдела с бизнес-аналитиками — www.comindware.com/ru/blog-%D1%88%D0%BF%D0%B0%D1%80%D0%B3%D0%B0%D0%BB%D0%BA%D0%B0-%D0%B4%D0%BB%D1%8F-%D0%B8%D1%82-%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%B2
Sign up to leave a comment.
Low-code с точки зрения разработчиков — есть ли плюсы для инженеров?