tekBlueprint

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

No-Code решения за скобками, так как они более специализированы и рассчитаны на использование в совсем ограниченных областях применения. Универсальные решения на них строить сложно и не всегда целесообразно. Опять же, на практике встречались неудачные примеры с такими попытками.

Введение

Процессы трансформации в компаниях уже давно идут, кто-то заменяет продукты ушедших с рынка компаний, кто-то переводит свои старые решения на новый техстек (B2B, B2C). Здесь появляется развилка – пойти по пути традиционной разработки или использовать low/less-code платформу. Ответ не всегда очевиден, и неправильный выбор может привести к перерасходу бюджета, упущенным срокам или созданию продукта, который невозможно масштабировать. В том числе это очень сильно влияет на архитектуру финального решения.

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

Для понимания, расскажу только про релевантный опыт из прошлого от которого буду отталкиваться:

1. ~ 6 лет, но очень давно, разработка на Delphi. Это был классический инструмент RAD разработки, с очень быстрым циклов релиза. В своё время было очень популярен и много софта на нём написано и до сих пор работает (в основном это desktop-приложения). По-моему, за десятилетия у него так и не появилось аналогов.
2. ~ 7 лет – разработка классических клиент-серверных веб-сервисов. Тут всё примерно одинаково везде: один из UI-фреймворков с готовой библиотекой компонентов или написанной с нуля, бэкенд с нуля или на сервер приложений, СУБД.
3. ~ 1 год – разработка внутренней закрытой платформы, под нужды компании. Здесь смешанный вариант: UI-фреймворк для разработки для внешних разработчиков, UI с серверным рендеренгом под нужды администрирования самой платформы, бэкенд платформы, СУБД.
4. ~ 7 лет – разработка на low/less-code платформе с собственным инструментарием.
5. И еще несколько лет различных проектов с разным техстеком и инструментами разработки (Delphi, PHP / JavaScript / Java / C++, Java ME / Android / Swing / JavaFX, различные UI-фреймворки на JavaScript, UE5 и много ещё всякого разного).

В общем, есть с чем сравнить.

Что такое low/less-code платформы?

Low/less-code платформы — это среды разработки, позволяющие создавать приложения с минимальным написанием кода. Что их обычно отличает от других инструментов подходов:

1. Чаще всего это работа с визуальными конструкторами: редактор пользовательского UI, настройка логики через формы.
2. Наличие готовых компонентов и плагинов для расширения функциональных блоков. Например, плагин для работы с аналитическими панелями, отчётность и так далее.
3. Подключаемые или встроенные механизмы управление бизнес-процессами. Могут быть как кастомные, так и на базе существующих движков BPMS.
4. Некоторые платформы предоставляют конструкторы для модели данных, либо это реализуется традиционными способами разработки в коде.
5. Настройка интеграций с популярными внешними системами через готовые коннекторы. Не всегда есть это есть из коробки.
6. Встроенные механизмы управления пользователями и ограничения доступа (RBAC, ABAC, RLS и т.д.).
7. Кроссплатформенность и адаптивность пользовательского интерфейса. Далеко не всегда полноценная и качественная, но лучше, чем ничего.
8. Возможностью разработки традиционным методом. При этом степень расширяемости может варьироваться от платформы к платформе, в зависимости от открытости её API.

Подобных платформ на рынке довольно много на самом деле. Как для развёртывания on-premise, так и доступных как SaaS.

RAD IDE

Небольшое отступление в эру забытых технологий, там когда-то была очень популярна IDE от Borland под названием Delphi. Которая сейчас принадлежит Embarcadero. Синергия очень быстрого компилятора и удобной IDE с набором готовых компонентов (VCL) позволяло в очень быстрые сроки штамповать приложения практически под любую задачу. У неё был и конкурент в лице Microsoft с MFC на C++, но тогда победил Delphi. Насколько знаю, сейчас Embarcadero поддерживает два основных продукта Delphi и C++Builder – Embarcadero Cross-Platform App Development Software. Суть и предоставляемый функционал у них схож, различаются языком разработки соответственно.

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

