Создание своего IT продукта. Наш кейс создания платформы (CMS)

Как мы перестали «кодить» и начали управлять бизнесом через SQL. История одной платформы

Если вы когда-нибудь заказывали разработку сайта или сложного веб-сервиса, то знаете: это похоже на лотерею. «Будет готово через месяц» растягивается на полгода, бюджет удваивается, а финальный продукт ломается при первой же нагрузке. Знакомо?

Я сам прошел через это десятки раз. Мы делали проекты «под ключ»: дизайн, верстка, бэкенд, базы данных. Команда росла, сроки — тоже. А счастья не было. Каждый новый заказчик хотел «как в Excel, только в браузере». Но дать ему это было невозможно без переписывания половины кода.

Пока однажды я не понял: проблема не в заказчиках, а в подходе. Мы пытались собрать конструктор «Лего» из тысяч уникальных деталей. А нужно было — просто дать людям SQL.

В этой статье я расскажу, как мы от заказной разработки пришли к собственной платформе, где бизнес-логика пишется на SQL, а не на PHP, C# или Java. И почему это спасло наши проекты (и нервы).

Что вы узнаете:

• Почему типовые CMS и фреймворки — это тупик для сложных проектов.
• Как SQL может заменить половину бэкенд-кода и ускорить разработку в 3-5 раз.
• Реально ли заказчику самому править логику, не вызывая программиста.
• Где посмотреть на работающий демостенд.

Поехали.

---

Заказная разработка: ключевые проблемы в нашей практике

Делая очередной проект по схеме заказной разработки, когда код пишется под проект на неком фреймворке, сталкиваешься с одним и тем же набором проблем.

Долго делается веб-проект

Ожидания заказчика по срокам всегда сильно опережают реальность. Полный стек разработки подразумевает взаимодействие множества людей, возникают микрозадержки, и в итоге все растягивается (даже без учета периода отладки).

В такой схеме программист — самое узкое звено, и именно оно должно работать на полную мощность без ненужных простоев.

Много ошибок при запуске продукта

Разработка с нуля и полный стек подразумевают больше мест, где можно допустить ошибку. Особенно это проявляется при попытках «ускорить» проект. Добавляются новые программисты, решения по требованиям принимаются необдуманно, прямо на ходу.

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

Дорого стоит разработка с нуля

Очень часто заказчик сравнивает заказную разработку с созданием аналогичного продукта на готовой системе — какой-либо CMS. При этом совершенно не учитывается гибкость и возможность дальнейшего развития.

Возрастает человеческий фактор

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

Подробнее проблема качественного кода разобрана в другой статье.

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

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

В нашем случае заказная разработка — не сахар. Возможно, есть команды, которые делают все легко и просто (или поддерживают такое ощущение у клиента).

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

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

Что нужно заказчику. Разработка сайта: с чего начать?

Что хочет от нас заказчик, когда создает свой IT-продукт?

Экономия средств

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

Скорость внедрения новых возможностей

Скорость внедрения идет рука об руку с экономией. Все, что долго внедряется, требует больше бюджета. Умный заказчик инстинктивно понимает: ему не нужен долгий тяжелый проект, в котором можно надолго застрять. Нужно сделать быстро что-то небольшое, внедрить, получить обратную связь (и свернуть проект, если нет результата).

Если делать большой проект год-полтора, надо вложить большую сумму, при этом нет гарантии, что самолетик полетит.

В проекте может быть много гипотез, которые заказчик хочет проверить на пользователях. Важно успевать за ритмом хотелок. Вчера придумали, сегодня описали, завтра внедрили и пользуемся. Так в идеале должны внедряться мелкие доработки.

Совсем идеал — когда заказчик некоторые моменты может по-горячему поправить в системе (конечно, с пониманием и ответственностью за свои действия) — как в Excel, меняя формат таблиц или добавляя новую формулу. Забегая вперед, скажу: мы исходим из того, что заказчик может знать SQL, а значит, может многое изменять в нашей системе.

