Разработка ПО

Современные платформы для разработки без программирования или с написанием минимального объема программного кода (low-code/no-code) позволяют группам разработчиков ПО – и даже людям, не имеющим подготовки в области программирования – создавать, поддерживать и расширять достаточно большой спектр приложений. Среди наиболее распространенных сфер их применения следует отметить создание мобильных приложений, улучшение клиентского опыта (Customer Experience, CX), оптимизацию рабочих процессов, модернизацию унаследованных приложений, автоматическую интеграцию данных и поддержку их визуализации.

Основное преимущество таких инструментов заключается в том, что они могут успешно использоваться теми, кто создает приложения для массового потребителя и не имеет глубоких навыков программирования. С их помощью они могут создавать приложения быстрее и дешевле, чем на основе традиционных SDK. При этом многие (но не все) коммерческие системы low-code нивелируют экономию на стоимости рабочей силы увеличением лицензионных отчислений или платы за подписку.

Затраты и экономия low-code/no-code

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

В качестве иллюстрации приведем следующие расчеты. Разработчики уровня бакалавра в США обходятся в год от 50 тыс. до 120 тыс. долл. (в среднем 72 тыс. долл.), а на создание с нуля простых приложений потребительского класса с написанием программного кода уходит от 6 до 25 человеко-месяцев (в среднем 12), так что разработка такого приложения обходится примерно в 72 тыс. долл. Разработка сложных приложений может стоить более 1 млн долл.

Если вы используете систему разработки low-code, которая сокращает время создания простого приложения до одного человеко-месяца (при затратах примерно в 6 тыс. долл.), но плата за лицензии составляет 10 долл. на пользователя, то при наличии 6600 пользователей ваши общие расходы превысят стоимость традиционной разработки. Но, опять же, это только приблизительная оценка.

В таком случае инструмент, плата за который устанавливается в расчете на количество приложений, серверов или разработчиков, может оказаться более выгодным вариантом. С другой стороны, при создании большого количества приложений для внутреннего пользования и наличии нескольких сотен сотрудников, выгоднее оплачивать лицензии на каждого пользователя.

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

No-code или low-code?

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

Для инструмента категории low-code, кривая обучения может оказаться круче, чем в случае no-code, но барьеры на пути расширения возможностей приложений здесь, как правило, ниже. Вместо покупки очередного компонента достаточно написать несколько строк кода, обращающегося к базовой системе, программе Open Source или API поставщика платформы.

В некоторых средах, для которых характерен минимальный уровень программирования, в определенных ситуациях можно обойтись и вообще без него. Другими словами, до определенного момента среда может использоваться без написания программного кода. В этом случае 95% необходимых работ выполняют бизнес-пользователи, а программист пишет код для оставшихся 5%. Эти цифры будут варьироваться в зависимости от конкретного приложения и инструмента.

Зачастую бывает так, что код, который требуется написать, семантически похож на уже знакомый вам язык. Например, инструмент Microsoft Power Fx базируется на Microsoft Excel, а Xbasic компании Alpha Software вырос из Microsoft Basic. Во многих инструментах low-code фигурирует язык, который либо тесно связан с JavaScript, либо использует реальный движок JavaScript, такой как V8.

Бытует мнение, что на самом деле инструменты no-code представляют собой инструменты low-code, которые пытаются продать бизнес-пользователям. Более реалистичная точка зрения заключается в том, что всем коллективам – как ведущим разработки без программирования, так и пишущим небольшие объемы программного кода – все равно нужны профессиональные разработчики, создающие компоненты, которые бизнес-пользователям не под силу. Сюда относятся схемы баз данных, разработка компонентов, системная архитектура, проектирование пользовательского интерфейса и проверка качества.

Виды инструментов для разработки low-code/no-code

Прежде чем инициировать покупку инструмента для разработки low-code/no-code, следует задать себе несколько вопросов о приложении, которое вы будете предлагать, с тем чтобы понять, имеет ли все это для вас смысл. Предлагаю вам записать ответы на следующие вопросы.

— Вы собираетесь создавать настольное приложение? Для Windows? Для Mac? Для Linux? Для всего перечисленного?

— Собираетесь создавать веб-приложение? Для браузера на настольном ПК? Для планшетов? Для смартфонов? Для всего перечисленного?

— Планируете писать нативный код для мобильных устройств? Использовать гибридную веб-технологию? Использовать нативную среду и веб-контент? Использовать все перечисленное?

— У вас уже есть бюджет? Какой? Есть конкретные сроки? Насколько быстро надо все сделать? Сколько у вас разработчиков? Какими навыками они обладают? Согласуются ли ваш бюджет, сроки и ресурсы с целями создания приложения? Как вы это оценивали?

— Нужна ли вашему приложению база данных? Если да, идет ли речь об уже существующей базе данных или о новой? Будут ли клиенты обновлять базу данных?