1. На тот момент были явные проблемы с отсутствием хорошей поддержки кроссплатформенной разработки. Основной платформой была Windows. Не найдя альтернативы разработка уходила на другие технологии: в QT/wxWidgets, .NET, Swing, Web. Много разного было и уже не помню точно. Borland упустила этот момент и актуальность Delphi сильно снизилась. В качестве бесплатной кроссплатформенной альтернативы был ещё Lazarus, который до сих пор жив и развивается.
2. Неудачные попытки уйти в веб-разработку, их попытки в веб-разработку не взлетели. Сейчас даже не знаю, осталось у них что-то или нет, но эта ниша тоже была утеряна.
3. Вход в мобильную разработку был слишком поздним, а сам процесс затянулся. В итоге уступили место конкурентам, в частности Android.
4. Баги, ухудшение UX, проблемы с обратной совместимостью. Не знаю, это был их внутренний хаос или что-то другое, но новые версии становились всё более тяжёлыми и проблемными. Многие просто не переходили на новую версию, в том числе и я, что тоже негативно влияло на продукт в целом.

Чем цепляли Borland и их инструмент/платформа:

1. Лучшая скорость сборки приложений и удобство отладки. Мне кажется даже сейчас вне конкуренции и подозреваю уже никогда не будет аналогов.
2. Богатая палитра визуальных компонентов под любые фантазии. А также возможность легко писать новые, что и делал под свои проекты. Плюс были очень хорошие библиотеки от сторонних разработчиков. Это очень помогало сократить время на разработку.
3. Скорость выполнения приложений – это нативные приложения, без всяких VM/GC/интерпретаторов и прочего мусора свойственного современному стеку разработки.

Судя по сайту Embarcadero сейчас они предоставляют инструмент для разработки под полноценную кроссплатформу – Windows, Android, iOS, macOS, Linux на Delphi или C++. Но сам давно уже не пользовался, не могу ничего сказать насколько она сейчас хороша или нет.

Что касается долговременной поддержки, то даже спустя 25 лет остаётся довольно большой пласт приложений написанных на Delphi и вполне себе работающих. Где-то пытаются мигрировать с них на новый техстех, не всегда получая достойную замену. Основная проблема – некому поддерживать, отсутствуют разработчики Delphi, мы стареем :)

Если подытожить, то Delphi один из старых, но хороших примеров успешной RAD IDE, да и цельной платформы для разработки на Windows в 90-х и начале 2000-х. Современные аналоги схожи и заимствуют некоторые удачные идеи от Delphi (те же компоненты/плагины), но ушли от desktop-приложений в web-сервисы.

Традиционная разработка

Компании разрабатывающие свои продукты, зачастую, создают внутри себя специализированные фреймворки и платформы с учётом внутренних нужд и стандартов. При этом они сами по себе могут основываться на каких-то готовых фремворках, как для бекенда, так и для фронтенда. Можно сказать, что они создают внутреннюю платформу на которой впоследствии будут разрабатываться свои собственные продукты. Не скажу что это лёгкий путь, подводных камней довольно много. Особенно высоки требования к квалификации и профессиональным знаниям команды, которые будут на первом этапе определять основу. Да и в дальнейшем предстоит долгий пусть эволюционного развития с аккуратным внесением изменений в техстек и архитектуру. Часто такие проекты могут попадать в производственный ад, из которого сложно, но можно выбраться.

Из подобных примеров это п.2 и п.3. Разрабатывались долго с учётом потребности к продукту. Были проблемы роста, но постепенно это корректировалось и эволюционировало. Да, не без споров и конфликтов заинтересованных сторон, что неизбежно. Если рассматривать в целом, то не могу сказать, чтобы были моменты, когда появлялись непреодолимые препятствия и дальше двигаться не получалось. Всегда были варианты куда расти, без жёстких внешних ограничений.

Традиционная разработка оправдана, если:

• Вы создаёте решение с долгосрочной перспективой, где архитектура и масштабируемость, это главный приоритет.
• Требуется сложная интеграция с внутренними системами. Особенно актуально, если протоколы взаимодействия или сами системы проприетарные и доступных коннекторов попросту нет.
• Проект требует разработки уникальных процессов специфичных для вашего бизнеса, сложной обработки данных или машинного обучения.
• Безопасность, соответствие внутренним стандартам ИБ. Шанс получить в готовом виде практически равен нулю.

Ограничения и риски

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

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

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

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

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

Low/less-code

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

1. Максимально быстрый старт, чуть ли не с первого дня. Всё настроено предварительно и готово к работе.
2. Рабочее приложение в горизонте недель/месяца. Быстро реализовал свои идеи, быстро собрал и поставил.
3. Низкий входной порог для разработчиков, DevOps/SRE. Всё готовое, нужно только собрать правильно.

