Пришло время включиться в обсуждение непосредственно разработчикам CS-Cart :)
В CS-Cart у нас фокус на клиентов и фидбек от них. Мы смотрим, какие есть потребности у бизнеса, без понимания целей не делаем вообще ничего. Каждый бизнес специфичен, но мы в CMS реализуем самые распространенные сценарии; пилить побольше плюшечек и настроечек мы не хотим, мы делаем цельный массовый продукт. Интеграция продукта под конкретный бизнес преследует другие цели, поэтому и модули под конкретные сценарие платные. Для бизнеса цена «скрепки» не так важна, если скрепка — часть механизма с многотысячным месячным оборотом.
В статье упоминается плохая документация. Документацию мы пишем в первую очередь для клиентов, чтобы им было легко разобраться в продукте, а потом уже для разработчиков. Помимо текстовой документации у нас есть видео-уроки, а в прошлом годы мы начали проводить вебинары, чтобы помочь новым разработчикам освоить CS-Cart.
Структура CMS и модулей в ней выглядит запутанной на первый взгляд, но она осваивается один раз и потом используется. Видел и положительные отзывы, и критику, и там, и там рациональные зерна есть. It just works, в текущей мажорной версии продукта менять ее мы не планируем. Если что-то работает не так, как описано в документации, можно запостить баг-репорт: forum.cs-cart.ru/c/bug-tracker. Если ошибка есть, то мы ее починим, а если нет — поможем разобраться с проблемой.
Активным разработчикам мы даем доступ в репозиторий CS-Cart, там они в рамках pull request'ов могут добавлять хуки для разработки модулей, чинить специфичные ошибки, с которыми не сталкивались клиенты, предлагать изменения в архитектуре.
Как верно замечают другие комментаторы, CMS разрабатывается с 2005-го года. За это время были и мажорные изменения, и минорные — и структура платформы менялась, и фокус в разработке новой функциональности в сторону ООП смещался. Некоторый код живет еще с 2005-го года, просто потому что он работает. Отчасти из-за этого в платформе есть узкие места по производительности, мы о них в курсе, но взять и переписать все не всегда можем. За 16 лет под платформу написано много модулей, которые работают с определенной структурой данных, архитектурой и API CMS. Рефакторинг по производительности выльется в потерю обратной совместимости и создаст огромную нагрузку на разработчиков, а клиентов может оставить без рабочих магазинов на неопределенный срок. Customer is king, потому на такой риск мы не идем. Когда есть возможность повысить производительность и сохранить совместимость, мы это делаем, например, в декабре 2020-го года были улучшения по фильтрам и странице товара.
Вообще производительность — вопрос сложный; вижу, что в статье фигурирует «зоопарк модулей». Без профилирования и выяснения конкретных мест, где и какие запросы тормозят (и запросы ли), я бы говорить ничего не стал. При чем тут MyISAM и связывание данных в нем, я не совсем понял. 50,000 — отнюдь не аномальная номенклатура, CS-Cart справляется с ней, а клиенты, которые инвестируют в хостинг с настройкой под себя, живут и с большими каталогами — видел магазины с 250,000 и более товаров. Повторюсь — каждый случай проседания по производительности нужно смотреть в отдельном магазине с его окружением, модулями, данными в БД и так далее.
Так как же и производительность улучшить, и архитектуру поменять? У нас уже есть ряд клиентов и партнеров, которым важна производительность и простота интеграции CS-Cart с другими бизнес-системами, поэтому с этого года мы разрабатываем следующую мажорную версию CMS. Подход у нее принципиально другой: мы фокусируемся на производительности, масштабируемости и взаимодействии бэкенда и фронтенда через API. Чтобы не изобретать велосипедов, используем Laravel и ReactJS. Если кому интересно приложить руку к созданию CS-Cart V, мы ищем разработчиков с большим опытом разработки модульных систем и пониманием того, как жить с большими нагрузками: www.cs-cart.ru/php-architect-laravel-expert.html
А скриншот на события 20-дневной давности ссылается.
В CS-Cart у нас фокус на клиентов и фидбек от них. Мы смотрим, какие есть потребности у бизнеса, без понимания целей не делаем вообще ничего. Каждый бизнес специфичен, но мы в CMS реализуем самые распространенные сценарии; пилить побольше плюшечек и настроечек мы не хотим, мы делаем цельный массовый продукт. Интеграция продукта под конкретный бизнес преследует другие цели, поэтому и модули под конкретные сценарие платные. Для бизнеса цена «скрепки» не так важна, если скрепка — часть механизма с многотысячным месячным оборотом.
В статье упоминается плохая документация. Документацию мы пишем в первую очередь для клиентов, чтобы им было легко разобраться в продукте, а потом уже для разработчиков. Помимо текстовой документации у нас есть видео-уроки, а в прошлом годы мы начали проводить вебинары, чтобы помочь новым разработчикам освоить CS-Cart.
Структура CMS и модулей в ней выглядит запутанной на первый взгляд, но она осваивается один раз и потом используется. Видел и положительные отзывы, и критику, и там, и там рациональные зерна есть. It just works, в текущей мажорной версии продукта менять ее мы не планируем. Если что-то работает не так, как описано в документации, можно запостить баг-репорт: forum.cs-cart.ru/c/bug-tracker. Если ошибка есть, то мы ее починим, а если нет — поможем разобраться с проблемой.
Активным разработчикам мы даем доступ в репозиторий CS-Cart, там они в рамках pull request'ов могут добавлять хуки для разработки модулей, чинить специфичные ошибки, с которыми не сталкивались клиенты, предлагать изменения в архитектуре.
Как верно замечают другие комментаторы, CMS разрабатывается с 2005-го года. За это время были и мажорные изменения, и минорные — и структура платформы менялась, и фокус в разработке новой функциональности в сторону ООП смещался. Некоторый код живет еще с 2005-го года, просто потому что он работает. Отчасти из-за этого в платформе есть узкие места по производительности, мы о них в курсе, но взять и переписать все не всегда можем. За 16 лет под платформу написано много модулей, которые работают с определенной структурой данных, архитектурой и API CMS. Рефакторинг по производительности выльется в потерю обратной совместимости и создаст огромную нагрузку на разработчиков, а клиентов может оставить без рабочих магазинов на неопределенный срок. Customer is king, потому на такой риск мы не идем. Когда есть возможность повысить производительность и сохранить совместимость, мы это делаем, например, в декабре 2020-го года были улучшения по фильтрам и странице товара.
Вообще производительность — вопрос сложный; вижу, что в статье фигурирует «зоопарк модулей». Без профилирования и выяснения конкретных мест, где и какие запросы тормозят (и запросы ли), я бы говорить ничего не стал. При чем тут MyISAM и связывание данных в нем, я не совсем понял. 50,000 — отнюдь не аномальная номенклатура, CS-Cart справляется с ней, а клиенты, которые инвестируют в хостинг с настройкой под себя, живут и с большими каталогами — видел магазины с 250,000 и более товаров. Повторюсь — каждый случай проседания по производительности нужно смотреть в отдельном магазине с его окружением, модулями, данными в БД и так далее.
Так как же и производительность улучшить, и архитектуру поменять? У нас уже есть ряд клиентов и партнеров, которым важна производительность и простота интеграции CS-Cart с другими бизнес-системами, поэтому с этого года мы разрабатываем следующую мажорную версию CMS. Подход у нее принципиально другой: мы фокусируемся на производительности, масштабируемости и взаимодействии бэкенда и фронтенда через API. Чтобы не изобретать велосипедов, используем Laravel и ReactJS. Если кому интересно приложить руку к созданию CS-Cart V, мы ищем разработчиков с большим опытом разработки модульных систем и пониманием того, как жить с большими нагрузками: www.cs-cart.ru/php-architect-laravel-expert.html