— Нужно ли вашему приложению поддерживать связь с клиентами? Нужны ли другие специальные функции?

— Вы создаете приложение для внутреннего пользования? Для заказчиков или для массового рынка? Для бизнес-партнеров? Для всех перечисленных категорий?

— Будут ли меняться или модернизироваться существующие бизнес-процессы? Пытаетесь ли вы оцифровывать существующую бумажную форму?

Как следует из этого перечня вопросов, в мире существует много разных целевых сред, предназначенных для тех или иных приложений. А у инструментов low-code/no-code есть много разных парадигм разработки.

Настольные приложения могут создаваться для Windows, macOS, Linux, а иногда даже DOS. Мобильные – на Android, iOS и разновидностях этих операционных систем для планшетов и часов. К веб-приложениям относится практически все вышеперечисленное, а также дополнительная поддержка браузеров (Chrome, Edge, Safari, Firefox и Opera) и возможность адаптации к различным размерам экранов. Гибридные веб-приложения сочетают в себе свойства нативных приложений и веб-контента.

Парадигмы проектирования предусматривают настройку прототипов приложений; перетаскивание с использованием таблиц свойств и небольших фрагментов кода; описания декларативных полей; преобразование отсканированных форм; преобразование каркасных или графических структур и генерацию форм из схем базы данных. Сами элементы управления могут быть встроены в платформу или реализованы как часть исполняемой среды инструмента.

Серверные возможности могут включать поддержку аутентификации и подключения к базам данных, облачным сервисам и корпоративным приложениям. Мобильные приложения могут поддерживать текстовые сообщения, push-уведомления, геолокацию, фото- и видеосервисы, сервисы идентификации и интеграции с социальными сетями. Приложения, использующие серверные сервисы, могут работать даже при прерывании подключения, зная, как разрешать конфликты данных, возникающие, когда сразу несколько пользователей пытаются обновить базу данных, которая находится в автономном режиме.

Известные платформы разработки low-code/no-code

В последний раз, когда я детально исследовал эту сферу, там было представлено более 400 вендоров. В Gartner своим анализом охватили около 250, пытаясь разбить их на постоянно меняющиеся категории. Многие вендоры и некоторые продукты подпадают под определение сразу нескольких категорий.

Не думаю, что средства управления бизнес-процессами (business process management, BPM) и роботизации бизнес-процессов (robotic process automation, RPA) следует объединять с другими инструментами low-code/no-code. Разница, на мой взгляд, заключается в том, что для инструментов BPM и RPA автоматизация и настройка систем является их основной целью. Обычные же инструменты разработки могут использовать корпоративные системы, но только в качестве средства для достижения другой цели.

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

В качестве иллюстрации я отобрал семь поставщиков систем low-code/no-code перечислив их в алфавитном порядке. Учтите, что включение в этот список не следует трактовать как рекомендацию, а исключение не является приговором.

- Alpha Software. Alpha Anywhere – инструмент полного цикла быстрой разработки low-code, который предназначен для создания разработчиками самой разной квалификации настольных приложений, веб-приложений и гибридных мобильных приложений, ориентированных на базы данных. Alpha TransForm – инструмент low-code/no-code, позволяющий разрабатывать мобильные формы с автономными возможностями и автоматической синхронизацией при возобновлении подключения.

- Appian. Appian предлагает визуальный конструктор no-code и инструменты low-code для создания веб-приложений и мобильных приложений, которые интегрируются с корпоративными данными без программирования. Кроме того, у Appian имеется платформа автоматизации для BPM и RPA.

- Claris. Claris FileMaker – система для разработки настольных, веб- и мобильных приложений категории low-code, включающая собственную базу данных. Она имеет встроенные шаблоны, поддерживает проектирование путем буксировки и интуитивный графический пользовательский интерфейс. Claris Connect – платформа автоматизации, построенная на том же ядре, что и FileMaker.

- Mendix. Mendix Studio – WYSIWYG-среда на основе браузера для разработчиков, которые создают приложения для массового потребителя. Mendix Studio Pro – среда с классическим интерфейсом дл ПК, включающая в себя все возможности, которые нужны для создания приложений, в том числе возможность добавления при необходимости программного кода. Mendix предлагает также платформу автоматизации и систему интеграции данных.

- Microsoft. Microsoft Power Apps – конструктор для Windows 10, требующий написания минимального объема программного кода и поддерживающий шаблоны, перетаскивание компонентов и Excel-подобный язык программирования Power Fx. В Power Apps используется языковая модель, способная генерировать код Power Fx из описаний на естественном языке. Профессиональные разработчики могут расширять возможности Power Apps с помощью Azure Functions и специальных коннекторов. Power Automate – отдельная RPA-платформа c поддержкой документооборота.

