Найпоширеніші міфи про сучасний Low-Code та їх спростування

Вітаю, мене звати Андрій і понад п’ять років ми з командою займаємось кастомною Low-code розробкою різного спрямування. Від автоматизації бізнес-процесів до мобільної та веброзробки.

Під час роботи з пресейлами для замовників в мене з’явилася ідея про написання однієї або й серії статей, які детально розкажуть, що сьогодні собою являє Low-code. І чому Low-code сам по собі — це навіть не технологія, а певний підхід до розробки, який реалізують інструменти.

Наразі на українському ринку спостерігається тенденція спроб використання Low-code для розв’язання точкових завдань або для створення прототипів. Про його використання тільки для прототипів (і про те, чому це не повноцінне використання інструменту) я розповідав у своєму виступі. Можете ознайомитися, якщо цікаво.

У статті ж я буду намагатись показати реальну сьогоднішню ситуацію щодо Low-code розробки, маючи прямий досвід роботи з 8-10 Low-code інструментами для створення комерційних і Enterprise-продуктів.

У цьому пості я ні в якому разі не відкидаю класичну розробку або не стверджую, що Low-code розробка краще за всіма параметрами. Однак я хотів би продемонструвати деякі спостереження, працюючи в цій сфері досить тривалий час.

Чи дійсно Low-code позбавляє необхідності писати код

Якщо підсумувати все, що я скажу нижче — ні, Low-code інструменти не нівелюють необхідність використання мов програмування або певних фреймворків, які можна застосувати до тієї чи іншої галузі. І зараз я розповім, чому це добре. Наразі на ринку існує певна сформована думка щодо актуальності «citizen developer» (людей без технічної кваліфікації, які можуть розробити якісний продукт, використовуючи No/Low-code інструменти).

Думка ця свідчить якраз про те, що будь-яка людина за певного спорядження може розробити програмний продукт. Деякі компанії просто навчають людей використовувати ці інструменти, і вони за певний час без проблем можуть створювати продукти, що відповідають стандартам ринку.

Певні дослідження показують трохи інший погляд на використання Low-code, з якого використання коду по мінімуму вважаю виправданим, наприклад, у сфері QA.

Велика стаття щодо використання цього підходу до тестування Challenges & opportunities in Low-code testing розповідає якраз про domain based citizen developers, які можуть використовувати певні спеціалізовані інструменти Low-code для автоматизації візуального тестування. У тексті наводиться аналіз компонентів тестування п’яти комерційних платформ Low-code, щоб висвітлити переваги цього підходу з точки погляду бізнесу. Я із задоволенням розберу цю тему у майбутніх статтях.

На мою думку, у застосуванні до розробки мобільних чи вебпродуктів продуктів трактування citizen developer і цієї практики (культури, напряму розроблення, можна називати по-різному) є некоректним з кількох причин:

• Розробник — це не людина, яка пише код, це інженер, який вміє розв’язувати поставлену задачу оптимальним способом, а інструмент може різнитися.
• Якщо автоматизація деякого бізнес-процесу з використанням, наприклад, RPA, може бути передана в руки citizen developers, то створення вебпродукту або мобільного застосунку — навряд. І причина тільки в тому, що людині необхідно знати певні стандарти, практики, які на цей момент не застосовуються автоматично Low-code інструментами.

Що це означає? А те, що інструменти розробки зараз автоматизують деякі best practice комерційної класичної розробки, проте точно не покривають всіх нюансів і деталей використання певних технологій всередині продукту. Як і не покривають усіх кастомізацій, які може вимагати замовник.

Наприклад, Low-code інструмент не оптимізує твій запит до БД або не пропише логіку валідації вхідних аргументів до методів. Не опише оптимальну структуру зберігання даних у БД. Інструменти можуть не мати певного функціоналу для реалізації того чи іншого візуального елемента.

Приклад: у розробці одного застосунку, який розробляла моя команда, була потреба в реалізації елемента анімованого еквалайзеру для вхідного звуку (на кшталт візуалізації вхідного звуку у Siri). В такому разі нам потрібно було розробляти кастомний widget на Dart, який використовував би всі можливості мови та її синтаксису (точно не Low-code).

Чому ж те, що Low-code вимагає знання і вміння використання мов програмування — це плюс? Тому що такі інструменти не повинні створювати нову парадигму розробки — вони повинні оптимізувати стару.

