Жизнь в Low Code / No Code реальности: плюсы и минусы

[quote="Den Brown"]Для начала приведу плюс: Flow имеют функционал версии и их историю, это очень удобно, и чувствуешь себя спокойнее[/quote] не совсем доволен исполнением. Этой фишки. Особенно если flow интегрированно в другой процесс. В этом случае пока отладишь flow нужно сделать версий 20

А так да инструмент удобный и относительно легко кастомизируется род нужны каждого клиента

Инструмент удобный, но постоянно встречаются проблемы, когда входят в пакет. Плюс медленный.

На всех проектах где сталкивался с No Code ничего кроме проблем не наблюдалось. Функционал они покрывали минимальный, зато косяков добавляли тонну. Особенно по падающим лимитам. Сам не использую, но клиенты любят эти flow поковырять. А потом сидишь и ломаешь голову почему тесты в сандбоксе работают, а на проде падают. Поэтому я за 100% Code-Only подход, а тек кто пробует все эти новомодные фишки линейкой по пальцам. :smiley:

[quote="Dmitry Shnyrev"]Поэтому я за 100% Code-Only подход[/quote]

Я исключительно про Screen Flow. К остальному пока особенно нет доверия

[quote="Dmitry Shnyrev"]На всех проектах где сталкивался с No Code ничего кроме проблем не наблюдалось.[/quote]

когда это было? какие проекты? если что-то вроде приложений-пакетов, то там конечно все на апексе


[quote="Dmitry Shnyrev"]Особенно по падающим лимитам[/quote]

у меня пруфов нет, но все же такое ощущение, что по Flow уже многое оптимизировано behind scene, так что и самая дурацкая логика работает. у нас triggered Flow (сконфигурированные джунами) выживают даже при дата-лоаде.

[quote="wilder"]Я исключительно про Screen Flow[/quote]

может и на triggered Flow уже стоит посмотреть внимательнее

[quote="Den Brown"]может и на triggered Flow уже стоит посмотреть внимательнее[/quote]
Может. Есть такой проект refactoring называется:)

[quote="Den Brown"]когда это было? какие проекты? если что-то вроде приложений-пакетов, то там конечно все на апексе[/quote]
Естественно я про "большие" проекты где тонны кода и где куча различной калькуляции, где одна DML операция может тригерить десятки триггеров и асинхронных процессов. И когда к этой магии на apex еще начинают приплетаться какие-то "неизвестные" flow которые клиент сам придумал, то тут ничего хорошего не жди. 
То что клиент на стандартном пустом орге играет Flow то пусть играет. Все равно ничего сложнее аналога простейшего триггера типа "посчитать и заполнить поле" не сделает. И смысл такому клиенту нанимать дорогого разраба?

Я может плохо пытаюсь донести свою мысль, но основная проблема No Code подхода в том что это инструмент "одного орга". Когда у тебя прод и [b]один[/b] человек которые занимается его [b]настройкой[/b]. А если у тебя команда разрабочиков, сандбоксы для разработки, репозиторий,  CI/CD? Где тут место No Code?

Тут на самом деле палка о двух концах.  Есть один проект. Мы поставили своей продукт, кастомзтровали его под клиента. А потом клиент взял команду из Мексики и давай кастомизировать все и все. Почти все написано на апексе и куче Financial Force пакетов. Казалось бы все апекс, но я когда получаю баг оттуда, то у меня глаз начинает дергаться. Потому что только  для того что бы понять в чем проблема, может уйти день в отладке. Это тот самый клиент у которого установка пакета обычно занимает от 4 часов. Хотя обычно это берет минут 10-20.

В общем я за то, что решения были разные, тогда хотя бы можно выбирать:) А то в некоторых случаях и выбора нет:)

[quote="wilder"]А потом клиент взял команду из Мексики и давай кастомизировать все и все. Почти все написано на апексе и куче Financial Force пакетов. Казалось бы все апекс, но я когда получаю баг оттуда, то у меня глаз начинает дергаться.[/quote]
Так а разве не работает принцип "кто последний тот и папа"? Пусть мексиканцы и фигсят то что накастомизировали? Хотя тут наверное больше вопрос $$$ :smiley:

[quote="wilder"]В общем я за то, что решения были разные, тогда хотя бы можно выбирать:) А то в некоторых случаях и выбора нет:)[/quote]
Но собственно пример я не совсем понял. Пришли челы нахуевертили тонну апекса который сложно дебажить. А если бы они накликали тоже самое на Flow было бы легче??? Я помню пару моментов, но тут скорее сказывается недостаток опыта при работе с Flow когда у меня вообще не получалось что-то отдебажить и понять почему Flow падает на тестах при деплое. Получалось залить релиз только если деактивировать Flows. А потом через какое-то время я забыл активировать Flows назад и оказывается что они не особо были нужны - никто про них и не вспомнил. Это последний печальный опыт работы с No Code который лишний раз укрепил мое мнение что No Code зло. 

[quote="Dmitry Shnyrev"]Так а разве не работает принцип "кто последний тот и папа"? Пусть мексиканцы и фигсят то что накастомизировали? Хотя тут наверное больше вопрос $$$ [/quote]

Конечно работает, но сначала нужно доказать что это не ты...

[quote="Dmitry Shnyrev"]мое мнение что No Code зло[/quote]
В общем такого мое мнение. Понимаю что серьезных аргументов у меня нет, а есть чисто субьективные впечатления. Но уверен что есть моменты когда No Code имеет право на жизнь :party:

Уже стоит ощущение, что например делать кастомную логику на апексе - это bad practice, a best practice - это все запилить во Флоу (за исключением самых тяжелых случаев)

и не забывайте что SF активно раскручивает свой OmniStudio

так что надежда, что это все временное поветрие, может и не оправдаться, и эти все LC/NC тулы придется принять и обнять как родных

[quote="Den Brown"]Уже стоит ощущение, что например делать кастомную логику на апексе - это bad practice, a best practice - это все запилить во Флоу (за исключением самых тяжелых случаев). 
[/quote]

И кстати клиент будет считать это совершенно верным

[quote="Den Brown"]Уже стоит ощущение, что например делать кастомную логику на апексе - это bad practice, a best practice - это все запилить во Флоу (за исключением самых тяжелых случаев)[/quote]
И ты как программист считаешь что это верно? Что код который читается, правится за секунду, покрывается тестами, дебажится, является bad practice по сравнению с кучей окошечек, менюшечек и прочей UI дряни. 

Я точно не сплю?

Вот к примеру, давайте простой пример задачи возьмем. Скажем надо показать погоду (или курсы валют) взятую по API из какого-то стороннего сайта. Как вы это на Flow сделаете? Я нуб по Flow, я не представляю. Проясните. Или скажем мне надо сгенерить PDF с какой-то инфой, ну или массовый пересчет каких-то значений каждый день (батч на apex).

Кстати идея! Давай те предлагать задачи и предлагать варианты решения на No Code. Я думаю это будет это будет крайне полезный вариант ведения беседы по этой теме. 

Лично я в плане Flow сталкивался(видел) с задачами типа "на create/update какого-то объекта заполнить какие-то поля по условиям". Это простой триггер. Такую задачу для Flow я еще представляю. Давайте накидывать более тяжелые задачи и пробовать решить их на Flow. 

[quote="Den Brown"]И кстати клиент будет считать это совершенно верным[/quote]
Мой текущий клиент кстати тоже считает что No Code лучше поэтому сам и ковыряется в нем периодически чем доставляет мне проблемы. Он пару раз пробовал настоять на том чтобы я изучил эту тему глубже чтобы отказаться от кода и погрузиться в мир флов. Но я максимально стараюсь не поддаваться. Последний раз мы касались этой темы когда потратили на созвоне 2 часа пробуя настроить простейший флоу, а у меня сдали нервы и я прямо во время разговора в бэграунде запилил апекс триггер, прикрутил тест и залил на прод и сказал что уже все готово и нет смысла ковырять дальше этот flow.

[quote="Dmitry Shnyrev"]Я точно не сплю?[/quote]

точно не спишь, особенно:

если клиент считает, что Flow is the best practice, т.к. во время выбора платформы они купились на СФ разговоры о LC/NC faster to market approach,

если старший архитект (кто уже 20 лет не писал никакой код, но точно следует всем рекомендациям СФ) тоже считает что нужно следовать рекомендациям и best practice

удачи с ними спорить!

[quote="Den Brown"]что нужно следовать рекомендациям и best practice[/quote]

Всякие NoCode тулы по любому должны продвигаться. На их разработку потратили же деньги. Это какой-то продукт который надо продать. Но мы то с вами взрослые люди и не должны вестись на всякий желтый пиар. У Flow есть своя ниша но увы за пределами серьезной SF разработки.

Для примера задач может завести отдельную тему? А как картинки добавлять?