- OutSystems. Система OutSystems позволяет перетаскивать визуальные элементы для создания пользовательских интерфейсов, бизнес-процессов, бизнес-логики и моделей данных для веб-приложений и мобильных приложений, а также дополнять их программным кодом при возникновении такой необходимости. В ее состав входит 70 уже готовых шаблонов. Инструмент OutSystems Forge содержит тысячи модулей с программным кодом, которые можно перетаскивать в приложение и при желании расширять в среде IDE.

- Salesforce. Salesforce Lightning – инструмент для создания приложений на Salesforce Platform с возможностью буксировки и написанием небольшого объема программного кода. Lightning App Builder позволяет бизнес-пользователям выбирать модули для проектирования приложений. Lightning Web Components помогает создавать повторно используемые элементы.

Ключевые факторы при выборе платформы low-code/no-code

Помните длинный список вопросов, который вам следовало задать себе? Теперь пришло время свериться с ответами. Универсальной системы разработки, подходящей на все случаи жизни, не существует, даже если вы испытываете потребность в стандартизации на базе одной системы в масштабе всего предприятия. Очень скоро выяснится, что разным подразделениям нужны разные продукты разработки для разных целей.

— Подходит ли вам модель оплаты? Для потребительских приложений системы с написанием минимального объема программного кода, требующие оплату лицензии на каждого пользователя, вряд ли можно считать оправданными. Многие поставщики указывают цены на своих сайтах. У других, чтобы узнать их, необходимо связаться с отделом продаж. Стесняться этого не стоит. Поинтересуйтесь ценами и сравните их с той информацией, которая уже имеется у вас о других поставщиках.

— Поддерживает ли предлагаемая платформа все желаемые цели? Если нет, продолжайте поиски. Если ни один из имеющихся вариантов не охватывает все желаемые цели, подумайте о сокращении списка целей с оставлением там наиболее важных устройств или браузеров.

— Соответствует ли платформа вашим навыкам разработчика? Подумайте о возможности коллективного проектирования приложений, которое позволит не зависеть от единственного разработчика и охватить все необходимые навыки. Если ваш коллектив не обладает всеми навыками, которые нужны для использования того или иного инструмента, продолжайте поиски. Возможно, какой-то другой продукт больше подходит вашей команде. Если ни с одним из инструментов вы справиться не можете, надо либо проходить переподготовку, либо нанимать дополнительных специалистов, либо делать и то, и другое.

— Поможет ли инструмент оптимизировать сроки разработки? Главным преимуществом инструментов, не требующих написания большого объема программного кода, является ускорение вывода приложений на рынок. Если этот фактор имеет для вас важное значение, нужно оценить, сколько времени потребуется для завершения проекта. Попросите поставщика оценить сроки исходя из ваших требований и опыта реализации аналогичных проектов. Попросите сделать то же самое разработчика, имеющего опыт использования соответствующего инструмента. Учтите, что при оценке сроков определенное время надо выделить на стадии тестирования и подготовки документации, а также на начальный этап проектирования и окончательное развертывание.

— Поддерживает ли платформа масштабирование? В некоторых решениях присутствуют узкие места, ограничивающие одновременный запуск приложения большим количеством пользователей; тогда как другие успешно справляются с очень большой нагрузкой. В некоторых ситуациях узкие места можно обойти на стороне сервера, запустив несколько серверов за системой сбалансирования нагрузки. Поставщик должен сообщить, с каким количеством пользователей справляется типичное приложение, но перед окончательным развертыванием необходимо провести нагрузочное тестирование.

— Отвечает ли платформа ожиданиям пользователей? Потребители ждут, что приложения будут реагировать на их действия за доли секунды и иметь привычный пользовательский интерфейс. На смартфоне, например, стоит протестировать прокрутку длинного списка. При ускорении движения управляющего элемента она должна выполняться быстрее, а при его замедлении соответствующим образом замедляться, прежде чем произойдет окончательная остановка.

— Не забывайте о необходимости доказательства выбранной концепции. Нельзя ограничиваться лишь пассивным изучением продукта в свободное время. Смоделируйте простой пример того, что вам предстоит сделать, и создайте приложение, подтверждающее концепцию. Заниматься этим лучше самостоятельно. Обращайтесь к поставщику лишь в том случае, если ваши сотрудники сами не справляются.

Разработка приложений с написанием минимального объема программного кода сулит немалую выгоду. С одной стороны, слишком многие компании настаивают на том, что мобильные приложения должны иметь нативный программный код, после чего с изумлением узнают, что придется потратить 1 млн долл. и год на создание приложения для iOS, а затем еще 500 тыс. долл. и полгода на практически идентичное приложение Android. Имеет смысл сначала изучить альтернативные варианты с точки зрения как сокращения расходов, так и ускорения вывода приложений на рынок.