Старт действительно быстрый и всё готово. Но это справедливо только к простым приложениям. То есть это типовая готовность, под некие абстрактные и обобщённые требования. Если проект требует чего-то нестандартного (например сложный UI), то никакого быстрого старта не получится. Необходим этап подготовки, PoC и анализа возможности использования выбранного инструмента. Из опыта п. 1 и п. 4. Всегда были ситуации, когда требовалась или доработка под требования проекта. И очень желательно это было делать на начальном этапе старта проекта, чтобы не оказаться обладателем огромного техдолга на рефакторинг, уже через несколько месяцев разработки. Если говорить о простых проектах одной функции, без каких-либо нестандартных требований, то здесь действительно быстрый и безболезненный старт. Сделали – развернули – забыли.

Быстрая поставка возможна, если всё удачно совпало и не пришлось дорабатывать. Но есть один нюанс, точнее вопрос – “А чьими руками возможно быстро реализовать проект: разработками поставщика или разработчиками заказчика?” Правильный ответ всегда будет – руками разработчика поставщика и конечно же не бесплатно. Да, есть профессиональные команды, которые потратят силы и время, чтобы разобраться и сделать самим, но у вас они должны быть. При попытке реализации силами заказчика окажется, что сначала нужно потратить довольно много времени на изучение предлагаемого инструмента. Повезёт, если у поставщика будут курсы.

С низким порогом входа для разработчиков вопрос в том, что считать низким или высоким порогом. Как ранее сказано, пока вы непритязательны и используете только те возможности, которые идут из коробки, то и проблем практически нет. Но такое бывает не часто. И здесь речь не только про внутренние компоненты инструмента (что-то может попросту отсутствовать). Но и про то, как вписывать проект в необходимую инфраструктуру и SLA (доступность, отказоустойчивость и так далее). У вас не будет всё хорошо и правильно всегда, придётся идти на компромиссы. Например, архитектура и дизайн выбранного инструмента могут просто не позволить вам нормально разворачиваться и масштабироваться в K8S без предварительных танцев с доработками на базовом уровне инструмента.

Ограничения и риски

Советую очень основательно подойти к анализу ваших потребностей и того, что есть в предлагаемом поставщиком решении (GAP-анализ). Проведите внутренний R&D, не опирайтесь на чужие слова и уверения. Не существует платформ, которые закрывают весь возможный функционал. Эти решения направлены на универсальность под широкий круг клиентов, а не эффективность и решение именно ваших потребностей.

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

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

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

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

Что и когда выбрать?

Как сказал ранее, это вопрос спорный. Нужен предварительный этап анализа, желательно с R&D, после которого и принимается взвешенное решение.

Практический чек‑лист перед выбором low/less‑code:

1. Функциональная матрица – сопоставить требования проекта с готовыми компонентами платформы.
2. Оцените ресурсы – необходимо понять какая у вас есть команда и бюджет.
3. Пилотный проект – реализуйте небольшую часть (10 % функций) и измерьте: время разработки, производительность, ограничения.
4. Оценка стоимости (TCO) – сюда необходимо включить не только лицензии, но и затраты на обучение, интеграцию, поддержку.
5. План внедрения – на самом деле довольно важная часть, наличие экспортируемых артефактов (модели данных, бизнес‑правила) и дорожная карта миграции.
6. Проконсультируйтесь с архитектором или техническими специалистами – как не хотелось бы покупать по красивой рекламе, но финальное принятие решения должно быть оставлено за техническими специалистами, которые будут с этим работать.

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

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

Заключение

Выбирая low/less-code инструмент необходимо крайне аккуратно оценивать все риски и свои силы. Последствия неверных решений будут стоить очень дорого, со счётом на многие годы вперёд. Следует учитывать что:

1. Нет и не будет единого решения. Выбор между традиционной разработкой и low/less‑code – это компромисс между скоростью, гибкостью, стоимостью и риском.
2. Тщательная предпроектная аналитика обязательна. R&D, PoC, GAP-анализ позволяют избежать дорогостоящих “переделок”.
3. Риски связанные с поставщиком следует фиксировать в SLA. Условия поддержки, обратной совместимости и миграции должны быть обязательно прописаны в договоре.
4. Всё равно потребуется квалифицированная команда. Даже с low/less‑code платформой нужны специалисты, способные проводить интеграцию, писать кастомный код и поддерживать инфраструктуру.

Практический совет в заключение: Если ваш проект находится в “серой зоне” (нет уверенности в выборе), то обязательно начните с пилотного проекта. Параллельно начните формировать техническое/архитектурное решение на его основе: CI/CD, мониторинг, масштабирование, возможности расширения, стандарты кода. По результатам пилота вы сможете объективно решить, нужна ли вам традиционная разработка или достаточно будет low/less‑code платформы и её расширения.