[quote="Dmitry Shnyrev"]Всякие NoCode тулы по любому должны продвигаться. На их разработку потратили же деньги. Это какой-то продукт который надо продать. Но мы то с вами взрослые люди и не должны вестись на всякий желтый пиар. У Flow есть своя ниша но увы за пределами серьезной SF разработки.[/quote]

все так и есть. и отнекиваться от этих тулов больше не представляется возможным, так как можно прослыть "[i]старым отсталым ретроградом[/i]". Люди помнят как VFP была заменена на Aura, затем на LWC. И этот процесс был абсолютно неизбежным, т.к. отражал "эволюционное" развитие технологии. И такие же ожидания люди прикладывают на переход на LC/NC, хотя здесь перемены более революционные, чем эволюционные, и не все так однозначно

[quote="wilder"]А как картинки добавлять?[/quote]
Загрузить на какое-то хранилище картинок которое дает тебе прямую ссылку и использовать иконку картинки в меню редактора выше. Но нужна именно прямая ссылка так как она подставляется в тег <img>

[img]https://mixnews.lv/wp-content/uploads/2023/06/25/2023-06-25-mixnews-mycollages-30.jpg[/img]

[img]https://i.ibb.co/Kwjq1VF/image.png[/img]

Я использую этот сервис
https://ru.imgbb.com/

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

типа такого 
https://i.ibb.co/Kwjq1VF/image.png

Влезу с вопросом -  а лимиты которые в этих флоу всегда раньше падали уже пофиксили как-то?
Ведь раньше каждый флоу запускался отдельно, и если ты писал триггер на флоу, и таких было несколько чтук, это значило что в целом платформа просто несколько раз прокручивала одни и те же записи в цикле(если такой был внутри флоу), а при вставке кучи записей одновременно. Раньше еще был прикол, что флоу запускались в разнобой, сейчас вроде уже можно очередность выставлять,что очень хорошо

Но я в целом к флоу отношусь только как к запасному аэродрому, на нашем проекте много разных флоу, но за них отвечают админы, в них делается отправка email, или например time based действия. Есть еще флоу для отправки к нужному сапорт агенту людей, которые пришли в чат за помощью. И все эти части у меня нет ни малейшего желания поддерживать в апекс коде, поэтому флоу тут идеально вписывается, а писать на флоу калькуляции чего либо - ну нет, спасибо)

Скрин флоу тоже хорошая и интересная тема, когда нужно вывести что-то простое на странице и не тратить на это сутки

[quote="Maxim Elets"]сейчас вроде уже можно очередность выставлять,что очень хорошо[/quote]
Если я правильно помню вроде сортировка по имени дает очередность запуска

[quote="Maxim Elets"]Влезу с вопросом - а лимиты которые в этих флоу всегда раньше падали уже пофиксили как-то?[/quote]

возможно, и даже вероятно. Никаких пруфов у меня нет, но в моем понимании СФ делает все возможное, чтобы самый тупой Flow код-алгоритм работал

но это все надо тестить и гуглить

я вообще бы начал с изучения best practice about Flow, я помню были best practice about Process Builder, но до них как-то все не доходило. а вот теперь придется

Вот пример. Есть related list из него по кнопке открывается flow. Во flow показываются 3 компонента

[img]https://i.ibb.co/HGTZ5zY/Untitled.png[/img]

Ну что ж, погуглил я фразу Salesforce Flow Best Practices и первой выпадает вот эта статья:

https://admin.salesforce.com/blog/2021/the-ultimate-guide-to-flow-best-practices-and-standards

что выглядит справедливо, так как автор участвовал в разработке Flow

и вот три вещи оттуда:

(1) Статья начинается с фразы "[i]There’s no way around it: Salesforce Flow is the automation tool of the future[/i]", что можно вольно перевести "[i]Вам отвертеться: Salesforce Flow - это будущее[/i]". И здесь можно справедливо возразить: "[i]Ну а что ты рассчитывал услышать от самого автора тула?[/i]", да вот беда: идея того что Low Code / No Code - это наше будущее (и настоящее), уже попала в головы маркетологов, и они убедились, что этот подход очень нравится клиентам. И теперь буквально каждая презентация для клиентов начинается и заканчивается фразой Low Code / No Code Platform. В такой ситуации нет никакой надежды, что это временный хайп, что можно отвертеться или отсидеться в сторонке.