С другой стороны, многие полагают, что с инструментами, позволяющими создавать приложения без написания большого объема кода, бизнес-пользователи справятся и без помощи профессиональных разработчиков и администраторов баз данных, а затем неожиданно сталкиваются с тем, что проект провалился. Если вы будете избегать крайностей и ставить четкие цели, велика вероятность, что вам удастся сформировать команду, которая умеет (или в состоянии в короткие сроки научиться) хорошо и быстро создавать приложения в парадигме low-code.

Написание приложений с нуля — трудоемкий процесс, требующий серьезных навыков разработки, часто сильно зависящих от целевой платформы. Платформы и инструменты разработки категории low-code (а иногда и no-code) ускоряют и снижают требования к квалификации участников процесса разработки, хотя у них есть свои собственные траектории обучения специалистов.

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

Существует несколько альтернативных парадигм проектирования приложений в режиме low-code — генераторы, шаблоны и простые языки конструирования. Например, генераторы, которые просматривают ваши базы данных и генерируют формы с привязкой к данным для каждой таблицы базы данных, позволяют начать работу очень быстро, в дальнейшем редактируя в соответствии с дополнительными требовании первоначально сгенерированные формы. Шаблоны более привлекательны, но менее гибки. Некоторые среды позволяют начать со сканирования форм, нарисованных на бумаге; другие позволяют начать с изображений, выполненных в Photoshop.

Задачи для разработки low-code такие же, что и для приложений, написанных вручную: настольных, веб- и мобильных. Настольные приложения обычно рассчитаны в рамках графических интерфейсов пользователя Windows, macOS и Linux. Веб-приложения должны работать во всех браузерах (Chrome, Edge, Safari, Firefox и Opera), и им необходимо оперативно обрабатывать различные размеры экрана. Мобильные приложения в первую очередь ориентированы на iOS и Android. Гибридные веб-приложения совмещают собственную оболочку с веб-контентом.

Некоторые платформы low-code генерируют нативный код, поэтому внешний вид и скорость создаваемых ими приложений очень похожи на приложения, написанные вручную. Другие исполняются интерпретатором, что иногда может порождать проблемы с производительностью, но этот вариант может быть достаточно хорош для приложений, которые не предполагают массового использования.

Условия лицензирования у разных поставщиков платформ разработки low-code сильно различаются. Некоторые схемы ценообразования могут сделать продукт непригодным для использования — например, плата по числу пользователей при применении к потребительским приложениям с потенциально очень широкой аудиторией.

Что такое разработка no-code?

Разработка no-code — это, по сути, та же разработка low-code, но без языка программирования, который вы могли бы использовать в продукте. Создатели подобных платформ иногда создают ухищренные визуальные инструменты, призванные заменить написание фрагментов кода, но инструменты эти, как правило, неудобны и отнимают много времени.

Платформы no-code, как правило, удобны и простоты в начале цикла разработки. К сожалению, у них часто есть ограничения, которые рано или поздно начинают мешать разработке — вплоть до ее остановки. Поставщики платформ иногда обходят эту проблему, предлагая целый маркетплейс модулей, которые можно интегрировать с разрабатываемыми приложениями, чтобы расширить их функции. Профессиональным же разработчикам они иногда даже предлагают SDK, с помощью которых можно писать новые модули.

Кто занимается разработкой low-code?

Продавцы low-code обычно говорят о нескольких типах пользователей своих продуктов. К ним относятся «гражданские разработчики» или «высококвалифицированные пользователи», а также бизнес-аналитики, администраторы баз данных и профессиональные программисты.

Чтобы добиться успеха, команда, занимающаяся разработкой в режиме low-code, должна понимать бизнес, знать платформу разработки, понимать существующий ИТ-ландшафт (особенно корпоративные приложения и базы данных) и обладать поддержкой со стороны руководства. Иногда удается найти одного человека со всеми необходимыми навыками, однако как правило необходима группа, которая готова работать вместе.

Существуют ли гражданские разработчики?

Термин «гражданские разработчики», похоже, пришел из мира аналитических систем, и у него тяжелое прошлое. Фактически, речь идет о не-разработчиках, не проходивших специального обучения, на которых тем не менее возложена ответственность за конфигурирование приложений. Я встречал несколько «гражданских разработчиков», так что они действительно существуют, но я обнаружил, что хорошие их представители быстро учатся кодировать на базовом уровне и свободно пользуются своим набором инструментов из разряда low-code. Однако большинство «гражданских разработчиков» знают только то, что им нужно, об инструментах, которые им необходимы для выполнения их обязанностей, оставляя собственно программирование другим людям.

В преимущества разработки low-code?

Разработка low-code часто сокращает время, необходимое для создания приложений, и снижает затраты. Она позволяет сотрудникам, обладающим лишь базовой квалификацией в сфере ИТ, вносить свой вклад в разработку, не полагаясь полностью на программистов и администраторов баз данных. На самом деле менее квалифицированные сотрудники могут оказаться теми, кто лучше всего понимает бизнес и цель приложения. «Менее квалифицированный» здесь относится лишь к их уровню знаний в области программирования.

