8 июля 2024 г.
Продолжение, начало здесь и здесь
Про актуальность LCNC (Low Code / No Code) для бизнеса, а также про развитие этого направления мы поговорили в первых двух частях, а сейчас сосредоточимся на недостатках и проблемах, связанных с этой технологией.
Проблемы с оптимизацией кода? Обойти можно!
Основные проблемы у LCNC, по сути, характерные для использования в разработке инструментов высокого уровня. Инструменты разработки становятся проще в использовании, но обратной стороной процесса является их загрубление, что ограничивает возможности создания оптимального кода. Низкую производительность решений, определяемую неоптимальным исходным кодом, отмечает Алексей Обухов, технический директор компании IW Group.
Сегодня эта особенность не является проблемой — вычислительные мощности достаточно велики для обеспечения быстрой работы бизнес-приложений, где в большинстве случаев не нужны сложные вычисления, а важно точное описание бизнес-логики. Кроме того, платформы LCNC допускают гибридные решения: фрагменты, которым действительно нужна скорость работы, — они, конечно, встречаются, хотя и немногочисленны — всегда можно написать на традиционных языках программирования, после чего легко и просто встроить в готовое приложение.
Проблемы с переносом решений? Их решать пока сложно
Решения, созданные при помощи LCNC, предоставляют широкие возможности для переиспользования кода в разных вариантах, но это только внутри платформы, на которой вели разработку. Однако есть проблема: переиспользовать модули легко и просто в рамках одной LCNC-платформы, но перенос между разными платформами проблематичен, если вообще возможен. Многие low-code платформы подразумевают одноплатформенность, напоминает Александр Сахаров, директор по работе с партнерами в компании «Диасофт», что создает огромное количество ограничений и проблемы с масштабирумостью и производительностью.
LCNC-платформ много, со взаимной совместимостью у них не очень хорошо, так как они специфичны. Ситуация, когда заказчик использует специфичное решение в рамках своей системы, увеличивает зависимость от поставщика, что влечет за собой соответствующие риски, напоминает Александр Субботин, руководитель отдела разработки Content AI.
В ряде ситуаций переносимость решений, созданных в рамках LCNC, оказывается не лучше, а хуже, чем у решений, созданных на традиционных методах. Компиляция традиционного кода для работы в экосистеме новой «операционки» тоже непростая задача, но перенос LCNC-решения на новую платформу существенно сложней; по существу, приложение придется писать заново, используя возможности целевой платформы.
Перенести решение можно только вместе с самой платформой, в ряде случаев это означает необходимость покупки дополнительной лицензии, а они стоят недешево. Для заказчиков это малоприятно. Компания, использующая LCNC-платформу, вынуждена искать решения, созданные именно для этого варианта, что существенно сужает выбор готовых продуктов. Можно, конечно, в ИТ-рельефе развернуть платформу, но это потребует дополнительных вложений на приобретение софта, усложнит администрирование компонент, а также потребует увеличения штата ИТ-специалистов — для развития прикладных решений нужны люди с опытом работы на разных LCNC-платформах. Для компаний в условиях кадрового дефицита особо проблематично расширение штата для привлечения специалистов с нишевыми компетенциями.
Важно, что LCNC-платформы активно совершенствуют, в том числе, и в направлении развития совместимости. «В кратко- и среднесрочной перспективе можно ожидать улучшений в области настройки low-code инструментов, что позволит разработчикам создавать более сложные приложения и лучше адаптировать их под конкретные потребности бизнеса, — уверен Василий Саутин, руководитель дирекции продаж IBS. — Также улучшение производительности может быть достигнуто за счет оптимизации архитектуры платформ и использования новых технологий».
В частности, это означает улучшение совместимости. Проблема с переносом решений сегодня существует и довольно остра, с течением времени ее будут смягчать общими усилиями игроков индустрии. «Современные low-code инструменты открыты, следовательно, создаваемый код может исполняться на любой открытой современной инфраструктуре», — говорит Александр Сахаров.
Проблемы с безопасностью? А они существуют?
Некоторые опрошенные нами эксперты отметили проблемы с безопасностью при использовании LCNC-инструментов. «Популяризация low-code оказывает негативное влияние на инфобезопасность», — уверен Алексей Обухов.
С одной стороны, они правы — в корпоративном ИТ-рельефе появляется еще одна платформа, что увеличивает поверхность атаки и, как следствие, усложняет администрирование, мониторинг и прочие действия, нужные для обеспечения инфобезопасности. С другой стороны, появление очередной платформы в корпоративном рельефе вряд ли радикально ухудшит ситуацию с ИБ, а с обеспечением безопасности платформы проблем меньше, чем с решениями, построенными традиционными методами (в этом случае уязвимости могут быть в самом коде, в используемых библиотеках и т. д.).
Большинство опрошенных экспертов отмечают повышение уровня безопасности при использовании LCNC. «В большинстве случаев low-code инструменты позволяют использовать только хорошо протестированные, безопасные и стабильные компоненты, — говорит Александр Чиченин, технический директора ITentika. — Положительно сказывается централизация и стандартизация компонентов».
С этим согласен Максим Кислицкий, руководитель направления по разработке low-code-платформы частного учреждения по цифровизации атомной отрасли «Цифрум»: «На наш взгляд, применение платформ повышает информационную безопасность и хорошо сочетается с SecOps, так как вместо проектирования подсистемы безопасности „с нуля“ под каждый проект применяются готовые и оттестированные платформенные решения».
Но следует заметить, что применение LCNC не обеспечивает перечисленные преимущества автоматически. «Важно понимать, что безопасность — это не автоматическая функция low-code платформы, — говорит Андрей Кувалдин, заместитель директора по развитию программных продуктов в компании „Транссеть“. — Разработчики и пользователи должны уделять ей внимание, независимо от используемых инструментов». Для достижения нужного уровня безопасности разработку на low-code нужно включать в традиционный стек, с DevOps, SecOps, TestOps и т. д.
Более широкий взгляд на проблематику позволяет увидеть дополнительные механизмы, которые увеличивают безопасность при использовании LCNC. «Low-code подход минимизирует риски при автоматизации процессов, позволяя быстро проверять гипотезы, создавать MVP, учитывать бизнес-требования заказчиков», — напоминает Юрий Востриков, генеральный директор компании BPMSoft (входит в IT-холдинг LANSOFT).
LCNC создают проблемы циклам традиционной разработке? Нет
Добавление нового инструмента в существующий конвейер разработки всегда несет с собой определенные сложности, но для специалистов по DevOps появление в LCNC не создает каких-либо проблем особой сложности. «Использование low-code в DevOps-практиках упрощает автоматизацию и улучшает сотрудничество между разработчиками, тестировщиками и операционными командами», — отмечает Василий Саутин. Конечно, нужно интегрировать в группу девелопмента группу новых разработчиков, пересмотреть процедуры взаимодействия команд, расширить тестовые процедуры с учетом особенностей нового инструмента и т. д., но это стандартные задачи для DevOps-инженера.
Современные low-code инструменты при генерации кода учитывают принципы и требования DevOps, подтверждает г-н Сахаров, приводя в качестве примера Digital Q.Security, платформенные продукты «Диасофта», которые в настоящее время проходят сертификацию ФСТЭК.
«Компании, которые стремятся улучшить процессы разработки программного обеспечения, активно используют интеграцию разработки low-code с практикой DevOps», — говорит Сергей Сосин, руководитель группы продуктового менеджмента в Nexign, отмечая, что компания применяет такие интеграции для повышения безопасности процесса разработки ПО, создания сложных масштабируемых продуктов и решений, повышения гибкости их доставки и снижения сложности эксплуатации за счет готовых low-code инструментов для адаптивной настройки.
Сказанное справедливо и для процедур тестирования. Для организации этого процесса нужны прежде всего требования к продукту и ожидаемые результаты, напоминает Мария Шалаева, владелец продукта «Платформа» компании GoodsForecast: «Тестировщик может и не знать, что „под конечным продуктом“ — low-code-платформа». Но все же тестировщикам следует понимать особенности работы low-code-платформ, признает г-жа Шалаева.
Гибридный подход может усложнить процедуры тестирования, требуя интеграции различных тестовых процессов и инструментов, но также может повысить эффективность и качество тестирования за счет использования средств автоматизации, напоминает г-н Саутин.
Окончание следует
Источник: Александр Маляревский, внештатный обозреватель IT Channel News