(2) Лимиты - оказывается они есть, все те же старые знакомые, со всеми вытекающими. Хуже того, там есть какие то специфичные и просто леденящие душу любого разработчика лимиты вроде "executed element limit", который работает даже на вложенные в цикл элементы и счет идет на каждую итерацию (!), что делает невозможной итерацию мало-мальски больших массивов. И этот момент (счет элементов в цикле) вроде как отменили уже, но сама мысль, что во Flow могут быть вот такие засады - это пугает. И как решение сложных ситуаций с лимитами, автор предлагает вызывать Apex code... Вот такой вот любопытный No Code :)

(3) Но больше всего мне было интересно, как в целом на архитектурном уровне организовать все эти Flow, на что автор отвечает: "[i]We’re still very much in the ‘wild wild west’ phase of record-triggered flows as architects and admins figure out the best way to incorporate them into their systems[/i]", что можно вольно перевести как "[i]да *** его знает, главное - чтоб работало[/i]".  И даже приводит пример, что для централизованной "оркестрации" можно использовать Apex trigger handler, который вызывает эти Flow.

Вот такое вот "новое будущее", которое нужно вызывать из все того же старого trigger handler :)

[quote="Den Brown"]Ну что ж, погуглил я фразу Salesforce Flow Best Practices и первой выпадает вот эта статья:

https://admin.salesforce.com/blog/2021/the-ultimate-guide-to-flow-best-practices-and-standards

что выглядит справедливо, так как автор участвовал в разработке Flow

и вот три вещи оттуда:

(1) Статья начинается с фразы "[i]There’s no way around it: Salesforce Flow is the automation tool of the future[/i]", что можно вольно перевести "[i]Вам отвертеться: Salesforce Flow - это будущее[/i]". И здесь можно справедливо возразить: "[i]Ну а что ты рассчитывал услышать от самого автора тула?[/i]", да вот беда: идея того что Low Code / No Code - это наше будущее (и настоящее), уже попала в головы маркетологов, и они убедились, что этот подход очень нравится клиентам. И теперь буквально каждая презентация для клиентов начинается и заканчивается фразой Low Code / No Code Platform. В такой ситуации нет никакой надежды, что это временный хайп, что можно отвертеться или отсидеться в сторонке.

(2) Лимиты - оказывается они есть, все те же старые знакомые, со всеми вытекающими. Хуже того, там есть какие то специфичные и просто леденящие душу любого разработчика лимиты вроде "executed element limit", который работает даже на вложенные в цикл элементы и счет идет на каждую итерацию (!), что делает невозможной итерацию мало-мальски больших массивов. И этот момент (счет элементов в цикле) вроде как отменили уже, но сама мысль, что во Flow могут быть вот такие засады - это пугает. И как решение сложных ситуаций с лимитами, автор предлагает вызывать Apex code... Вот такой вот любопытный No Code :)

(3) Но больше всего мне было интересно, как в целом на архитектурном уровне организовать все эти Flow, на что автор отвечает: "[i]We’re still very much in the ‘wild wild west’ phase of record-triggered flows as architects and admins figure out the best way to incorporate them into their systems[/i]", что можно вольно перевести как "[i]да *** его знает, главное - чтоб работало[/i]".  И даже приводит пример, что для централизованной "оркестрации" можно использовать Apex trigger handler, который вызывает эти Flow.

Вот такое вот "новое будущее", которое нужно вызывать из все того же старого trigger handler :)[/quote]

Это довольно древняя статья, но от apex даже спустя 2 года после выхода все равно никуда не деться :)
А в целом лимиты я погуглил: на элементы лимит был 2000, с 57 api версии их убрали совсем  :party::party:
То есть раньше если был цикл в флоу то каждый IF внутри цикла считался как элемент и значит если у тебя там было if else - это 3 элемента минимум то есть флоу мог пробежаться по 600 записям примерно, а потом он счастливо умирал :so-sad:

Вот здесь хорошо объяснены основные недостатки LCNC approach:


linkedin.com/pulse/why-low-code-no-code-just-doesnt-cut-software-development-

Вот кстати интересный ресурс попался на глаза - выгляди как набор инструкций по NoCode в одном месте