Початкові спроби створення популярних і, що важливіше, реально використовуваних Low-code інструментів мали на меті повністю нівелювати необхідність писати код. Та сфокусуватися на маркетингу й бізнес-частині продукту. Чим породили негативну думку технічних фахівців, а також ввели в оману поточних ЛПР щодо того, що таке Low-code.

Той самий обраний підхід створення нової парадигми розробки, що буде доступною людям будь-якого рівня технічної підготовки, призвів до реалізацій доволі посередніх продуктів. Продуктивність і скомпільований код яких залишав, м’яко кажучи, бажати кращого. Адже використовував неоптимальне дублювання коду, його мінімальне перевикористання тощо за списком антипаттернів проєктування.

Через це сформувалася думка «Low-code — для прототипів».

Сучасні ж інструменти Low-code мають на меті не прибрати необхідність коду, а оптимізувати рутину програмістів. Саме так їх і потрібно сприймати.

Інструменти не роблять інструмент за розробника, вони надають швидший спосіб виконати дії, які він виконує на класичних технологіях — реалізація та гнучкість проєктування залишається за спеціалістом.

Для демонстрації гнучкості розробки з використанням Low-code інструментів звернемося до прикладу реалізації застосунку, який розробляє моя команда, — «IdeaEcho». Він записує голос користувача, який надиктовує свою ідею, і за допомогою мовної моделі перетворює голос на текст. А текст — на структуровану ідею, до якої можна повернутися.

Гнучкість розробки з використанням Low-code інструментів

Розглянемо приклад реалізації сторінки запису голосу у візуальному редакторі студії. Вона містить кілька нетривіальних елементів для стандартного Low-code інструменту, як-то curved slider, еквалайзер у вигляді трьох вигнутих ліній, який динамічно реагує на голос.

Саме таких компонентів немає у FlutterFlow, тому необхідно звернутися до написання кастомних віджетів, використовуючи в цьому випадку Dart. До речі, переглянути базу всіх компонентів можна тут.

Інструмент FlutterFlow має стандарти структурування сторінки, які переносяться із стандартів Flutter/Dart.

Наведена вище схема ілюструє дерево віджетів для ExamplePage. Сторінка структурована за допомогою ієрархії віджетів, які визначають її макет і функціональність.

Кожен віджет у цьому дереві відіграє певну роль у побудові користувацького інтерфейсу. Від базових елементів, як-то Text, Image, до структур макета, як-то Rows/Columns, які організовують ці елементи.

Зробимо крок назад і подивимось, які елементи було розроблено, не вдаючись до кастомного коду. А які було створено власноруч за допомогою сторонніх бібліотек.

Для цього я виділив зеленим кольором елементи, які було створено тільки у візуальному редакторі, а помаранчевим — ті, які було створено із використанням кастомного коду:

Студія розробки Flutterflow підтримує всі примітиви Flutter, а також компонентну структуру сторінки. Як приклад на скріншоті нижче демонструю частину структури сторінки, яку ми розглядаємо.

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

На зображені нижче — розгляд reusable-компонента на прикладі RecordControls.

Компонент має анімацію під час інтеракції з ним. Це так само було реалізовано за допомогою вбудованого редактора анімацій, який дає змогу описувати їх як на рівні стандартних властивостей об’єкта, так і на рівні заздалегідь заготовлених пресетів (Fade, Shimmer, Slide тощо).

Кожен компонент надає можливість керування івентами протягом його життєвого циклу, що підтримує стандарти атомарної структури.

Робота з кастомними компонентами (віджетами), функціями, бібліотеками теж представлена всередині студії розробки й підтримує IntelliSense, як і будь-яка класична IDE. Сторонні бібліотеки можуть передаватися через PubSpec. Так само можлива компіляція застосунка й окремого компонента та його розгортання для тестування на емуляторі AndroidStudio або Hardware-пристрої.

Розробка на цьому інструменті прискорює процес, оскільки багато елементів візуального інтерфейсу є стандартними. Їх можна реалізувати, використовуючи тільки графічну обойму редактора, не вдаючись до коду.

Використання цього інструменту конкретно в нашому випадку прискорило процес створення продукту майже вдвічі. Якраз коштом оптимізації швидкості верстки інтерфейсів і внутрішньої логіки програми.

Чи можна написати «поганий код» на цьому інструменті? Звичайно! Однак як і в будь-якій розробці, якщо дотримуватись певних стандартів проєктування — проєкт виходить підтримуваним і розширювальним. А програміст, своєю чергою, більше піклується про структуру програми та її логічність, ніж про код.

