Как упростить создание веб-проектов без потери гибкости
Введение
В этой статье мы поговорим о компромиссах, на которые мы идем при создании платформы. Противоречие очень простое.
С одной стороны хочется снизить сложность создания 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