Плагин

Архитектура с плагинами появилась как ответ на противоречие: основная программа должна оставаться стабильной, а пользователям нужны тысячи разных функций. Решение — оставить в ядре «разъёмы». Программа заранее объявляет, в какие моменты и какими способами в неё можно встроиться, а плагин подключается к этим точкам. Так устроены CMS, редакторы кода, графические программы, системы сборки, браузеры (там это чаще называют расширениями).

Как это работает

У любой системы плагинов три составляющие. Первая — способ обнаружения: папка, которую сканирует программа, или реестр в настройках. Вторая — контракт: интерфейс, который плагин должен реализовать, или набор событий, на которые он может подписаться. Третья — жизненный цикл: включение, отключение, удаление, обновление. В WordPress контракт — это хуки, подробнее — в статье «Плагин WordPress». В 1С-Битрикс похожую роль играют модули с обработчиками событий.

Пример: плагин для jQuery

Библиотека jQuery даёт простую точку расширения — объект $.fn. Всё, что туда добавлено, становится методом любой выборки элементов:

$.fn.highlight = function ( color ) {
  return this.css( 'background-color', color || '#fff3a0' );
};

$( '.price-new' ).highlight();

Ядро jQuery при этом не меняется, а новый метод работает так же, как встроенные.

Плюсы и цена

• Ядро обновляется отдельно от расширений, а лишние функции не грузятся, пока не установлены.
• Сторонние разработчики могут развивать экосистему без доступа к основному коду.
• Но каждый плагин — чужой код с теми же правами, что и программа. Уязвимость в нём — уязвимость всего сайта.
• Плагины конфликтуют между собой и с новыми версиями ядра. Чем их больше, тем выше шанс, что очередное обновление что-то сломает.

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