Как упростить создание веб-проектов без потери гибкости

Введение

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

С одной стороны хочется снизить сложность создания IT системы за счет подхода drag n drop (визуальное проектирование, не нужны знания SQL и т.д.).
С другой стороны - нужна высокая степень гибкости. Если система не гибкая, то рано или поздно она начнет тормозить развитие бизнеса.

Я рассмотрю подробнее это противоречие и обозначу свое видение, как мы решаем этот вопрос в рамках платформы Falcon Space. '

Очень хочется снизить сложность создания IT системы

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

Снижение сложности до уровня настроек - очень заманчивая идея.
Тут очень много плюсов:

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

Минусов такого подхода всего 3:

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

В системе нужна высокая степень гибкости

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

No-code платформы никогда не дадут такой гибкости в полной мере. В них есть много чего, но не всегда этого "много чего" хватает для удовлетворения конкретных бизнес-потребностей. На мой взгляд, нельзя ограничивать систему в плане гибкости (образно, обрезать крылья) только из-за того, что кто-то хочет сэкономить на писании кода (в нашем случае SQL).

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

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

Как мы разрешаем это противоречие для себя?

Периодически мы возвращаемся к вопросу полного создания системы через UI (уж больно это заманчивая идея).

Но основное решение, утвержденное уже давно таково:

Гибкость - ключевая ценность. Всегда должна быть возможность подлезть со своим SQL или JS кодом для обеспечения требуемого уровня гибкости.
Язык SQL - ключевой язык настройки. Изучить SQL можно довольно быстро (за 1-2 недели вполне можно базово освоить на практике). SQL позволяет все делать гибко. Настройки в итоге задаются не жестко (как в UI), а через SQL SELECT.
Осознаем, что большинство людей, заинтересованных в таких системах, не знает SQL. Но также стоит признать, что на практике клиент мало что может или хочет делать руками. Проще сформулировать свое видение, а разработчики это внедряют.
Если бы все-все настройки надо было учесть в UI - это получится панель управления самолетом в кучей кнопок, настроек, что может напугать даже матерого пользователя.
В этом плане типовые SQL процедуры будут выглядят гибче и лаконичнее.
Автогенерация кода - это хорошо для первичной настройки с последующей доводкой по коду под нужную бизнес-логику. Это уменьшает рутину у разработчика, ускоряет его работу, но при этом мы не теряем в гибкости.

В каком случае мы можем полностью перейти на UI подход?

Для этого необходимо разрешить следующие вопросы:

Как не потерять гибкость при таком подходе?
Как сделать так, чтобы сам клиент не ломал систему (ведь теперь он мог бы все менять в системе сам)?
Сложность UI будет в разы сложнее (будет очень много настроек вместо указания их в процедурах в выходных SELECT).

Конечно, есть системы с no-code подходом, но вероятно они сильно ограничены в плане гибкости.

Мы же стараемся балансировать в треугольнике Гибкость - Скорость поставки наработок - Стоимость.

Если мы включаем полное UI управление, мы сразу теряем сильно в гибкости. Если мы подключаем создание fullstack плагинов к платформе (полноценная заказная разработка) - мы будет сильно терять в скорости поставки и стоимости (просто будет в разы выше).

Поэтому мы останавливаемся на своей волне - вся бизнес-логика и большинство настроек на SQL + стилизация через Bootstrap.

Источник: https://falconspace.ru/blog/kak-uprostit-sozdanie-veb-proektov-bez-poteri-gibkosti