#Введение в разработку

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

Чтобы не было мучительно больно при обслуживании коробки Битрикс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 файлах и СУБД