Перед тем как начать работать в Bitrix Framework, необходимо понять основные правила, следование которым поможет избежать многих и многих ошибок:

• Что важно помнить при работе над сайтом:
  1. Нельзя править на "боевом" сайте. Необходимо вести разработку на копии сайта с использованием режима Установка для разработки Начиная с версии 16.5.7 и старше, в продуктах «1С-Битрикс» можно пометить новую или существующую установку продукта специальным маркером Установка для разработки. Маркер позволяет проводить тестирование, не устанавливая продукт локально.
     
     Подробнее ...
  2. Если в силу каких-то причин приходится править При должном уровне квалификации и обоснованных доводах почему именно так нужно. на живом сайте, то нужно всегда иметь доступ к FTP или SSH, так как административная часть из-за ошибок в коде может оказаться недоступной.
  3. Всегда должен быть наготове свежий бекап.
  4. Для случая, когда доработки значительны, когда работает команда из нескольких человек крайне рекомендуется использовать систему контроля версий Организовать сопровождение проекта с помощью системы контроля версий не сложно, если ограничиваться файлами. Для этого можно использовать, например, Mercurial - кроссплатформенную распределённую систему управления версиями, разработанную для эффективной работы с очень большими репозиториями кода.
     
     Подробнее ... .
• Если вы хотите внести какие-то изменения в работе сайта, то:
  • Сначала формализуйте свои требования на листе бумаги, а не кидайтесь править код.
  • После этого заново просмотрите все случаи использования на сайте модифицируемого вами блока. Убедитесь, что всё логично. Очень часто делают небольшие, казалось бы, изменения, а потом оказывается, что страдает связанный функционал, о котором не подумали или забыли.
  • После того, как вы формализовали потребности в изменениях, посмотрите, какие сущности эти требования затрагивают.
  • Только после этого подумайте, какие средства использовать для достижения своих целей.
• Способы внесения изменений и желательный порядок их применения:
  • сначала попытайтесь сделать это редактированием шаблона самого сайта и файлов CSS;
  • если предыдущее невозможно, то попытайтесь сделать это средствами редактирования страницы сайта;
    Примечание: К этому пункту нужно подходить крайне осторожно. Бездумное добавление кода может привести к тому, что компоненты будут обрамляться кодом, который должен быть в шаблоне компонента, а не на странице. Размещение php-кода на странице грозит проблемами. Если контент-менеджер откроет страницу через визуальный редактор, то легко можно "все сломать":

    • визуальный редактор на этапе разбора и визуализации содержимого страницы может допустить ошибки,
    • контент-менеджер может случайно внести правки "несовместимые с жизнью" в php-код и даже не поймет этого.

  • при невозможности реализации задачи с помощью первых вариантов переходите к редактированию шаблонов компонента и файлов CSS компонента, либо изменяйте вывод данных с помощью файлов result_modifier.php и component_epilog.php
  • используйте обработчики событий, которые позволяют решать очень широкий спектр задач.
  • кастомизация компонента или разработка собственного компонента или модуля - последний из возможных вариантов получения нештатного функционала.
• Не рекомендуется писать код HTML в код PHP для изменения представления данных. В компонентах 2.0 разделены логика и представление. Логика - это сам компонент, представление - это шаблон вывода компонента. Шаблон существенно проще, чем компонент в целом. Нет необходимости изменять логику компонента для изменения особенностей показа его данных. Для одной логики может быть несколько представлений, в том числе зависящих от шаблона текущего сайта. Представление (шаблон вывода) может быть написано на любом шаблонном языке, который можно подключить из PHP. Например, шаблоны могут быть на PHP, Smarty, XSL и т.д. Использование стороннего шаблонизатора должно быть четко обосновано, его использование должно давать какие-то преимущества перед штатными средствами.
• Собственные компоненты и шаблоны - в собственном пространстве имен. Кастомизируя штатные компоненты и шаблоны, разрабатывая собственные, размещайте их в собственном пространстве имен. При обновлении системы все внесенные изменения в пространстве bitrix затираются.
• При работе с компонентами не надо обращаться к базе напрямую. Концепция работы с продуктом предполагает работу с данными через функции API. Структура данных может меняться от версии к версии, а функции сохраняют обратную совместимость. Мы настоятельно не рекомендуем использовать прямые запросы к БД, т.к. это может нарушить целостность данных и привести к неработоспособности сайта. В силу вышесказанного структура таблиц не афишируется.
• Запрещается Напрямую это не запрещено Лицензионным соглашением. Но при изменениях в ядре вы одновременно можете полностью нарушить работу системы и потерять право на техподдержку. То есть изменения станут необратимыми. править код ядра в силу нескольких причин:
  • при обновлении системы внесенные изменения затрутся;
  • при изменении ядра владелец лицензии теряет право на техническую поддержку;
  • при изменении ядра разработчиком сайта возможна некорректная работа системы, так как ядро - сложная система, требующая учета работы всех модулей.
  Ядро продукта - файлы, находящиеся в директории /bitrix/modules/ а так же файлы системных компонентов: /bitrix/components/bitrix/.

  Модификация ядра - это мера, которая возможна только в крайних случаях. Допустимо только разработчиками уровня Senior при полном понимании:
  - зачем это нужно и
  - последствий в виде потери возможности штатного обновления через систему обновлений и отказа вендора от технической поддержки такого сайта.

• Если вы сопровождаете живой сайт и заказчик просит провести работы по доделке-расширению функционала, то сначала проверьте, а пользуются ли вообще этим функционалом. Проверить можно так:
  • Статистика посещаемости - Внутренняя статистика, Яндекс.Метрика, Google Analytics или Liveinternet
  • Артефакты внутри Bitrix Framework: результаты веб-форм, заказы, скачивания (в Яндекс.Метрике есть нужный отчёт и отлично работает) и т.д.
  • Карты кликов в Яндекс.Метрике.
  Если блок мёртвый, то лучше его вообще убрать или переформулировать ТЗ В большинстве случаев это задача не разработки, а проектного отдела, проект менеджеров, руководства, в крайнем случае тим лида, если он контактирует с клиентами.
  Кроме того, зачастую заказчик хочет доделать функционал, вне зависимости от того, пользуются или нет им, он платит за это деньги. А экспертиза обычного разработчика может быть вовсе не достаточна для такой оценки. Возможно клиент планирует дальнейшие шаги, рекламу и т. п. .