Почти любую задачу на сайте под управлением CMS можно решить двумя способами: купить готовый модуль или заказать доработку. Первый путь выглядит дешевле и быстрее, второй — надёжнее и точнее. На деле оба утверждения верны лишь иногда, а выбор между ними — это выбор между двумя видами риска: зависеть от чужого кода или отвечать за свой.
Разберём критерии, по которым решение принимается спокойно, а не по цене в каталоге.
Насколько задача типовая
Главный вопрос — решает ли модуль именно вашу задачу или только похожую на неё. Приём оплаты, расчёт доставки, выгрузка товаров на торговые площадки, базовые SEO-настройки, импорт прайс-листов — задачи, которые у большинства сайтов выглядят одинаково. Писать их заново обычно незачем: готовое решение уже прошло через чужие ошибки.
Другое дело — логика, которая отличает ваш бизнес от соседнего: собственные правила ценообразования, нестандартная схема скидок, обмен с внутренней учётной системой, особый порядок оформления заказа. Здесь готовый модуль закрывает задачу «почти», и это «почти» потом обходится дороже всего. Ориентир простой: если для работы модуля нужно менять процесс в компании или переписывать сам модуль, это уже не готовое решение.
Что будет после обновления CMS
Модуль живёт не сам по себе, а внутри системы, которая обновляется. Поэтому важно не только то, что он делает, но и то, как он встроен.
- 1С-Битрикс. Обновления ядра перезаписывают файлы в каталоге
/bitrix/, поэтому собственный код размещают в/local/, а поведение системы меняют через обработчики событий и свои шаблоны компонентов. Доработка, сделанная правкой файлов ядра или чужого модуля, исчезнет при первом же обновлении. - OpenCart. Правильный способ вмешаться в работу системы — модификаторы OCMOD и события, а не правка исходных файлов. Отдельная сложность — версии: модуль, написанный под 2.x или 3.x, на 4.x без переделки, как правило, не заработает.
- WordPress. Расширения работают через хуки, изменения оформления выносят в дочернюю тему. Всё, что исправлено прямо в коде плагина или родительской темы, обновление вернёт в исходное состояние.
Для заказной доработки правила те же. Хорошая доработка оформлена как самостоятельный модуль, не трогает ядро и переживает обновления. Плохая — это несколько правок «по месту», о которых через год не вспомнит и сам автор.
Совместимость, поддержка и безопасность
Совместимость
Модуль должен подходить не только к версии CMS, но и к версии PHP, к редакции системы, к вашему шаблону и к остальным установленным расширениям. Конфликты возникают там, где два модуля меняют одно и то же место: корзину, оформление заказа, карточку товара. Чем больше расширений на сайте, тем выше цена каждого следующего.
Поддержка автора
Покупая модуль, вы покупаете не только код, но и готовность автора его развивать. Посмотрите на дату последнего обновления, историю версий, тон ответов на отзывы. Модуль, который не обновлялся несколько лет, однажды перестанет работать с новой версией системы — и превратится либо в причину не обновляться, либо в срочную задачу для программиста. Учтите и условия: у платных решений срок обновлений часто ограничен, а продление стоит денег.
Безопасность
Любой модуль выполняется с правами всего сайта: видит базу, заказы, данные клиентов. Уязвимость в плагине — такой же вход на сайт, как слабый пароль администратора. Поэтому не стоит ставить расширения из случайных источников и тем более «бесплатные версии» платных модулей: во взломанные сборки нередко добавляют посторонний код. Настораживать должны зашифрованные исходники и обращения к сторонним серверам, назначение которых автор не объясняет.
Модуль — это не покупка, а зависимость. Разовый платёж за него почти никогда не бывает последним расходом.
Стоимость владения
Сравнивать нужно не цену модуля с ценой разработки, а расходы за два-три года.
- Готовый модуль: покупка, продление обновлений, установка и настройка, подгонка под шаблон, время на разбор конфликтов и риск остаться без поддержки автора.
- Заказная доработка: разработка, тестирование, документация и последующее сопровождение. Код, который написан для вас, кроме вас никто не обновит.
Часто выигрывает третий вариант: готовый модуль для типовой части и тонкая доработка поверх него — через события и хуки, без правки чужого кода. Модуль продолжает получать обновления, а ваша логика лежит отдельно. Собственные модули мы публикуем в магазине модулей по мере выхода, о заказных доработках рассказано на странице модулей и расширений для CMS.
И ещё одно соображение. Если доработок накопилось столько, что платформа под ними едва угадывается, вопрос, возможно, уже не в модуле. Об этом — в статье о том, на чём делать интернет-магазин.
Чек-лист: как проверить модуль перед покупкой
- Версии. Модуль заявлен совместимым с вашей версией CMS, версией PHP и редакцией системы.
- Обновления. Последняя версия вышла недавно, история изменений ведётся, автор отвечает на вопросы.
- Отзывы. Читайте не оценки, а описания проблем и то, чем они закончились.
- Способ встраивания. Модуль не правит файлы ядра и использует штатные механизмы: события, хуки, модификаторы.
- Код. Исходники открыты и не зашифрованы — иначе вы не сможете ни проверить модуль, ни доработать его.
- Внешние обращения. Понятно, какие данные и куда модуль отправляет.
- Удаление. Модуль убирает за собой таблицы, файлы и настройки, а сайт после этого продолжает работать.
- Условия. Известны срок обновлений, стоимость продления и число сайтов, на которые действует лицензия.
- Проба на копии. Установка — сначала на тестовой копии сайта и только после резервной копии, которую вы умеете развернуть.
Если модуль проходит по всем пунктам — покупайте, это разумная экономия. Если спотыкается на двух-трёх, сравните его цену не с ценой разработки, а с ценой проблем, которые он принесёт с собой.