[TOC]

Работа с продуктом значительно осожняется возможностями которые он предоставляет и отсутствием накладываемых ограничений. Любой разработчик с абсолютно любой квалификацией может вносить изменения в абсолютно любые части продукта (не всегда без плачевных последствий).

Чтобы не было мучительно больно при обслуживании коробки Битрикс24 следует осознать несколько простых правил, о которых мы поговорим далее.

Нельзя править на “боевом” сайте, все что не касается контента.

Любое изменение в не контентной области необходимо проводить на копии сайта и переносить автоматическими средствами на боевую версию. Да, при работе с Битрикс24 следует иметь как минимум 2 независимых версии: “боевую” для использования и “тестовую” для разработки/тестирования. В этом очень поможет параметр Установка для разработки. Для всех не контентных частей следует использовать систему контроля версий.

Вы должны знать что вы делаете

Перед тем как бросаться писать код необходимо подумать. Думать вообще полезно, но при работе с продуктом официальная документация по которому отстутствует и нет гарантии обратной совместимости на уровне кода думать нужно не только по тем сценариям что уже появились, но и то что еще может появиться.

Начните с формализации требований: опишите запрос клиента в терминологии Битрикс24. Возможно это уже существует в продукте и можно использовать готовые инструменты.

Потом найдите все используемые места использования данного механизма. Например для изменения лида это может быть:

  • Изменение в карточке лида
  • Изменение из списка лидов
  • Изменение из канбана
  • REST-приложения
  • Прямые и косвенные обработчики событий (например обновление лида на событии обновления лида)
  • Изменения из бизнес-процессов

Подумайте как ваша новая механика будет затрагивать существующие стандартные механики, как она будет влиять на внешние приложения (которые потом клиент поставит сам), как она будет работать в связке с уже написанными механиками.

Хорошо подумайте и ответьте на вопрос “Как еще можно добиться желаемого результата?”. Здесь как и везде действует правило Паретто: 20% работы приносит 80% пользы. Старайтесь делать меньше и получать больше.

Если вы не знаете как это работает, старайтесь не изменять стандартное поведение системы. Лучше потратить чуть больше времени на разработку своего, чем изменять имеющиеся.

Какими способами изменять

Если изменение можно рационально сделать через стандартные механизмы, то лучше использовать их. Например: если нужно генерировать pdf документ, то лучше будет использовать штатный модуль, чем писать свой или использовать модуль товарища.

Если стандартных механизмов нехватает, лучше легитимно расширить возможности системы. Например: сделать свой тип пользовательского поля, свое действие бизнес-процесса, написать обработчик события, подписаться на JS события.

Если нужно изменить существующую механику, лучше использовать “мягкое” изменение. Добавлять скрывать блоки на JS/CSS, использовать result_modifier.php и component_epilog.php.

Если стандартная механика сильно отличается необходимой, старайтесь не трогать стандартное и разработать рядом свою аналогичную механику, скрыв через js/css стандартную.

Если “мягкий” вариант не подходит и есть острая необходимость специальных точечных изменений, то нужно выносить компонент в local-папку и изменять его. Старайтесь не прибегать к этому методу и не злоупотреблять.

Что не нужно делать

Никогда:

  1. Изменять что-либо в /bitrix/components/bitrix/*
  2. Изменять что-либо в /bitrix/modules/*
  3. Изменять что-либо в /bitrix/php_interface/*
  4. Изменять что-либо в /bitrix/js/*
  5. Изменять что-либо в /bitrix/css/*
  6. Выполнять ручную переиндексацию правил ЧПУ (urlrewrite.php)
  7. Работать в визуальном редакторе для правки компонентов Битрикс24
  8. Использовать INSERT/UPDATE/DELETE запросы в базе данных

Часто:

  1. Выполнять работы без ssh доступа к серверу и актуального бекапа
  2. Использовать SQL-запросы (SELECT)

Как правильно

В настоящее время наилучшими практиками является:

  • Использование системы контроля версий
  • Работа исключительно с публичной частью и local-папкой
  • Использование песочницы для разработки
  • Перенос изменений через средства миграции/автоматического переноса
  • Хранение учетных данных в .env файлах и СУБД