Когда следует использовать разработку low-code?

Если вы уже обладаете платформой low-code с разумной лицензией, которая позволяет вам быстро создавать приложения, со всеми необходимыми возможностями и интеграциями и приемлемой производительностью, вам следует пользоваться ею всякий раз, когда это возможно. Единственными исключениями могут быть потребительские приложения, для которых производительность более важна, чем время вывода на рынок и минимизация затрат на разработку.

В целом, платформы разработки low-code могут найти себе применение в самых разных компаниях — от предприятий с многолетним отставанием в разработке приложений до тех, которые готовы производить своими силами любые необходимые им программные системы. Считайте low-code своим секретным оружием.

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

Архитектор операций машинного обучения (MLOps) и DevOps в GitLab Монмаюри Рэй попробовала пояснить, какое влияние машинное обучение оказывает на изменение порядка прогнозирования и принятия решений.

Экономическая модель искусственного интеллекта

Рассматривая все это через призму экономики и бизнеса (а не разработки ПО и системного анализа), она указывает на снижение роли прогнозирования, которое является составной частью экономической модели искусственного интеллекта. К другим параметрам относятся данные, мощь аналитических технологий и вклад человеческого фактора.

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

И хотя все здесь сводится к вопросу реализации рутинной части ИТ-стека, а многим организациям концепция понятна, в применении машинного обучения при решении реальных задач по-прежнему видны пробелы. Технологические гиганты, такие как Google и Tesla, действительно способны эффективно использовать системы машинного обучения, но среднему предприятию еще только предстоит осуществлять переход к масштабному применению соответствующих инноваций.

«Вместе с тем нам есть, чему поучиться у Google и Tesla, поскольку по мере внедрения моделей машинного обучения экономика покупки интеллекта тоже меняется, – указала Рэй. – Нужно понимать, что сегодня за хорошую и плохую модель машинного обучения мы платим одинаковую цену. А какой сорт кофе покупать, если все продукты продаются по одинаковой цене? В этом и заключается экономическая дилемма моделей машинного обучения: поскольку мы платим одинаковую цену как за хорошую, так и за плохую модель, обратная связь и точность становятся ключевыми элементами, фундаментальной основой внедрения и масштабирования передового машинного обучения, которую нельзя ставить под угрозу».

Bing: меняться надо быстрее

По мнению Рэй и ее коллеги из GitLab, утверждение это хорошо иллюстрируется неспособностью Bing конкурировать с поисковыми технологиями Google на любом более или менее существенном уровне. С учетом того, что Microsoft Bing занимает менее 3% мирового поискового рынка, в операционном плане соответствующая технология отличается от технологии Google из-за соответствующих циклов обратной связи и увеличения времени, затрачиваемого на переосмысление рекомендаций Bing, которые, по сути, формируются за счет функций машинного обучения.

«Чтобы повысить точность модели и использовать машинное обучение в качестве службы общего назначения, можно задействовать различные системы, – делает вывод Рэй. – Одна из них должна автоматизировать выполнение повторяющихся задач, связанных с машинным обучением, с тем чтобы сократить продолжительность цикла обратной связи и снизить стоимость прогнозирования и принятия решений».

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

Но здесь все не так просто. Разработчики программного обеспечения делового назначения сталкиваются с революционным ростом разнообразия оборудования в виде процессоров, облаков, устройств на границах сети и т.д. Каждый из производителей чипов, будь то Nvidia, Intel или другая компания, имеют свои собственные специфичные библиотеки и платформы. Проблема усугубляется тем, что сегодня разработчикам приходится вручную оптимизировать и настраивать модели машинного обучения для каждого из аппаратных лагерей.

Генеральный директор компании OctoML Луис Сезе пытается решать соответствующие задачи совместно с сооснователем компании и ее директором по продуктам Джейсоном Найтом. Оба они активно высказываются на тему того, как использовать машинное обучение для улучшения самого машинного обучения.

Миллиарды вычислений для одного алгоритма

Команда OctoML считает, что цель любого ИТ-директора заключается в максимально быстром и эффективном с точки зрения затрат внедрении инноваций искусственного интеллекта. Но реалии таковы, что 90% приложений искусственного интеллекта и машинного обучения так и не появляются на рынке. Проблема сегодня заключается в том, что средства машинного обучения требуют специального проектирования и серьезных вычислительных ресурсов, что приводит к высоким затратам на облачные сервисы и делает их неподходящими для развертывания на границах сети.

«В условиях, когда машинное обучение становится все более и более популярным (в сферах компьютерного зрения, NLA/NLP, производства контента и т.д.), объем вычислительных мощностей, которые требуются для машинного обучения, непомерно растет, – констатируют Сезе и Найт. – Во многих случаях (возьмем какую-нибудь масштабную модель, например, GPT-3) разработчики выполняют миллиарды и миллиарды вычислений, чтобы получить от алгоритма лишь один ответ».

