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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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