Для подальшого спростування думки «Low-code — тільки для прототипів» можемо знову звернутися до деяких публікацій. У сучасній роботі 2022 року розглядається зростаюча роль платформ Low-code у корпоративному середовищі. Демонструється їхня ефективність у розробці критично важливих застосунків, що виходять за рамки простого створення прототипів.

Те саме підтверджує публікація в Carpathian Journal of Electronic and Computer Engineering. У дослідженні показано, як Low-code-інструменти перетворилися із засобів створення прототипів на основоположні компоненти при створенні критично важливих застосунків у галузях фінансів, охорони здоров’я та виробництва. Воно підкреслює перетворювальний вплив платформ Low-code, який дає організаціям змогу ефективно створювати та розгортати складні застосунки, що не виходять з експлуатації після впровадження.

Маючи це на увазі, клієнти можуть отримати більш коректне розуміння про те, що роблять розробники на такого роду проєктах.

На мою думку, цей підхід залишає за нами вибір рівня абстракції та гнучкості продукту, який ми розробляємо. Якщо це прототип — накидай стандартні компоненти й не переживай. Якщо це продукт, який користувачі будуть використовувати, проєктуй систему досконально, не обмежуючись якимись умовностями Low-code-інструменту.

Чи дійсно Low-code прискорює процес розробки

Швидкість розробки з використанням інструментів Low-code залежить від чинників, що стосуються як самих інструментів, так і розробника.

Деякі інструменти використовують певні абстракції над стандартними сутностями з категорії проєктування систем. Мабуть, щоб знизити складність входження в розробку для citizen developers або розробників, які не використовували раніше фреймворки та методології класичної розробки.

Як приклад можна навести те, яким чином деякі інструменти розробки реалізують концепцію візуального програмування. Що саме по собі хоч і є досить абстрактним, та в деяких випадках — зручним інструментом, який приніс нам Low-code.

Реалізації поділяються на такі категорії:

• Односторонній спрямований флоучарт, що бере елементи з BPMN 2.0, відомі кожному.

Простий та популярний у використанні. На відміну від деревоподібного (графоподібного) формату, не перетворює блок логіки на спагеті, бо має напрям логіки процесу, що полегшує процес читання.

• Двонаправлений граф.

Дуже спірний інстурмент, що використовується в небагатьох інструментах. Дозволяє рухати ноди графа (які можуть репрезентувати функції або операції в коді) в будь-яку точку простору, і напрям визначається виключно вибором розробника або конвенціями в команді.

• Контекстуальний конструктор (мені тут згадується Scratch, наприклад😐)

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

• Point-n-click формули для невеликих блоків коду і класичний код для більших елементів логіки.

Блоки коду, в які візуально вбудовуються змінні з обраних контекстів або функції, описані розробником. Змінні та операції з кодом можна визначати як написанням коду, так і point-n-click варіантом.

Такі варіанти написання логіки використовуються найчастіше і мінімально відходять від класичного коду. Тільки трохи спрощують операції з контекстами й областями видимості, з якими працює розробник у кожному блоці коду окремо.

Найчастіше вони використовують можливості написання блоків коду класичним методом, що дає змогу використовувати всі можливості та конструкції мови в стандартному форматі.

Я не буду сперечатися про те, що справді існує велика кількість інструментів, які навпаки ускладнюють життя розробникам. А не спрощують, як заявляють вендори під час продажу. Проте коли коректні інструменти для команди знайдені — можна помітити збільшення швидкості роботи. Як із візуальною частиною продукту, якщо така наявна, так і з частиною бізнес-логіки, умовним відображенням елементів та реактивністю продукту.

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

Звісно, не завжди такі результати можна екстраполювати на всі типи проєктів і логік, однак вони можуть бути на цьому рівні за умови вибору кваліфікованої команди або розвитку відповідної внутрішньої практики.

Чи означає Low-code, що AI зробить мені застосунок

Ні, футуристична концепція про всемогутній AI, який може за текстовим описом згенерувати highload-архітектуру, у цю угоду не входила.

Часто ви можете побачити пости в LinkedIn, які демонструють Low-code-компоненти інструменту, що дають змогу, за прикладом Copilot, написати блок коду або згенерувати віджет. Однак наразі в сучасній Low-code розробці ці методи застосовуються рідко.