Созданный на базе Apache TVM проект OctoML предназначен для упрощения производственного запуска моделей машинного обучения за счет автоматического повышения производительности моделей на любом оборудовании в популярных средах машинного обучения Pytorch, TensorFlow и ONNX. Еще раз, речь здесь идет об автоматизации развертывания самой модели машинного обучения.

Тестирование программ и возможности тестирования

Возвращаясь к GitLab, стоит отметить, что свет в конце тоннеля уже виден. Опрос GitLab DevSecOps Survey 2021 свидетельствует о расширении использования программных ботов машинного обучения для создания программного обеспечения на этапе тестирования.

В 2020 году только 16% опрошенных сообщили о наличии у них ботов для автоматического тестирования программного кода и об использовании инструментов искусственного интеллекта и машинного обучения при выполнении процедур тестирования. В этом году их доля выросла до 41%. При этом 25% респондентов используют боты для тестирования программного кода, 16% оценивают код с помощью средств искусственного интеллекта и машинного обучения перед передачей его человеку и 34% изучают возможность применения искусственного интеллекта и машинного обучения, не предпринимая пока практических шагов.

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

Бизнес-руководителям нравится идея средств разработки, которые требуют минимального объема написания кода (Low-Code) или даже совсем не требуют (No-Code). Меньше кода, значит — меньше работы, проекты реализуются быстрее за меньшие бюджеты, а в конечном счете топ-менеджеры быстрее получают премии. Кому такое не понравится?

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

И тем не менее, у решений, которые сводят кодирование к минимуму, есть свои применения. Программисты ценят их за возможность выпустить работоспособную систему за короткое время с меньшими трудозатратами. Инструменты Low-Code позволяют, в частности, создавать эффективные средства поиска, сортировки и других манипуляций с табличными данными. Поэтому когда это действительно уместно, разработчики готовы пользоваться такими инструментами.

Но в то же время им не хочется быть загнанными в угол присущими средам Low-Code ограничениями, в том числе необходимостью отработки всех граничных случаев и обхода ситуаций, с которыми система не справляется нужным образом автоматически. Программистам приходится возиться с недоработками и недокументированными возможностями таких систем и прикладывать усилия, изобретая способы выполнения пользовательских запросов об изменении поведения стандартных функций.

Разработчики оказываются в ловушке, когда маркетинговые обещания оказываются далекими от реальности: работа с инструментами Low-Code происходит медленнее и может вызывать больше сложностей, чем реализация всей функциональности путем написания кода.

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

1. Проблемы сопровождения и развития

Самая сложная часть работы с решением категории Low-Code обычно ждет вас через несколько лет после внедрения созданной в нем системы. Она прекрасно работает, но постепенно накапливаются запросы на исправления и усовершенствования. Нередко эти доработки выходят за пределы возможностей системы с минимумом кодирования, в связи с чем выполнить их непросто. Если бы в вашем распоряжении был исходный код, его можно было бы частично переписать, но его нет. И если бы разработчики знали, что в дальнейшем понадобится такая-то возможность, они бы, вероятно, изначально приняли другие решения, например воспользовались бы совершенно иным фреймворком. Но этого не произошло и теперь вы — в тупике.

2. Все получают одно и то же

Есть в ресторанах одной и той же сети — это для тех, кто не любит удивляться. Бизнес-модель таких сетей состоит в том, чтобы экономить, предлагая во всех заведениях единое меню, оформление и стандарты обслуживания, но заманчивее они от этого не становятся.

Так и системы, созданные при помощи одного и того же инструментария Low-Code, выглядят сделанными «под копирку». Имея минимальный опыт, разработчик может беглым взглядом определить, какой именно инструмент использовался для разработки системы — движок «проглядывает» сквозь нее независимо от настроек, заставок и CSS-«обложек». Часть пользователей это устраивает, если для них лучше, чтобы интерфейс выглядел привычным, но другим нужен элемент новизны.

3. Универсальных инструментов не бывает

Производственники отдают предпочтение серийной продукции, поскольку для нее проще организовать конвейер. Многие покупатели же, напротив, ненавидят «штамповку», желая, чтобы уважали их индивидуальность.

Решения Low-Code просты в использовании, но одинаковы в своей ограниченности. Вам доступно мало возможностей изменения, настройки и написания кода — вам приходится работать с тем, что есть, и с этим ничего не поделаешь. В итоге недовольны и программисты, и пользователи.

4. Иногда написать код проще, чем выполнить настройку

Практика принижения объема трудозатрат на настройку программного обеспечения — стратегическая ошибка. Она может быть обусловлена принципом оплаты за строку написанного кода или тем, что руководство привыкло искать компромисс между созданием нового кода и покупкой готового продукта. Так или иначе, но бытует представление о том, что изменение параметров в конфигурационных файлах платформы или инструментария не составляет особого труда.