Кастомизация функционала под требования клиента

Именно по этой причине заказчик выбирает разработку под свои нужды.

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

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

Низкие риски смены поставщика

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

Высокое качество выпускаемого продукта

На этапе запуска заказчик ожидает, что продукт должен быть хорошо протестирован и не содержать ошибок. В теории — да. Но посмотрите на количество патчей Windows (возможно, сравнение некорректное, но суть та же).

Здесь важнее понимать итеративную природу проекта и с пониманием относиться к ошибкам (нашли — исправили — работаем дальше). Разработчик, со своей стороны, должен уменьшать риски возникновения ошибок, не влияя сильно на раздувание бюджета.

Что может предложить разработчик: заказная разработка и готовый IT-продукт

Что может предложить веб-разработчик такому заказчику? По большому счету два варианта:

• Сделать свое типовое готовое решение под конкретную задачу (например, CRM) и продавать его заказчику (если оно удовлетворит его потребности).
• Предложить услуги заказной разработки (продавать часы программистов).

Оба решения имеют достоинства и недостатки.

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

• Продукт создавать дорого (надо сводить концы с концами, пока он не зарабатывает).
• Легко промахнуться мимо рынка (никому не нужно, не решает задачу, проигрывает конкурентам). Разработчики — не маркетологи и часто не понимают проблем конечного пользователя.

Как увязать готовые продукты и заказную разработку

Постепенно пришло понимание: заказная работа по фуллстеку — это сложно масштабируемое, низкорентабельное и неблагодарное дело:

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

В идеале решение виделось таким:

• Создать платформу, которая позволяет делать быстрые изменения по бизнес-логике без обновления кода сайта.
• Сделать пул типовых компонентов, управляемых из SQL. SQL все знают, хранимые процедуры имеют хорошие возможности для описания бизнес-логики.
• Максимально уменьшить стек разработки, чтобы не нужно было изучать 6-7 технологий. Меньше технологий — дешевле поддержка, быстрее обучение, надежнее решение.
• Стандартизировать элементы и подходы. Раньше каждый разработчик делал некоторые элементы по-своему. В идеале система должна выглядеть, как будто ее писал один человек.
• Оставить возможность глубокой кастомизации. Без этого часть покупателей откажутся. Задача — сделать так, чтобы можно было простыми средствами развивать систему под себя.
• Возможность наращивать способности системы от проекта к проекту. Не в плане брать чужие наработки, а в плане шлифовки стандартных компонентов (появление опций, правка багов).
• Меньше людей на проекте. Чем больше разработчиков, тем сложнее координация, больше звонков и совещаний. При увеличении количества качество кода будет падать.

Как появилась идея создать конструктор сайтов. Суть платформы Falcon Space

Управление метриками через SQL

В нашей старой системе учета, сделанной под свои нужды, был модуль «Метрики». Я реализовал подход, когда метрика — это просто хранимая процедура на SQL, которая визуализируется в таблицу. В таблице могут быть вложенные таблицы, которые также создаются через SQL.

Чтобы создавать такие метрики, не нужно менять код приложения или делать обновления PROD-версии. Меняем данные в таблицах, создаем процедуры и проверяем на сайте.

Вложенные метрики https://falconspace.ru/tst-customers

Метрики создаются постепенно (сейчас их более 250, и большинство уже не актуальны). Такой подход экономил кучу времени по сравнению с реализацией через код приложения (например, через LINQ, EF).

Первые компоненты платформы

Параллельно у нас был JS-компонент «Таблица», который позволял быстро собрать таблицу управления некой сущностью (CRUD): настроили JSON, создали метод контроллера, прописали методы в бизнес-логике и DAL — и таблица готова.

Пришла идея повторить SQL-подход на таблицах:

• На странице находится сниппет (разметка компонента).
• JS отправляет запрос за настройками в базу (где в таблице БД хранится информация о настройках таблицы).
• Вызываем нужную хранимую процедуру (которая возвращает данные и дополнительные настройки).
• Визуализируем все на странице.

Именно это легло в основу построения любого компонента конструктора:

• Любой компонент — это сниппет разметки.
• Она трансформируется через вызов хранимых процедур в таблицу, форму, дашборд и т.д.
• Любое действие в системе — это вызов определенной хранимой процедуры, которая генерируется по процедуре-примеру. Каждая процедура имеет жесткий формат вывода, задающий настройки и данные (может быть от 1 до 10 select в одной процедуре).

Пока не было идеи создать полноценную платформу. Было большое желание ускорить создание таблиц и уменьшить количество дурацких ошибок, размазанных по всему стеку. Вместо 3-4 часов тратить на это 30-40 минут.

Эту задачу мы решили, но не остановились и попробовали реализовать другие типовые элементы — статичные страницы и формы.

Ключевой проблемой на пути к созданию платформы была работа форм. Изначально было обходное решение: давать платформу как проект доработки в виде solution на ASP.NET. Но в этом случае мы получали проблемы обновления и все недостатки заказной разработки на полном стеке.

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

Начало работы на платформе

Параллельно мы делали клиентские проекты уже на базе конструктора. Возникали более узкие вопросы: внедрение SignalR, интеграции, кастомизация внешнего вида. Все эти потребности мы решали для проекта заказчика, но это шло и в копилку платформы, расширяя ее возможности.

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

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

Возникающие проблемы и решения

Две ключевые проблемы на этом этапе:

• Как сделать универсальное API при соблюдении подхода платформы.
• Как вызывать такие действия, как отправка SMS или очистка системного кеша из SQL-процедур.

Для API мы сделали две подсистемы: входящие методы API и исходящие запросы к внешним API. Входящие методы — это метод контроллера, принимающий все запросы и по коду действия определяющий хранимую процедуру обработки. C исходящими запросами сложнее: сначала нужно подготовить запрос (одна хранимая процедура — request), затем обработать ответ (другая — response).

Для вызова нестандартных действий я сначала попробовал внедрение сборок в SQL Server, но отказался: это громоздко, сложно переносимо и создает зависимости от внешней среды. В итоге внедрили концепцию «Внешних действий»: платформа ожидает от хранимых процедур дополнительных select, в которых передаются нужные команды (например, отправить SMS).

В целом о подходе конструктора для создания сайтов

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

Также этот подход упростил создание типовых решений. Любое готовое решение — это просто большой кусок SQL-кода (определения таблиц, хранимые процедуры, SQL-функции и данные таблиц).

Мы создали инструменты внутри платформы, упрощающие перенос частей проекта на другую базу в виде SQL-скриптов. Постепенно создаем типовые решения и предлагаем их внедрение в рабочие проекты (например, компонент «Блог» или «База знаний»).

Кое-что пришлось оставить за бортом — например, сильную нетиповую кастомизацию внутренних страниц в плане дизайна. Лендинги могут быть любые: их код просто добавляется целиком и адаптируется в платформе.

Страница https://falconspace.ru/tst-dashboard

Сильно кастомные проекты по внешнему виду — это не про нас. Мы даем гибкость в изменении бизнес-логики и хороший внешний вид по умолчанию, что подходит для 95% проектов. По опыту, проекты с повышенными требованиями к дизайну — самые проблемные и рискованные. За придирками по дизайну часто стоит непонимание процесса создания продукта.

Дизайн важен, но для бизнес-систем я не вижу особой потребности в уникальности. Это скорее личные особенности владельца продукта, которые не идут на пользу. Мы пожертвовали гибкостью в дизайне, но оставили возможность изменений через CSS и JS.

Для полного освоения системы нужно знать две технологии: MS SQL и Bootstrap 4. SQL обеспечивает пластичность бизнес-логики, Bootstrap — гибкость вывода данных. Почему SQL? Разработка своего языка — сложно и непонятно зачем, да и разработчику придется осваивать новое. Большинство программистов знают SQL (хотя бы сталкивались в вузе).

Для алгоритмических задач SQL позволяет делать основные действия: условие, циклы, типовые функции. Используя SQL как основу, мы снижаем риски проблем производительности (конечно, это не панацея, но гораздо лучше Lazy loading и неоптимизированных запросов в LINQ). Компоненты за один вызов хранимой процедуры возвращают несколько select, что уменьшает время на обработку запросов.

Внутри не используется тяжеловесная ORM (Entity Framework, Linq2SQL). Все запросы написаны в SQL и оборачиваются в объекты через Dapper (сравнимо по скорости с DataReader).

Основная разработка ведется через кабинет администратора. Потенциально можно делать горячие правки и через телефон (интерфейс адаптивен под мобильные).

У полноценной IDE есть большие плюсы. Мы постепенно добавляем возможности в наш SQL-редактор (подсветка кода, тестовый запуск хранимых процедур, вывод параметров, полноэкранный режим).

Как внедрение веб-платформы сказалось на проектах

Мы уменьшили количество людей на проектах. Теперь привлекаем не более 2-3 человек (раньше было до 10). Это упрощает контроль, уменьшает ненужные взаимодействия и снижает себестоимость работ.

Существенно увеличилась производительность разработчика — он может сконцентрироваться на бизнес-логике, а не на мелких элементах реализации.

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

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

Чем меньше мест, где разработчик может допустить ошибку, тем быстрее можно ее найти. В нашем случае 90% ошибок — неточности в SQL. Именно там в первую очередь нужно искать проблему. Это влияет на время отладки и сроки.

На проектах одна из задач — выявление неточностей и проработка их на платформенном уровне, чтобы за счет простых средств (CSS-классы или настройки в ХП) решать эти моменты в дальнейшем. Правда, это ведет к распуханию документации.

Дополнительный плюс — более простое обучение новых разработчиков. Если человек знает SQL и что-то слышал о HTML, обучить его работе на платформе не составит труда. Раньше обучение полному стеку могло занять 3-6 месяцев. Сейчас при плотном изучении можно освоить основные возможности за 1-2 недели.

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

Что изменилось с точки зрения заказчика

Меньше нареканий по неточностям и доработкам внешнего вида. Многие моменты делаются по умолчанию, разработчику не нужно думать о мелких деталях вывода таблицы. Его задача — правильно настроить хранимую процедуру.

Стоимость изменений снизилась. Правки делает один человек, нет нужды задействовать сложный цикл обновлений. Если заказчик сам владеет SQL, он может менять некоторые элементы в системе.

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

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

Развитие веб-платформы

Процесс непрерывного улучшения затягивает. Постепенно привыкаешь к внедрениям и шлифовке компонентов. Нам еще многое предстоит сделать: адаптация разработчика в платформе, улучшение документации, проработка системных инструментов (диагностика БД, стресс-тестирование хранимых процедур).

Сейчас мы прорабатываем соединения с другими базами (PostgreSQL, MySQL, Oracle), чтобы можно было обрабатывать данные из «неродных» БД. Также важное направление — работа на Linux (демостенды на Linux уже есть, но требуют проверки всех возможностей). Сейчас система используется на Win-хостинге или VPS с Windows Server.

Самое главное — создание слоя бизнес-модулей: учет кадров, отчет БДДС, генерация счетов и другие компоненты, которые собираются в подсистемы.

Страница https://falconspace.ru/tst-bdds

В новом проекте можно не делать подсистему с нуля, а взять за основу существующий блок (например, отчет БДДС) и адаптировать его под свои нужды. Любой созданный компонент — это пакет SQL, который может быть перенесен в новую БД.