[url=https://help.salesforce.com/s/articleView?id=sf.extend_click_intro.htm&type=5]Extend Salesforce with Clicks, Not Code[/url]

[quote="Dmitry Shnyrev"]набор инструкций по NoCode в одном месте
[/quote]

ну это просто перечень для конфигурирования и кастомизация орга.

должна же быть какая-то грань между конфигурированием, дроп-энд-дропом и LCNC. 

LCNC -это все же программирование, декларативное, но программирование.

цель данной темы было не обсуждение того, почему мы любим или не любим, хотим или не хотим весь этот LCNC

LCNC уже здесь, и одно дело как с ним самому работать, а другое дело - как с ним вообще жить в одном орге.

и проблема в том, что в реальности это будешь НЕ ТЫ, кто будет делать все эти флоу в большом сложном орге, а другие люди. и в лучших традициях LCNC рекламы - "да любой с этим может работать" - это будут именно люди с таким уровнем подготовки. с околонулевым уровнем подготовки, понимания и ответсвенности, которые могут действовать так, как будто there is no tomorrow. а так как на такой уровне всегда большая текучка кадров, то для такого человека действительно нет нужды заботится о последствиях действий, так как он нашел уже новую работу

и с помощью инструментов LCNC все эти люди теперь могут делать довольно много, и прям проде. как с этим жить и выжить, вот в чем вопрос

[quote="Den Brown"]как с этим жить и выжить, вот в чем вопрос[/quote]
Не вижу проблем. Подготовить речь для клиента что все это плохо и это бомба замедленного действия. Запросить ХХХХХХ$ на переделку всего на lwc + apex. Если клиента это не устраивает то пожелать удачи в бизнесе и идти к другому клиенту. Клиентов/проектов много а ты один. Так нафига тратить свое время на поддержку/допилку говно-решений которые оставил твой предшественник???

Вот как вывод из этой темы давайте сформируем [b]список недостатков LCNC[/b], который можно будет использовать для аргументированного общения с клиентом. Почему LCNC плохо и к чему это может привести в долгой перспективе.

К примеру, вот это говно невозможно ни читать, ни дебажить. 

[img]https://d3nqfz2gm66yqg.cloudfront.net/images/20210614134532/Image_21.png[/img]

[quote="Dmitry Shnyrev"]можно будет использовать для аргументированного общения с клиентом. Почему LCNC плохо [/quote]

я не думаю, что в 2023 году у тебя еще есть такой вариант, если ты вообще хочешь работать с клиентом.
этот клиент начал этот проект, потому что повелся на LCNC. и уже видел своими глазами, что там много можно сделать интересного

есть только один вариант: как с этим жить, как митигировать импакт гавно-флоу на твой проект. а для этого нужно самому стать экспертов во всех этих LCNC тулах

как писал тот парень: "[i]Вам не отвертеться[/i]"

[quote="Den Brown"]я не думаю, что в 2023 году у тебя еще есть такой вариант, если ты вообще хочешь работать с клиентом.[/quote]

Тут я соглашусь, предложений стало куда меньше.
Самым правильным конечно будет сказать - флоу говно, вероятно столкнёмся с какими то косяками, но раз вам хочется, то можно. А потом когда что-то отвалится - переделывать на apex. По итогу будет опыт в флоу + денежка за работу, а потом денежка за переделку.

В целом большинству заказчиков не важно насколько инвалидски реализовано решение, ведь если работает, то работает.

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

сколько я помню Mulesoft, он всегда был LCNC тулом в основе которого было конфигурирование и декларативное программирование. при этом никто не говорит, что Mulesoft- это не серьезно, там "все иконки и картинки какие-то". так что Mulesoft был просто началом всех этих перемен

я думаю, что таким людям, как мы, нужно спокойнее относится к LCNC тулам, хорошо знать их и использовать везде, где это имеет смысл. и если в логике есть какой то момент, где только код поможет, вывести это в Action, но все равно в целом использовать Флоу. можно сказать - это новый уровень твоих программистских навыков - умелое жонглирование между кодом и Флоу

[quote="Den Brown"]я думаю, что таким людям, как мы, нужно спокойнее относится к LCNC тулам, хорошо знать их и использовать везде, где это имеет смысл. и если в логике есть какой то момент, где только код поможет, вывести это в Action, но все равно в целом использовать Флоу[/quote]
Хорошо, тогда скажите мне как работать двум разрабам над одним флоу? Вы забыли про git? Как мержить изменения. Как дебажить, скажем у меня не работает и мне надо вывести сериализованный в json List или Map. А как жить когда ты делаешь на сандбокс свой flow а клиент взял и на проде что-то поменял пока ты спишь, потому что
[quote="Den Brown"]все же лучше для клиента, там как ему его проще пофиксить или хотя бы понять.
[/quote]
В коде один Source of Truth и это git репозиторий. И что-то запороть в нем практически невозможно. А как вы представляете жизнь в более менее серьезном проекте где каждая собака идет и вносит изменения прямо на проде? Я помню на flow есть версии, но разве они помогают разрулить все вышеперечисленные проблемы?

лично я бы вообще сделал Production read-only и чтобы любые изменения можно было залить только через changeset или API. Никаких click решений и возможности повлиять на metadata даже админам разрабам. Вот тогда был бы порядок. Хочешь что-то поменять - делаешь сандбокс, меняешь и заливаешь changeset на Production. 

По ходу данной темы сильно заметно отсутствие опыта работы на реальных НЕ SF проектах (Java/.NET/Python). Наверное вам попадались исключительно проекты с мелкими клиентами где нужен максимум мелкий триггер/форквлов/флов максимум на посчитать какое-то поле или сделать небольшую валидацию.

А вы попробуйте запилить что-то типа уровня Jira на Salesforce. Посмотрю как вам LCNC помогут.

[quote="Dmitry Shnyrev"]А вы попробуйте запилить что-то типа уровня Jira на Salesforce. Посмотрю как вам LCNC помогут.[/quote]
А я скажу вам со сто процентной уверенностью что рано или поздно клиент вырастит из мелких флов и захочет что-то посерьезнее. 

Я считаю Salesforce просто уникальнейшим проектом аналогу которого нет из-за своего Apex/Visualforce/LWC. Покажите мне хоть одну другую CRM где возможно такое использовать (кроме 1С :smile:)? Такая гибкость кода в сочетании со стандартным UI это стоит многого. Так зачем отказываться от такого дара как код в пользу LCNC?????????????????????

Пока ни одного довода кроме "клиент туда может сам влезть и все сломать" в пользу LCNC я не услышал. 
Так что Apex Forever!!! :party:

[quote="Dmitry Shnyrev"]тогда скажите мне как работать двум разрабам над одним флоу? Вы забыли про git? Как мержить изменения. Как дебажить, скажем у меня не работает и мне надо вывести сериализованный в json List или Map. А как жить когда ты делаешь на сандбокс свой flow а клиент взял и на проде что-то поменял пока ты спишь[/quote]

вот именно именно именно поэтому я и начал эту тему. чтоб перечислит все засады и быть как-то к ним готовым.

[quote="Dmitry Shnyrev"]Пока ни одного довода... в пользу LCNC я не услышал.[/quote]

ты не осознал весь масштаб проблемы. во всех более менее крупных консалтинг конторах все менеджеры, директора, архитекты(кто сто лет не кодил и вообще уже едва соображает),все как загипнотизированные зомби повторяют "LCNC... LCNC...  LCNC.." и дирижирует этим сам... Salesforce

[quote="Den Brown"]ты не осознал весь масштаб проблемы. во всех более менее крупных консалтинг конторах все менеджеры, директора, архитекты(кто сто лет не кодил и вообще уже едва соображает),все как загипнотизированные зомби повторяют "LCNC... LCNC... LCNC.." и дирижирует этим сам... Salesforce[/quote]
Ну если с этой точки зрения и нет права выбора, то останется только подстраиваться под ситуацию и начинать изучать LCNC. Но а пока есть возможность пилить True Code решения, будем пилить эти самые решения.
А изучить те же самые Flow при необходимости не думаю что составит большого труда. За неделю я думаю можно освоить имея баграунд разработчика. 

ок, давай подведем какие-то итоги, друзья-флоуненавистники

(1) проблему с изменениями в проде решить невозможно (т.к. это не проблема, а фитча, спросите СФ), они это будут делать в любом случае. Но можно под страхом смерти требовать от них что-то писать в Description (здесь бы вообще внедрить какой-то change log) при изменениях, а также при работе с флоу в сендбоксе, каждый раз вначале делать push back флоу из прода. рефрешить сендбокс из-за каждого флоу апдейта не получится

(2) изучить вопрос с мерждем флоу метадаты. весь вопрос в том, насколько этот файл readable and understandable. здесь нужно просто пробовать

(3) знать все эти тулы ЛУЧШЕ чем те люди кто с ними работает. иначе ты будешь всегда зависим от их уровня профессионального развития, а это очень печальная судьба. если клиент LCNС - то уметь запилить флоу, ну такой в котором флоу - это логический каркас, и вся работа делает в апекс actions (к примеру)

(4) т.к. вся эта LCNC мания может быть началом каких-то сдвигов на маркете, то начать крутить головой в поисках "горячих" платформ. и хотя в СФ еще найдется работа на годы, он уже в стадии "дойной коровы", а это значит что новые клиенты могут вполне начать выбирать что-то дешевле и прикольнее. и конечно это будет LCNC платформа :smiley: