Введение — Bitrix24: Книга разработчика
#Введение в разработку
Работа с продуктом значительно осложняется возможностями которые он предоставляет и отсутствием накладываемых ограничений. Любой разработчик с абсолютно любой квалификацией может вносить изменения в абсолютно любые части продукта (не всегда без плачевных последствий).
Чтобы не было мучительно больно при обслуживании коробки Битрикс24 следует осознать несколько простых правил, о которых мы поговорим далее.
#Нельзя править на “боевом” сайте, все что не касается контента.
Любое изменение в не контентной области необходимо проводить на копии сайта и переносить автоматическими средствами на боевую версию. Да, при работе с Битрикс24 следует иметь как минимум 2 независимых версии: “боевую” для использования и “тестовую” для разработки/тестирования. В этом очень поможет параметр Установка для разработки. Для всех не контентных частей следует использовать систему контроля версий.
#Вы должны знать что вы делаете
Перед тем как бросаться писать код необходимо подумать. Думать вообще полезно, но при работе с продуктом официальная документация по которому отсутствует и нет гарантии обратной совместимости на уровне кода думать нужно не только по тем сценариям что уже появились, но и то что еще может появиться.
Начните с формализации требований: опишите запрос клиента в терминологии Битрикс24. Возможно это уже существует в продукте и можно использовать готовые инструменты.
Потом найдите все используемые места использования данного механизма. Например, для изменения лида это может быть:
- Изменение в карточке лида
- Изменение из списка лидов
- Изменение из канбана
- REST-приложения
- Прямые и косвенные обработчики событий (например обновление лида на событии обновления лида)
- Изменения из бизнес-процессов
Подумайте как ваша новая механика будет затрагивать существующие стандартные механики, как она будет влиять на внешние приложения (которые потом клиент поставит сам), как она будет работать в связке с уже написанными механиками.
Хорошо подумайте и ответьте на вопрос “Как еще можно добиться желаемого результата?”. Здесь, как и везде действует правило Паретто: 20% работы приносит 80% пользы. Старайтесь делать меньше и получать больше.
Если вы не знаете как это работает, старайтесь не изменять стандартное поведение системы. Лучше потратить чуть больше времени на разработку своего, чем изменять имеющиеся.
#Какими способами изменять
Если изменение можно рационально сделать через стандартные механизмы, то лучше использовать их. Например: если нужно генерировать pdf документ, то лучше будет использовать штатный модуль, чем писать свой или использовать модуль товарища.
Если стандартных механизмов нехватает, лучше легитимно расширить возможности системы. Например: сделать свой тип пользовательского поля, свое действие бизнес-процесса, написать обработчик события, подписаться на JS события.
Если нужно изменить существующую механику, лучше использовать “мягкое” изменение. Добавлять скрывать блоки на JS/CSS, использовать result_modifier.php и component_epilog.php.
Если стандартная механика сильно отличается необходимой, старайтесь не трогать стандартное и разработать рядом свою аналогичную механику, скрыв через js/css стандартную.
Если “мягкий” вариант не подходит и есть острая необходимость специальных точечных изменений, то нужно выносить компонент в local-папку и изменять его. Старайтесь не прибегать к этому методу и не злоупотреблять.
#Что не нужно делать
- Изменять что-либо в /bitrix/components/bitrix/*
- Изменять что-либо в /bitrix/modules/*
- Изменять что-либо в /bitrix/php_interface/*
- Изменять что-либо в /bitrix/js/*
- Изменять что-либо в /bitrix/css/*
- Выполнять ручную переиндексацию правил ЧПУ (urlrewrite.php)
- Работать в визуальном редакторе для правки компонентов Битрикс24
- Использовать INSERT/UPDATE/DELETE запросы в базе данных
- Выполнять работы без ssh доступа к серверу и актуального бекапа
- Использовать SQL-запросы (SELECT)
#Как правильно
В настоящее время наилучшими практиками является:
- Использование системы контроля версий
- Работа исключительно с публичной частью и local-папкой
- Использование песочницы для разработки
- Перенос изменений через средства миграции/автоматического переноса
- Хранение учетных данных в .env файлах и СУБД