Такі інструменти можна використовувати для побудови простого макета або концепту з величезною швидкістю. Звісно, якість реалізації та підтримуваність такої генерації лежить на вендорі рішення розробки.

Наразі технології такого роду не є ключовими в розробці, проте, можливо, в майбутньому матимуть успіх.

Сподіваюсь, мені вдалось раз і на завжди спростувати твердження про те, що «Low-code — це майже свій ручний розробник, який за тебе все зробить». Повірте, такі трактування справді зустрічаються.

Low-code не підтримує стандарти DevOps

Як підтримувати продукти? Досить важливе питання, коли розглядаємо інструменти такого виду для Enterprise-розробки. У великих компаніях снують регламентовані процедури перевірки коду, автоматичного тестування, тестового розгортання та численних шарів тестів й перевірок перед відправленням на реліз певної фічі чи продукту.

Логічне питання, чи підтримує це ваш Low-code. Моя відповідь — так.

Сучасні інструменти найчастіше використовують два підходи, щоб підтримувати стандарти розгортання додатків за стандартами тієї чи іншої компанії:

• Надання точок входу для побудови своїх пайплайнів розгортання і тестування.
• Надання інтеграцій з різними рішеннями на ринку для реалізації логіки автоматичного розгортання і тестування.

Використання методу do it yourself у цьому випадку виправдане, тому ми обираємо перший варіант.

У такому разі програмний продукт, при його розташуванні на cloud-потужностях вендора, надає нам API виконання release, rollback. Проведення тестування відбувається через написання Unit-тестів у самому інструменті Low-code і їх запуск. З використанням API, який надається вендором.

Може бути використана система моніторингу, що надається вендором, або ж підключена ззовні. І, так, існують спеціалізовані інструменти моніторингу спеціально для Low-code інструментів.

Методи вище застосовуються, коли розроблене нами рішення хоститься на закритих обчислювальних потужностях вендора, які використовують публічні cloud-провайдери.

При self-hosting-розгортанні ми природно отримуємо набагато більше гнучкості в налаштуванні тестування інструментів.

Low-code інструменти надають варіант вивантаження коду повністю як у форматі проєкту на певному фреймворку, так і як кластеру K8S, наприклад, коли йдеться про Back-end розробку.

А як же проводитися підтримка Low-code-продуктів? Існує два варіанти:

• використання редактора, який надає вам вендор для редагування проєкту, залишаючись в екосистемі;
• використання класичного коду з підтримкою коду, який було експортовано з інструменту розробки, виходячи з екосистеми вендора. Vendor-lock — це часта практика в Low-code інструментах, і я вважаю це неприпустимим під час розгляду інструменту для великого комерційного розроблення. Тому потрібно уважно вивчати інструменти Low-code перед початком розроблення.

Найчастіше у своїй практиці я бачив використання першого варіанту. Він зручніший, тому часто компанії обирають саме його.

Чи є Low-code-продукт моєю власністю

Можливо, це для багатьох буде неочікуваним питанням. Але дійсно існує велика кількість вендорів, які настільки глибоко використовують vendor-lock, що не лише не дозволяють забирати код із собою, а й мають право власності на кінцеві продукти! Це природно неприпустима для комерційної розробки практика, яка створила для деяких клієнтів негативну конотацію Low-code.

Поспішаю заспокоїти — це прописується в договорі з вендором, що дає змогу на рівні вибору стратегічного партнера обирати саме партнера, а не господаря.

Що можна винести з цієї інформації

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

Low-code інструменти не замінюють класичну розробку, а натомість доповнюють її, дозволяючи розробникам зосередитися на більш складних і творчих аспектах проєктування. Важливо розуміти, що такі інструменти не усувають потребу в знаннях мов програмування та принципів розробки, а скоріше надають ефективні засоби для їх реалізації.

Ідея про «citizen developer», яку наразі пропагандують інфлюєнсери, є до певної міри перебільшеною. Оскільки створення складних продуктів все ще вимагає глибоких технічних знань і досвіду. Водночас використання Low-code-технологій вимагає обережного підходу. Особливо у великих комерційних проєктах, де необхідно забезпечити гнучкість, масштабованість і відповідність стандартам якості.

Маю в планах написати більш аналітичну статтю щодо вибору інструментів, які підпадають під усі критерії, що я вказав. Думаю, буде цікаво.

Дякую за ваш час.