Минусы нашего подхода

У данного решения есть минусы:

• Некоторые возможности лучше делать в бэкенд-языке, а не в SQL (например, вычисление хеша MD5 для кириллицы в SQL Server).
• Есть ограничения по функционалу (в плане интеграции, передачи файлов по API), и иногда приходится искать компромиссы.
• Браузер — не полноценная среда разработки. Многие предпочитают работать в IDE, а не в кабинете на сайте.
• Потенциально могут возникнуть потребности, которые лучше решаются в C#, чем в SQL, по оптимизации CPU. В этом случае их нужно решать через внешний сервис или внедрение в ядро нового внешнего действия.
• Необдуманные правки из личного кабинета могут привести к ошибкам. Это риски — плата за скорость и легкость правок. С другой стороны, эти ошибки можно так же быстро исправить.

Заключение

Мы пока в начале пути. Многое еще предстоит сделать. Но уже можно с уверенностью сказать: у нас есть свой продукт, который мы постепенно шлифуем с каждым новым проектом — заказчика или нашим типовым решением/демо.

Источник: наша страница на vc.ru https://vc.ru/tribuna/173182-na-puti-k-svoemu-produktu-ot-zakaznoy-razrabotki-k-sozdaniyu-svoey-platformy

P.S. Если вы планируете создавать свой продукт в сети, посмотрите наше большое руководство «Как создать IT-продукт».

FAQ: Часто задаваемые вопросы

Что такое Falcon Space?

Это веб-платформа для создания бизнес-приложений, где бизнес-логика управляется через SQL-хранимые процедуры. Позволяет быстро создавать и изменять функционал без переписывания кода.

Какие технологии нужно знать для работы с платформой?

Достаточно знать MS SQL Server (для бизнес-логики) и Bootstrap (для стилизации интерфейса). Это снижает порог входа для разработчиков.

Может ли заказчик сам вносить изменения?

Да, если он знает SQL. Многие изменения можно делать через кабинет администратора, не привлекая программиста.

Сколько стоит разработка на платформе?

Себестоимость работ ниже, чем при классической заказной разработке, так как требуется меньше людей и времени. Платформу можно разместить на недорогом хостинге (от 300 руб./мес.).

Какие есть ограничения?

Есть ограничения по кастомизации дизайна (стандартный вид платформы) и по некоторым интеграциям. Также браузер не заменит полноценную IDE для сложных задач.

Итоговый чек-лист: как использовать подход платформы в вашем проекте

1. Оцените текущие проблемы. Если ваши проекты тормозят из-за долгой разработки и большого числа ошибок — возможно, пора менять подход.
2. Сократите стек технологий. Чем меньше технологий использует команда, тем быстрее обучение и дешевле поддержка.
3. Используйте SQL для бизнес-логики. Хранимые процедуры позволяют быстро вносить изменения без обновления кода.
4. Стандартизируйте компоненты. Создайте пул типовых элементов (таблицы, формы, дашборды), управляемых через SQL.
5. Уменьшите команду. Меньше людей — меньше координации и ниже себестоимость.
6. Шлифуйте платформу с каждым проектом. Каждое исправление ошибки или новая возможность должны улучшать продукт в целом.
7. Дайте заказчику возможность вносить правки. Если клиент знает SQL, он сможет менять логику без вашего участия.
8. Проверьте демостенд. Посмотрите на работу платформы вживую, прежде чем принимать решение.

Насколько полезной была статья?

Создание программного продукта в сети

Как создать IT-продукт. Мануал по созданию программных продуктов

Разработка IT продукта по шагам - что можем предложить

Процесс создания продукта - наш подход к созданию продукта

Готовое IT решение. План создания сайта для на базе платформы Falcon Space

Создание веб-сервиса для малого и среднего бизнеса: от гипотезы до внедрения

Конструктор веб-сервиса Falcon Space: разработка для бизнеса