О том же заявляют и поставщики инструментов Low-Code: вы не пишете код, когда выбираете алгоритмы, соединяетесь с базой данных и вводите параметры. Это просто настройка, а как все знают, настройку можно выполнить даже на смартфоне, находясь в шумном баре. На самом деле возня с конфигурационными файлами может занять дни и недели прежде чем будет достигнут нужный результат, однако поставщики систем пытаются убедить заказчиков в том, что это «не работа», даже если она отнимает больше времени, чем написание кода.

5. Полет вслепую

Программисты привыкли пользоваться средствами отладки, которые позволяют остановить выполнение программы в любой точке, чтобы просмотреть состояние переменных и уточнить, что происходит внутри алгоритма. Инструменты Low-Code же для «простоты» скрывают внутренности программы от разработчика.

Если решения на базе Low-Code ведут себя, как ожидалось, проблем с этим нет. Но часто бывает так, что при минимальных неполадках работа застревает, так как нет возможности уточнить, что происходит внутри «черного ящика» — вы словно ведете самолет без приборов, летя наудачу.

6. Нельзя добавлять функции корректировки данных

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

В системах Low-Code для подобных задач могут быть предусмотрены фильтры или переключатели, и обычно этого достаточно. Но когда нет, вам не повезло. Для поставщиков малокодовых сред это тоже непростая ситуация. Некоторые из них экспериментировали с возможностью добавления произвольных фрагментов кода, но это чревато дырами безопасности, если кто-то находит способы злоупотребления. К примеру, из Drupal убрали возможность включения фрагментов кода PHP, чтобы закрыть потенциальную брешь безопасности и улучшить производительность кэширования.

7. Cистемы Low-Code, как правило, неэффективны

Инструменты Low-Code сулят возможность «понимать», чего вы хотите, и волшебным образом исполнять ваши желания. Но цена этого «чтения мыслей» — увесистый стек кода, в котором предусмотрены варианты на все случаи жизни.

Допустим, ваша компания хранит все данные только в CSV-файлах. Но разработчики среды Low-Code должны все предусмотреть и также обеспечить поддержку JSON, YAML, XML версий 1.0 и 1.1 и т. д. Существует масса всевозможных форматов данных, и отдел маркетинга поставщика среды Low-Code будет настаивать на том, чтобы она поддерживала все из них — ведь нужно как можно больше галочек в таблице функциональности.

В результате появляется впечатляющий образец инженерной работы, внушительный, как дредноут, и такой же «маневренный» и «быстрый», как военный корабль времен первой мировой.

Как следствие, созданный продукт работает медленнее и менее эффективно, чем могла бы. Если вы стеснены жесткими сроками и обрабатываемый вашей системой набор данных не слишком велик, неэффективность можно замаскировать, добавив мощностей. Но рано или поздно «счет» за излишки в коде вам будет выставлен в любом случае.

8. Нужны специальные навыки

Многие платформы с открытым кодом разработаны на популярных языках программирования, широко преподаваемых в университетах. Есть немало специалистов, которые способны разобраться в коде стеков, реализованных на Java, JavaScript, Python, PHP и т. д.

Но работе с инструментариями Low-Code студентов не учат, поскольку в теории это и не нужно. Конечно, подобные инструменты нередко тоже написаны на распространенных языках, но проблема не совсем в этом, а в сложности структуры фреймворков Low-Code. Вы платите не только за саму систему — в дальнейшем, если ее нужно будет доработать или расширить, членам вашей команды придется потратить дополнительное время на изучение ее устройства.

9. Зависимость

Внедрение платформы Low-Code напоминает попадание в толпу — присоединиться легко, а выбраться непросто. Цена уменьшения объема выполняемой вами работы — зависимость от гигантов, которые подпирают своими плечами ваши системы. Пока гиганты двигаются, вы двигаетесь вместе с ними. А если они останавливаются или падают, вас ждут проблемы.

Внедрение архитектурных стандартов и следование им — не самый простой элемент agile-разработки для руководителей и участников команд. Стандартов, относящихся к практикам и данным, придерживаться непросто, так как agile-группы работают в режиме спринтов длительностью по две-четыре недели, а владельцы продуктов обычно заполняют журнал пожеланий приоритетными функциями. Ведь дополнительное время требуется как на разработку стандартов, так и на то, чтобы продумать технические особенности их внедрения.

Если работать по схеме, при которой после завершения очередного спринта составляются планы только на следующий, на планирование долгосрочной разработки с соблюдением стандартов не остается времени. При этом если задокументированным стандартам трудно следовать или нет возможности с ними сверяться, новых разработчиков будет сложно заставить усвоить рекомендации, касающиеся архитектуры и данных, а это все равно что блуждать группой по лесу без карты и GPS; вы, возможно, набредете на тропу, но не будете знать, лучший ли это путь к «цивилизации».

