How to
RedLab
11 часов назад
ADPASS рекомендует материал к прочтению
Falcon Space
Как упростить создание веб-проектов без потери гибкости
В этой статье мы поговорим о компромиссах, на которые мы идем при создании платформы.
Введение
В этой статье мы поговорим о компромиссах, на которые мы идем при создании платформы. Противоречие очень простое.
С одной стороны хочется снизить сложность создания 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.
Лучшее в блогах
Вам понравится
Demis Group
08.09.2024
UXART
04.09.2024
От PSP до велосипеда: Как приложение Могучи меняет воспитание детей | Кейс
![]()
Дети не любят убираться, мыть за собой посуду и делать домашку. И как тогда привить им чувство ответственности? Мы не скажем наверняка, но точно знаем, что Moguchi станет мотиватором для вас и ваших детей. Сегодня про Могучи, как мы спроектировали и задизайнили решение и почему вашему ребенку тоже нужен to-do app.
Веб-интегратор «Компот»
03.09.2024
Новости 
Кейсы 
Интервью и дискуссии 
Маркетинговые исследования 
Просто о сложном 
Проверено ADPASS 
Рекламные кампании 