У решений Аспро и Сотбита есть минус — «под капотом» много лишних функций и шаблонов дизайна, а это утяжеляет код и снижает производительность. По этой же причине изменения, не предусмотренные настройками Аспро, сложнее внедрить, чем в стандартном магазине Битрикс, приходится учитывать много нюансов.
Наше же решение изначально планировалось не как готовый продукт для продажи на маркетплейсе. Готовые компоненты (ГК) — это набор функциональных блоков, которые можно использовать выборочно для сборки нового сайта с нуля, так и установив на уже существующий, функционал которого нуждается в технической поддержке. Например, только Корзину и Чекаут или только Авторизацию/Регистрацию и т.д.
Основная цель использования ГК для разработчика — упростить и ускорить внутреннюю разработку проекта, а для заказчика — снизить стоимость разработки за счет использования готовых функциональных блоков, но при этом не усложнить дальнейшее развитие проекта. На проект также устанавливаются инструменты для разработки: различные сервисы, логгер, фронтенд сборка и т.д.
Это единичный пример комплексного компонента от Битрикс, который каждый пересобирает под свои нужды. Но я так и не понял в чем ваш подход отличается от Битриксового? Вы сами пишите в статье.
Тот же принцип и у битрикса. только они не стали делать вам компоненты под каждую задачу, а сделали конструктор. который вы используете по своему смотрению. У большинства студий, которые работают с битриксом на гите лежат наработки для решения типовых задач, которые просто накатываются на проект (новости, баннеры, отзывы, формы) и т.д.
Да, у нас подход в целом не отличается от Битриксового, но наши компоненты сильно оптимизированы: с учетом своих наработок и опыта, классным UX, что не скажешь о штатных компонентах Битрикса. Также в составе готовых компонентов есть и шаблоны сайта, почтовые события, формы, сниппеты, типовые страницы и прочий функционал, которого нет в штатном, но он пилится из проекта в проект.
В целом это и есть наши наработки, собранные с разных проектов, протестированные и обернутые в модуль. Для экономии ресурсов сделали для них удобный установщик, с помощью которого можно установить как выборочно какие-то функциональные блоки, так и всё решение сразу.
Вы сейчас точно описываете запуск готового решения? Если вы пишите ТЗ, то это уже не готовое решение. Покупая готовое решение вы соглашаетесь на то, что ваш сайт будет "раскрашен" и отконфигурирован через базовые настройки, получит штатную интеграцию с 1С кой, 24-кой и платежной системой.
Никто никого не обязывает строго придерживаться шаблона, всегда имеют место доработки и очень редко, когда штатной интеграцией возможно решить вопрос интеграции с 1С. ТЗ мы пишем всегда, в том числе и для готового решения. Странно не описывать требования к конечному результату. Разница только в том, что в случае готового решения объем ТЗ существенно меньше (описываются в основном доработки, если они нужны в рамках проекта, ну и требования к интеграциям с ERP и сервисами).
Кроме того, Аспро, который вы используете для работы (пара статей на вашем ресурсе посвящена именно переработке фронта на базе Аспро) тоже не самое гибкое решение.
Вы правы, решения на базе Аспро далеко не самые гибкие, поэтому мы разработали свои компоненты, на базе которых возможно более гибко собирать типовые проекты или подключать их к действующим.
Да, это все еще растущий тренд. Только запускают свою электронную коммерцию бренды, производители и дистрибьюторы. Часто преследуя развитие по D2C-модели или запуск нового канала продаж дополнительно к маркетплейсам. Небольшие интернет-магазины с принципом купи-продай съели маркетплейсы.
1. Всё же у нас иная реализация, к тому же штатный чекаут битрикса настолько монолитный, что проще выпиливать и делать свой кастомный. В нашем случае бэк живёт отдельно от фронта и более гибок в случае интеграции новой бизнесовой логики.
2. Например, битриксовая система с отзывами через форумы жутко неудобная, а любые задачи всё-таки стандартный Битрикс закрыть не может (иногда нужные задачи в нём решены, но так плохо/неудобно/негибко, что приходится их перерешивать самостоятельно), казалось бы, зачем что-то кодить если все возможные кейсы уже учтены и решены. К тому же у не опытных разработчиков, которые не знают всех нюансов, не всегда это получается сделать без костылей.
3. Не забываем про сопутствующие работы на написание ТЗ, настройку штатного интерфейса и функционала, доработку функциональных элементов, отрисовку баннеров и иконок, интеграции с 1C, службами доставки и платёжными системами.
Битрикс целился на то, чтобы одним решением покрыть все возможные случаи, даже очень редкие и специфичные (например, продажа товаров с разной кратностью), поэтому в части кода оно большое и запутанное, а разобраться в нём и внести правки (особенно на фронте) зачастую сложно. Мы наоборот облегчили логику, так как целились в типовой сценарий, который по нашему опыту обычно нужен клиентам. И закладывались на то, чтобы кастомные истории при необходимости было легко реализовать через код - "довесить" то, что есть в Битриксе, либо добавить новую логику. К тому же, в компонентах, например, в чекауте используется api-first подход.
Под "готовым решением" имеется ввиду готовые интернет-магазины с маркетплейса Битрикса.
У решений Аспро и Сотбита есть минус — «под капотом» много лишних функций и шаблонов дизайна, а это утяжеляет код и снижает производительность. По этой же причине изменения, не предусмотренные настройками Аспро, сложнее внедрить, чем в стандартном магазине Битрикс, приходится учитывать много нюансов.
Наше же решение изначально планировалось не как готовый продукт для продажи на маркетплейсе. Готовые компоненты (ГК) — это набор функциональных блоков, которые можно использовать выборочно для сборки нового сайта с нуля, так и установив на уже существующий, функционал которого нуждается в технической поддержке. Например, только Корзину и Чекаут или только Авторизацию/Регистрацию и т.д.
Основная цель использования ГК для разработчика — упростить и ускорить внутреннюю разработку проекта, а для заказчика — снизить стоимость разработки за счет использования готовых функциональных блоков, но при этом не усложнить дальнейшее развитие проекта. На проект также устанавливаются инструменты для разработки: различные сервисы, логгер, фронтенд сборка и т.д.
Да, у нас подход в целом не отличается от Битриксового, но наши компоненты сильно оптимизированы: с учетом своих наработок и опыта, классным UX, что не скажешь о штатных компонентах Битрикса. Также в составе готовых компонентов есть и шаблоны сайта, почтовые события, формы, сниппеты, типовые страницы и прочий функционал, которого нет в штатном, но он пилится из проекта в проект.
В целом это и есть наши наработки, собранные с разных проектов, протестированные и обернутые в модуль. Для экономии ресурсов сделали для них удобный установщик, с помощью которого можно установить как выборочно какие-то функциональные блоки, так и всё решение сразу.
Никто никого не обязывает строго придерживаться шаблона, всегда имеют место доработки и очень редко, когда штатной интеграцией возможно решить вопрос интеграции с 1С. ТЗ мы пишем всегда, в том числе и для готового решения. Странно не описывать требования к конечному результату. Разница только в том, что в случае готового решения объем ТЗ существенно меньше (описываются в основном доработки, если они нужны в рамках проекта, ну и требования к интеграциям с ERP и сервисами).
Вы правы, решения на базе Аспро далеко не самые гибкие, поэтому мы разработали свои компоненты, на базе которых возможно более гибко собирать типовые проекты или подключать их к действующим.
Да, это все еще растущий тренд. Только запускают свою электронную коммерцию бренды, производители и дистрибьюторы. Часто преследуя развитие по D2C-модели или запуск нового канала продаж дополнительно к маркетплейсам. Небольшие интернет-магазины с принципом купи-продай съели маркетплейсы.
1. Всё же у нас иная реализация, к тому же штатный чекаут битрикса настолько монолитный, что проще выпиливать и делать свой кастомный. В нашем случае бэк живёт отдельно от фронта и более гибок в случае интеграции новой бизнесовой логики.
2. Например, битриксовая система с отзывами через форумы жутко неудобная, а любые задачи всё-таки стандартный Битрикс закрыть не может (иногда нужные задачи в нём решены, но так плохо/неудобно/негибко, что приходится их перерешивать самостоятельно), казалось бы, зачем что-то кодить если все возможные кейсы уже учтены и решены. К тому же у не опытных разработчиков, которые не знают всех нюансов, не всегда это получается сделать без костылей.
3. Не забываем про сопутствующие работы на написание ТЗ, настройку штатного интерфейса и функционала, доработку функциональных элементов, отрисовку баннеров и иконок, интеграции с 1C, службами доставки и платёжными системами.
Битрикс целился на то, чтобы одним решением покрыть все возможные случаи, даже очень редкие и специфичные (например, продажа товаров с разной кратностью), поэтому в части кода оно большое и запутанное, а разобраться в нём и внести правки (особенно на фронте) зачастую сложно. Мы наоборот облегчили логику, так как целились в типовой сценарий, который по нашему опыту обычно нужен клиентам. И закладывались на то, чтобы кастомные истории при необходимости было легко реализовать через код - "довесить" то, что есть в Битриксе, либо добавить новую логику. К тому же, в компонентах, например, в чекауте используется api-first подход.
Под "готовым решением" имеется ввиду готовые интернет-магазины с маркетплейса Битрикса.
Вот тут много строчек кода https://o2k.ru/blog#!/tfeeds/906498033771/c/Веб-разработка
А эта статья про готовые компоненты, за счёт которых мы увеличиваем скорость разработки.