Айсберг надежд: как фреймворк обещает всё

За последний год в общении с клиентами все чаще возникает один и тот же сценарий: приходит компания с проектом b2b или b2c портала, который неплохо ложиться поверх 1С-Битрикс:Управление сайтом (по тексту БУС), но в процессе общения нас просят, а давайте посчитаем стоимость проекта на коробке БУС и на фреймворке.

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

Даже нельзя сказать, что клиента обманывают или вводят в заблуждение — вполне возможно, что он обратился к команде, которая всю жизнь пишет микросервисные решения на фреймворке. И в целом, это правда. Однако порой ему не раскрывают вторую часть: что будет после. Это, пожалуй, и есть главная проблема — недосказанность и отсутствие у клиента достаточной квалификации, чтобы задать правильные вопросы.

Почему все думают, что решение на фреймворке обязательно будет эффективнее, чем коробочное решение.

Стоит отметить, что разговор обычно происходит в плоскости бэкенда, причем неважно, идет ли речь о Django, Laravel или Ruby on Rails. Дальше диалог развивается по одному из двух сценариев: либо мы начинаем считать дополнительную смету.

Альтернативное решение почти всегда в 1,5 — 2,5 раза дороже, параллельно пытаемся объяснить потенциальные подводные камни такого решения.

В нашей практике речь чаще всего идет о проектах в e-commerce, где функционал практически идентичен. Для несложных проектов — каталог, форма заявки, интеграция с CRM — фреймворк действительно может быть оптимальным выбором. Однако ситуация меняется, когда планируется расширение функционала, уже имеющегося в готовом решении: скидки, товары с характеристиками, интеграции с логистикой, 1С, платежными системами.

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

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

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

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

Если же требуемая логика существенно отличается от коробочной более чем на 30% — выбор очевиден: необходим индивидуальный подход с разработкой на фреймворке.

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

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

#cms #framework #битрикс #bitrix