Подходы "Low Code" и "Zero Code" в настоящее время получают всё больше распространения в маркетинговых материалах и многие потребители программных продуктов начинают интересоваться декларируемыми преимуществами таких подходов.
Авторами систем, построенных на принципах "Low Code" и "Zero Code", заявляются такие преимущества, как сокращение капитальных и операционных расходов бизнеса при внедрении информационных систем.
Казалось бы - так оно и есть, если бы не одно "но". Дело в том, что заменяя решение задач автоматизации посредством программирования на специальном языке, имеющем многолетнюю историю, всем известные паттерны и антипаттерны применения, проверенные возможности ведения версий, развертывания и тестирования решением тех же задач через программирование алгоритма посредством конфигурирования параметров в окнах специального интерфейса или мастера конфигураций, невозможно избавиться от программистов, но программисты, или пользователи, выполняющие их роль, будут вынуждены программировать не на специально предназначенном для программирования языке, а в некой программе.
Казалось бы - так и надо, ведь это упрощает программирование и позволяет избавиться от дорогостоящих специалистов.
Однако, это не так. Дело в том, что главное в программировании - это не кодинг, а кодинг способом, допускающим наименьшее число ошибок в эксплуатации.
Поэтому, языки программирования постепенно эволюционировали от интерпретаторов типа "BASIC" и диалоговых систем, позволяющих быстро написать и запустить на выполнение что угодно силами самых низкоквалифицированных пользователей до современных компилируемых сред программирования, проверяющих не только типы переменных и констант при сборке, сигнатуры вызовов функций, но и заданные разработчиком контрольные выражения и тесты.
Использование современных компилируемых промышленных языков программирования и общепринятых подходов часто замедляет разработку, но в этом и заключается цель, ибо допустить ошибку или опечатку можно за долю секунды, а на то, чтобы её найти, могут потребоваться часы.
Поэтому, чем дольше производится разработка/настройка одного и того же, тем меньше вероятность, что в итоге будет получена система, работающая некорректно, хотя бы потому, что при более длительном времени разработки текст будет большее количество времени находиться перед глазами разработчика и просматриваться на предмет наличия ошибки.
Такое работает, разумеется, если производится работа с неким цельным куском текста или алгоритма, а не изолированной строкой в конструкторе, скрывающей соседние строки.
Кроме того, избавиться от дорогостоящих специалистов всё равно не удастся, как показывает опыт внедрения той же информатики. Просто если раньше специалисты могли делать задачи из других областей и использовать в работе знания из смежных проектов то после внедрения low coding системы специалисты становятся более "узкими" - это уже специалисты исключительно по информатике, например. Но им всё равно надо будет платить зарплату. И если ранее они были взаимозаменяемыми со специалистами бэка, то после перехода на систему программирования настройками их уже заменить будет невозможно, потому что никто из посторонних не будет знать, зачем когда и что предшественники поменяли в настройках.
Важен вопрос и опыта. Если при работе программистов отдела с классическими языками программирования с течением времени у заказчика появляется больше возможностей просто в силу того, что отдел накапливает опыт и начинает работать более эффективно, то при использовании систем zero coding'а опыт ничего не даёт, так как настройки меняются только через тот интерфейса, что предусмотрел поставщик системы и только тем способом, который система допускает.
Исходя из этого надо с очень большой осторожностью подходить к внедрению систем, программирование которых осуществляется настройками и понимать, что каждая конструкция в современном языке программирования возникла не просто так, для реализации амбиций и фантазий автора языка, а как компенсация за потерянные годы и нервные клетки предыдущих поколений разработчиков.
Отказаться от всего этого - это значит, вернуться в 60-е, без контроля цикломатической сложности графа исполнения программы, с повсеместным использованием безусловных переходов из любого места программы в любое место программы (что особенно характерно для BPM процессов), с невозможность, понять как будет обходиться граф исполнения без моделирования обхода графа исполнения (основной недостаток программирования на goto - зависимость способа обработки от контекста (истории), а не от места кода, осуществляюшщего обработку - появляется и в BPM). Если вспомним историю, то обнаружим, что блок-схемы появились в самом начале программирования, когда они 1-в-1 переносились на ассемблер. И отказались от них, разумеется, не потому, что не было технической возможности их нарисовать, а потому, что они не давали такого упрощения разработки, которую давало структурное прграммирование.
Что же делать, если уже внедрили Low Coding систему? Как быть? Как понять, что происходит?
Надо, во-первых, вернуться к классической разработке, которая основана на трудах Николауса Вирта, как можно больше функций вынося в код, который верифицируем тестами, контролируется в системах контроля версий и которму можно доверять, в отличие от настроек, внедрить процесс деплоя изменений и тестирования их в том числе и юнит тестами, чтобы стабилизировать систему. А, во-вторых, надо анализировать и контролировать то, что уже внедрено. По-другому никак - анализ логов и контроль.
Помочь в контроле и анализе могут инструменты и библиотеки процессной аналитики - по логам событий они умеют восстанавливать граф исполнения потока. Например, такие, как в pmkitten.com
Написано на Dotty и Wicket
!без Web 2.0!
Адаптировано для работы в Lynx
канал в Дзен