Вы исходите из предпосылки, что можно выбрать, кто будет делать — разработчик или бизнес. На мой взгляд, такого выбора нет, потому что:
1. Разработчиков не хватает, дефицит сохраняется.
1.1. Да и те, кто называет себя разработчиками — не всегда таковые. К нам на собесы иногда залетают «синьоры», которые не знают примерно ничего, включая систему контроля версий. А ещё я знаю продуктовые IT компании, в которых на прод заливают через FTP. Так что нужно сравнивать нормального разработчика и нормального «гражданского»
1.2. С учетом дефицита, задача удержать разработчика на типовых неинтересных задачах становится нетривиальной.
2. Я лично у себя в компании с помощью ряда инструментов могу накидать бизнес-процесс мышкой (и периодически пользуюсь такой возможностью). Только подумайте, как много мыслей в процессе построения бизнес-процессов («о, а тут текст некрасивый», «а тут наверное лучше другое количество дней» и т.п.), мне лично страшно представить тот стресс, который бы испытывали разработчики, попроси их делать это вместо меня. Вот реальный кейс — я уехал в отпуск, а HR команда сама поменяла чуть-чуть бизнес-процессы. Для разработчика эти правки ну супер неинтересные, мне бы даже было бы стыдно к инженеру с таким обращаться. Бизнес-процессы, формы и т.п. должны делать те, кто этим пользуется, а не разработчики. У меня прошлый БП вместе со всеми правками занял наверное пару дней. Если бы делали разработчики, то у меня было бы меньше возможностей для итераций и пристрелок, мне пришлось бы ждать в очереди из общего бэклога. Я не знаю как выразить этот простой деньгами даже в моей компании, но он был бы очень значительным.
Во-первых, статья не про конкретные инструменты. Но если вам действительно важно разобраться, а не покричать, то я вам тут Америку не открою — код ревью в LCDP действительно визуально отличается от код ревью в традиционной разработке (на самом деле, конфигурацию можно читать, но конечно никто этого в здравом уме делать не будет).
Ревью, в силу принципиально другого уровня абстракции, проходит иначе. Нужно просто попытаться понять эту специфику. В классической разработке вы точно так же будете визуально проверять bpms в Camunda или jBPM, потому что проверять diff xml можно, но зачем.
Поиск по ключевым словам возможен очень разнообразно, как по неймингу компонентов, так и по коду (хотя джобы и схемы, преобразованные в код, читать проблематично). Если же мы говорим о фронтенд LCDP, то там все преобразовывается в код, который можно читать (например, Reify)
Вот сравнение джобы в Таленде www.youtube.com/watch?v=nR-afMng3KQ (создание версии, сравнение версии). Аналогично c Pega, Mendix, Powerapps ну и далее по списку.
По поводу код ревью — аналогично проверке в обычной среде. Ведь код ревью опирается на некую культуру (которая может быть упакована в регламенты и рекомендации, в статанализ и т.п.). Нет у меня золотой инструкции про то, как понять качество. Это всегда зависит от конкретного контекста и уровне абстракции самого проверяющего. Инженер, если он развивается, собственный мерджреквест через полгода зареджектит. Даже находясь в одном и том же проекте с одними и теми же правилами. silver bullet тут нет.
Битрикс это не LCDP, уясните же уже. Так же как low-code это не инструмент, а философия, концепция. У которой есть свои реализации — где похуже, где получше.
Поделитесь своей, правильной реальностью. В моей реальности человека, который писал на Ассемблере, а потом на C++, было именно так. Да, где-то на Западе Паскаль появился на 2 года позже C (70, 72), а C++ в 85ом, но я и мои сверстники до Страуструпа добрались где-то со второй половины 90-х. Я же не об исторической точности, не это смысл графика и статьи. Смысл в том, что повышается уровень абстракции. И по логике, завтра он тоже должен повыситься.
Индия ежегодно поставялет 1 млн человек. Вы давно с разработчиками из Индии коммуницировали? 15 лет назад я сам говорил «а что они умеют». А они уже умеют многое.
Из одного миллиона, понятно, до мидла дойдет не много. Но этот прирост ежегодный (и это хорошо). Плохо же не то что мало разработчиков или много — это данность. Вопрос о том, куда это приведет индустрию.
Во-первых, статья не об этом (она о том, что уровень абстракции растет).
Во-вторых, в моей картине мира всё начиналось с перфокарт и ассемблера (да, я в курсе про существование функциональных языков еще до моего рождения) а сегодня — это развитые фреймворки. И что-то будет дальше. Очень жаль, что вместо обсуждения сути вы кинулись в обсуждение несущественных деталей.
Т.е. у вас получается решать в code-first, и не получилось в low code. Возможно, вы не привыкли к новому уровню абстракции?
Хороший, даже блестящий, разработчик, не в состоянии сделать что-то хорошее в low code, пока не сменит парадигму с code-first на более верхнеуровневую low code.
И потом, эти же разработчики в code first решениях устают от операционки — «задачи неинтересные».
Если вам реально интересно докопаться до сути, а не прибежать в комменты и сказать что-то, что вообще никак нельзя проверить, дайте подробности: какая задача, какие фреймворки, в чем проблема. Давайте обсудим конкретно.
Повторюсь, что версионирование в low code системах многих имеется (я не сталкивался с системами, в которых версионирование отсутствует, но допускаю что конкретные элементы реализации могут страдать, так как сложно совместить в голове код компонента, вставку java кода и т.п.
Давайте от абстрактных размышлений перейдем к конкретным.
Ваш пример. У вас есть некий отчет, который настолько вам нужен, что вы им аж раз в год пользуетесь, и при этом этот отчет для своих нужд может поменять какой-то другой отдел. Если у того отдела свои задачи, то лучше ему дать собственный отчет и пусть они меняют его (и в LCAP это сделать просто). Если же это кто-то из ваших сотрудников поменял, и он перестал формироваться и вы через год это обнаружили (допустим, сотрудник уже не помнит зачем и что он менял), и в той low code системе нет возможности посмотреть изменения конфигурации, то благодаря самодокументируемости вы пересоберете отчет вновь и быстро.
Собственно, сравним с парадигмой code first:
а) у вас могли поменяться конфиги (не факт что изменения конфигов логируются, а если логируются, то они в нормальном виде)
б) у вас код вообще мог не меняться, а поменяться третья система (а тесты регулярно не бегают, потому что их обычно редко кто просто так гоняет, и наличие хороших тестов в традиционной разработке — отдельная тема).
Но в low code вы визуально понимаете как что работает, и lowcode ные вставки кода читаются за минуту. А в code-first коде формирования отчета, который вы трогали год назад, вы разбираться будете минимум пару часов.
№5. Тут сразу две ошибки. Абстракции в low code есть, расширяемость компонентов есть. copy-paste это неправильное использование — да, в low code тоже нужны мозги, и если вы знаете коллег, которые ими не пользуются, расскажите им об этом.
№6. low code это новый уровень абстракции разработки, она постоянно растет. Сначала машинные команды, потом память, потом функции, потом ООП, потом фреймворки и компоненты. Теперь компоненты становятся самодокументируемыми и гибко расширяемыми — low code.
Мы знаем случаи на практике, когда команда разработки на питоне не могла завершить сервис месяцами, который мы внедрили силами джуна и менеджера за две недели. Замечу, что большая часть наших ребят — это разработчики, и мы понимаем что такое разработка. PHP, Python, Go, Node.js, *.js, Flutter — на всём этом мы пишем. Но при этом мы не хотим постоянно отвлекаться в разработке на минорные правки, нам хочется писать нормальный интересный код, и принцип low code этому способствует. Почему вы принцип путаете с каким-то конкретным инструментом, о котором вы не говорите? :)
№7 а давайте конкретно, вы о каком конкретно стеке?
№8 Давайте конкретно? Если вы спроектировали интеграцию в Talend, и она у вас выгрузилась в отдельный docker и работает автономно, но при этом в месте разработчика у вас все интеграции под рукой — где там место «самопальному велосипеду»? Наоборот, это способствует более правильной архитектуре и не перегружает конечные системы лишней логикой интеграций. Это про ESB. Но тоже самое можно говорить и про бизнес-процессы, и про моделирование данных, и про интерфейсы и т.п.
расскажите, какие low code решения вы использовали?
Мы знаем, что часто в low code приходят инженеры с уровнем абстракции code first и начинают из low code делать code first. Спрашиваешь — зачем тут так много кода, это можно было бы правильно сделать, и слышишь в ответ «что-то писать захотелось, не чувствую себя творцом». Ага.
А теперь представим, что мы написали сотню микросервисов и через полгода где-то что-то нужно поправить.
Вопрос не в том, чтобы возненавидеть или радоваться в коде (будто тысячи строк кода понятнее сложных схем) — нейминг и возможность сделать абстракцию важно. Если у вас большой бизнес-процесс или задача интеграции, сделайте подзадачу. Всё, как в традиционных парадигмах. Никто не мешает и большая часть решений позволяют.
Думать нужно будет всегда. А вот будет ли это думание завтра выражаться в написании кода, или в проектировании визуальном, или чем-то еще — это большой вопрос. Я уверен, что уровень абстракции будет увеличиваться.
1. Vendor lock — а в code first нет вендор лок? Ну вот я вам как руководитель IT компании, занимающейся разработкой под заказ, сообщаю — у нас постоянно заказчики приходят и говорят «у нас было написано такое супер-пупер решение, правда прошло 7 лет и мы теперь не знаем что с ним делать, мы там вообще ничего поменять не можем, а разработчики потеряли интерес к проекту, а новые почему-то не вдохновляются». Или другой пример: «Вот у нас есть тыща собственных разработчиков, но мы тут сервис пилим год силами наших разработчиков, но они вот погрязли в том и в том и в том, и до этого проекта как-то руки не доходят». Отсутствие vendor lock в традиционной разработке это сильнейший миф — только команда с очень высоким уровнем культуры разработки может делать поддерживаемые решения, но таких команд, увы, очень мало. И каждый такой член команды на вес бриллианта, и ему всякую ерунду давать не будут. А эту «ерунду» будут делать остальные. И к чему мы пришли?
Кто тут стартап? Talend с 3% рынка ESB? Salesforce с 200 миллиардами долл капитализации? Oracle? IBM? Microsoft? Mendix (см. Siemens)?
А это основные поставщики low code решений сегодня.
1. IDC говорит, что в ближайшее время нужно 500 млн приложений. Такого количества разработчиков нет даже в теории. Поэтому под citizen developer могут пониматься и конечные пользователи (мне нужна форма — я её запилил, сейчас это делается в «экселях»), и бизнес-аналитики, для которых это должно стать нормой, и дизайнеры интерфейсов. Это зависит от культуры предприятия. В «красной» компании понятно, начальник ничего сам делать не будет (если такие компании в будущем в принципе останутся). Короче, тут суть в том, что у бизнеса нет времени на долгую разработку, и low code, вне зависимости кто её делает, сделают быстрее. И отрасль будет развиваться по пути ускорения внесения изменений. Что будет в гипотетическом будущем — неизвестно, может какой-то process mining, только очень очень умный. Не исключено.
2. Внедрение. Бывает что да, вжух и в продакшен, потому что если ты поменял понятную часть в конструкторе (в интеграции атрибут добавил например), то с высокой долей вероятности тестировать code-first подходами не требуется по ряду причин. Или если вы в приложении что-то изменили.
На ТЗ нет ни у кого времени. Мы не видели ни одного ТЗ, даже госовского, чтобы там не менялось в процессе очень многое. Именно с этим борется Agile, ТЗ это не «бережливое» производство, если мы IT берем (в строительстве в качестве ТЗ BIM и там другая история).
2.1. Преодолевать сопротивление IT нужно, потому что рано или поздно текущий пузырь роста зарплат к производительности труда рухнет, так не может объективно долго продолжаться.
Выстраивается это тем, как учит Agile — разработчики и продукт оунер начинают мыслить задачей в терминах ценности. Выстраивается всё точно так же, как и в обычной разработке. Просто разработка становится больше консультантом, наставником и дизайнером («давай подумаем как это лучше сделать»), но нормальные it команды и так уже так работают, просто теперь они будут работать еще быстрее.
У всех у нас есть какая-то фамилия, что поделать
1. Разработчиков не хватает, дефицит сохраняется.
1.1. Да и те, кто называет себя разработчиками — не всегда таковые. К нам на собесы иногда залетают «синьоры», которые не знают примерно ничего, включая систему контроля версий. А ещё я знаю продуктовые IT компании, в которых на прод заливают через FTP. Так что нужно сравнивать нормального разработчика и нормального «гражданского»
1.2. С учетом дефицита, задача удержать разработчика на типовых неинтересных задачах становится нетривиальной.
2. Я лично у себя в компании с помощью ряда инструментов могу накидать бизнес-процесс мышкой (и периодически пользуюсь такой возможностью). Только подумайте, как много мыслей в процессе построения бизнес-процессов («о, а тут текст некрасивый», «а тут наверное лучше другое количество дней» и т.п.), мне лично страшно представить тот стресс, который бы испытывали разработчики, попроси их делать это вместо меня. Вот реальный кейс — я уехал в отпуск, а HR команда сама поменяла чуть-чуть бизнес-процессы. Для разработчика эти правки ну супер неинтересные, мне бы даже было бы стыдно к инженеру с таким обращаться. Бизнес-процессы, формы и т.п. должны делать те, кто этим пользуется, а не разработчики. У меня прошлый БП вместе со всеми правками занял наверное пару дней. Если бы делали разработчики, то у меня было бы меньше возможностей для итераций и пристрелок, мне пришлось бы ждать в очереди из общего бэклога. Я не знаю как выразить этот простой деньгами даже в моей компании, но он был бы очень значительным.
Ревью, в силу принципиально другого уровня абстракции, проходит иначе. Нужно просто попытаться понять эту специфику. В классической разработке вы точно так же будете визуально проверять bpms в Camunda или jBPM, потому что проверять diff xml можно, но зачем.
Версионирование Talend www.youtube.com/watch?v=nR-afMng3KQ
Поиск по ключевым словам возможен очень разнообразно, как по неймингу компонентов, так и по коду (хотя джобы и схемы, преобразованные в код, читать проблематично). Если же мы говорим о фронтенд LCDP, то там все преобразовывается в код, который можно читать (например, Reify)
По поводу код ревью — аналогично проверке в обычной среде. Ведь код ревью опирается на некую культуру (которая может быть упакована в регламенты и рекомендации, в статанализ и т.п.). Нет у меня золотой инструкции про то, как понять качество. Это всегда зависит от конкретного контекста и уровне абстракции самого проверяющего. Инженер, если он развивается, собственный мерджреквест через полгода зареджектит. Даже находясь в одном и том же проекте с одними и теми же правилами. silver bullet тут нет.
Версионирование и всё CI/CD — легко гуглится.
Mendix например www.mendix.com/evaluation-guide/app-lifecycle/cicd
Ну и у других точно так же.
Битрикс это не LCDP, уясните же уже. Так же как low-code это не инструмент, а философия, концепция. У которой есть свои реализации — где похуже, где получше.
Из одного миллиона, понятно, до мидла дойдет не много. Но этот прирост ежегодный (и это хорошо). Плохо же не то что мало разработчиков или много — это данность. Вопрос о том, куда это приведет индустрию.
Во-вторых, в моей картине мира всё начиналось с перфокарт и ассемблера (да, я в курсе про существование функциональных языков еще до моего рождения) а сегодня — это развитые фреймворки. И что-то будет дальше. Очень жаль, что вместо обсуждения сути вы кинулись в обсуждение несущественных деталей.
Хороший, даже блестящий, разработчик, не в состоянии сделать что-то хорошее в low code, пока не сменит парадигму с code-first на более верхнеуровневую low code.
И потом, эти же разработчики в code first решениях устают от операционки — «задачи неинтересные».
Если вам реально интересно докопаться до сути, а не прибежать в комменты и сказать что-то, что вообще никак нельзя проверить, дайте подробности: какая задача, какие фреймворки, в чем проблема. Давайте обсудим конкретно.
Давайте от абстрактных размышлений перейдем к конкретным.
Ваш пример. У вас есть некий отчет, который настолько вам нужен, что вы им аж раз в год пользуетесь, и при этом этот отчет для своих нужд может поменять какой-то другой отдел. Если у того отдела свои задачи, то лучше ему дать собственный отчет и пусть они меняют его (и в LCAP это сделать просто). Если же это кто-то из ваших сотрудников поменял, и он перестал формироваться и вы через год это обнаружили (допустим, сотрудник уже не помнит зачем и что он менял), и в той low code системе нет возможности посмотреть изменения конфигурации, то благодаря самодокументируемости вы пересоберете отчет вновь и быстро.
Собственно, сравним с парадигмой code first:
а) у вас могли поменяться конфиги (не факт что изменения конфигов логируются, а если логируются, то они в нормальном виде)
б) у вас код вообще мог не меняться, а поменяться третья система (а тесты регулярно не бегают, потому что их обычно редко кто просто так гоняет, и наличие хороших тестов в традиционной разработке — отдельная тема).
Но в low code вы визуально понимаете как что работает, и lowcode ные вставки кода читаются за минуту. А в code-first коде формирования отчета, который вы трогали год назад, вы разбираться будете минимум пару часов.
И это не имеет отношения к разделению прав.
2. OneTick это no code как я понимаю. Совершенно другая парадигма.
№6. low code это новый уровень абстракции разработки, она постоянно растет. Сначала машинные команды, потом память, потом функции, потом ООП, потом фреймворки и компоненты. Теперь компоненты становятся самодокументируемыми и гибко расширяемыми — low code.
Мы знаем случаи на практике, когда команда разработки на питоне не могла завершить сервис месяцами, который мы внедрили силами джуна и менеджера за две недели. Замечу, что большая часть наших ребят — это разработчики, и мы понимаем что такое разработка. PHP, Python, Go, Node.js, *.js, Flutter — на всём этом мы пишем. Но при этом мы не хотим постоянно отвлекаться в разработке на минорные правки, нам хочется писать нормальный интересный код, и принцип low code этому способствует. Почему вы принцип путаете с каким-то конкретным инструментом, о котором вы не говорите? :)
№7 а давайте конкретно, вы о каком конкретно стеке?
№8 Давайте конкретно? Если вы спроектировали интеграцию в Talend, и она у вас выгрузилась в отдельный docker и работает автономно, но при этом в месте разработчика у вас все интеграции под рукой — где там место «самопальному велосипеду»? Наоборот, это способствует более правильной архитектуре и не перегружает конечные системы лишней логикой интеграций. Это про ESB. Но тоже самое можно говорить и про бизнес-процессы, и про моделирование данных, и про интерфейсы и т.п.
Мы знаем, что часто в low code приходят инженеры с уровнем абстракции code first и начинают из low code делать code first. Спрашиваешь — зачем тут так много кода, это можно было бы правильно сделать, и слышишь в ответ «что-то писать захотелось, не чувствую себя творцом». Ага.
А теперь представим, что мы написали сотню микросервисов и через полгода где-то что-то нужно поправить.
Вопрос не в том, чтобы возненавидеть или радоваться в коде (будто тысячи строк кода понятнее сложных схем) — нейминг и возможность сделать абстракцию важно. Если у вас большой бизнес-процесс или задача интеграции, сделайте подзадачу. Всё, как в традиционных парадигмах. Никто не мешает и большая часть решений позволяют.
А это основные поставщики low code решений сегодня.
2. Внедрение. Бывает что да, вжух и в продакшен, потому что если ты поменял понятную часть в конструкторе (в интеграции атрибут добавил например), то с высокой долей вероятности тестировать code-first подходами не требуется по ряду причин. Или если вы в приложении что-то изменили.
На ТЗ нет ни у кого времени. Мы не видели ни одного ТЗ, даже госовского, чтобы там не менялось в процессе очень многое. Именно с этим борется Agile, ТЗ это не «бережливое» производство, если мы IT берем (в строительстве в качестве ТЗ BIM и там другая история).
2.1. Преодолевать сопротивление IT нужно, потому что рано или поздно текущий пузырь роста зарплат к производительности труда рухнет, так не может объективно долго продолжаться.
Выстраивается это тем, как учит Agile — разработчики и продукт оунер начинают мыслить задачей в терминах ценности. Выстраивается всё точно так же, как и в обычной разработке. Просто разработка становится больше консультантом, наставником и дизайнером («давай подумаем как это лучше сделать»), но нормальные it команды и так уже так работают, просто теперь они будут работать еще быстрее.