Какие проблемы данных и архитектуры требуют внимания

Полезным будет разделить стандарты в области данных и архитектуры на две категории.

1. Стандарты архитектуры, например, модели данных, конвейеры данных, базовые технологии микросервисной архитектуры, стандартные конвейеры непрерывной интеграции и доставки программных решений (continuous integration/continuous delivery, CI/CD), проверки концепций для новых технологий. Внедрение таких стандартов требует подготовительной работы.
2. Стандарты для практик, в том числе соглашения об именовании, требования к тестированию, стандарты интерфейсов микросервисов и шаблоны удобства использования (usability) — все это будет служить для участников группы руководством при реализации функций и устранении технического долга. Кроме того, в данную категорию можно включить стандарты процессов, определяющие принципы расширения моделей данных, проверки усовершенствований конвейера CI/CD, составления документации по новым конечным точкам микросервисов и т. д.

Когда стандарт требует инженерной работы, ее лучше оформить в качестве ситуаций (epic), функций и историй (story) в журнале пожеланий и назначить соответствующей группе. Для этой группы другие команды разработки становятся клиентами, соответственно, она должна сформулировать условия приемки своей работы. Владельцем продукта при этом может быть архитектор данных, приложения или решения. Его задача — выпустить компонент, которым легко смогут воспользоваться agile-команды и который будет полезен бизнесу.

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

Agile-разработка требует систематического планирования

Многие agile-группы проводят совещания по планированию в начале каждого спринта. В ходе таких совещаний обсуждаются и выбираются для реализации пользовательские истории.

Этот подход эффективен, когда приоритет группы — мелкие доработки существующих приложений. Но если речь идет о новой функциональности, которую нужно создавать в соответствии со стандартами в области данных и архитектуры, оперативного планирования недостаточно. Краткого совещания непосредственно перед началом спринта просто не хватит, чтобы обсудить пользовательские истории и согласовать их реализацию в соответствии со стандартами.

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

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

Разработка эталонных архитектур и моделей данных

Один из элементов координации работы agile-групп состоит в разработке эталонных архитектур и моделей данных, отражающих текущее состояние проекта, состояние в ближайшем будущем и долгосрочные цели. Такие схемы будут служить «дорожной картой» для разработчиков, помогающей обеспечивать оптимальное соответствие реализации стандартам архитектуры и данных.

Эталонная архитектура представляет собой схему с цветовой маркировкой и символами, при помощи которых изображаются текущее и будущие состояния системы. Схему следует уместить на одной странице, определив набор связанных компонентов и изобразив все сервисы одного или более приложений.

Эталонная модель данных может состоять из нескольких схем в зависимости от особенностей использования данных в организации. Обычно эталонная модель описывается следующими схемами:

— концептуальная модель данных, изображающая бизнес-объекты, связи и основные транзакции;

— аналитическая модель, отражающую централизованное размещение данных в озерах или хранилищах и их использование для аналитики, экспериментов с искусственным интеллектом и визуализаций;

— модель интеграции данных, на которой показаны источники данных, операции преобразования и базы данных;

— сервисная модель, показывающая, каким образом микросервисы и другие компоненты соединяются с базами данных.

Такие схемы служат разработчикам в качестве отправной точки при освоении стандартов и планировании на будущее. Архитектору следует дополнить их вспомогательными сведениями — документацией по API, словарями данных и перечнем профильных специалистов по каждому компоненту архитектуры и модели данных.

Составьте согласованные со стандартами условия приемки нового кода

Пользовательские истории должны описывать суть требований и причину их появления, а также содержать пояснение о том, кому конкретно нужна их реализация. В идеале документировать принципы реализации истории должен не владелец продукта, а архитекторы, разработчики и инженеры по тестированию. При этом группы разработки должны нести ответственность за выпуск функциональности и соответствие реализации стандартам в области архитектуры, данных, безопасности, DevOps и другим.

При этом только документирования стандартов и эталонных архитектур недостаточно. Когда команды разработки стеснены обязательствами быстрого написания кода и выпуска очередных релизов, доработка стандартов обычно не в приоритете. Архитекторы должны брать на себя ответственность за анализ пользовательских историй и организацию собраний с членами команд для обмена знаниями, а также за согласование реализаций с необходимыми стандартами путем дополнения историй условиями приемки.

При этом и условия приемки, и стандарты должны обсуждаться руководителями разработки с членами группы — это поможет им придерживаться в работе оптимальных методов и обеспечивать долгосрочное соответствие реализаций стандартам.

В организациях большого размера придется рассмотреть и другие принципы соблюдения стандартов в области данных и архитектуры. Но в любом случае, основные практики, которые помогут группам разработки выпускать новые функции, отвечающие единой архитектуре, — это подготовка стандартов, планирование за несколько итераций до спринта, составление условий приемки с опорой на архитектурные особенности и распределение ответственности.