Одно время в компании, где я работал, остро стоял вопрос с контролем качества разработки у новых сотрудников. Большая загруженность старших разработчиков, не всегда позволяла следить за тем что делают новички. В результате огромное количество времени уходило на исправление ошибок и объяснение того, что можно делать, а что нет.
Для решения проблемы мы написали список правил разработки продуктов на Битрикс, которым должен следовать каждый разработчик в компании.
1. Ядро продукта
Запрещается править код ядра продукта, в силу нескольких причин:
- при обновлении системы внесенные изменения могут затереться;
- при изменении ядра владелец лицензии теряет право на техническую поддержку;
- при изменении ядра разработчиком сайта возможна некорректная работа системы, так как ядро - это сложная система, требующая учета работы всех модулей.
Ядро продукта - файлы, находящиеся в директории /bitrix/modules/ а так же файлы системных компонентов: /bitrix/components/bitrix/.
Если нет никаких других вариантов кроме правок в ядро, то только по предварительному согласованию с менеджером/директором (но таких случаев за мою практику не встречалось).
2. Компоненты
Любой код отвечающий за бизнес-логику приложения должен быть вынесен в собственные компоненты и модули. На страницах должны располагаться только компоненты.
Собственные компоненты должны храниться в папке /local/components/kaycom/.
При работе с компонентами не надо обращаться к базе напрямую. Концепция работы с продуктом предполагает работу с данными через функции API. Структура данных может меняться от версии к версии, а функции сохраняют обратную совместимость. Настоятельно не рекомендуется использовать прямые запросы к БД, т.к. это может нарушить целостность данных и привести к неработоспособности сайта.
Результаты тяжелых вычислений и выборок из БД следует хранить в кеше.
Место хранения кеша определяется настройками в файле .settings.php.
При использовании встроенного кэширования компонентов, обязательно использовать функцию setResultCacheKeys (https://dev.1c-bitrix.ru/api_help/main/reference/cbitrixcomponent/setresultcachekeys.php). В которую необходимо передать массив ключей массива $arResult, которые должны использоваться в некешируемой области, либо пустой массив.
Изменение логики работы шаблонов стандартных компонентов должно происходить в файлах result_modifier.php и component_epilog.php (https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&CHAPTER_ID=04789&LESSON_PATH=3913.4565.4790.4789)
Картинки должны ресайзитья до нужного размера (например методом /CFile::ResizeImageGet https://dev.1c-bitrix.ru/api_help/main/reference/cfile/resizeimageget.php). Если не ограничивать размер изображений, могут быть загружены картинки намного большего размера, чем требуется, что непременно скажется на скорости загрузки страницы. Также необходимо проверять наличие ссылки на картинку - пустых тегов img на странице быть не должно.
3. Модули
Сложную бизнес-логику следует выносить в модули. Но не пишите своих модулей, пока не будете уверены, что аналогичных нет у Битрикса, либо они не отвечают необходимым требованиям.
Собственные модули должны храниться в папке /local/modules/kaycom.{имя_модуля}/.
Модуль - это модель данных и API для доступа к этим данным. Методы классов модуля могут вызываться в компонентах, шаблонах, других модулях.
Модуль может состоять только из файлов с классами и не иметь интерфейса в админке или публичке. Главное, что код будет логически сгруппирован и размещен согласно логике Битрикса. Модули намного легче поддерживать и расширять.
4. Файл init.php
Не захламляйте файл init.php.
Подключайте там только “заголовочные” файлы. Например:
- /local/php_interface/include/events.php - регистрация обработчиков событий,
- /local/php_interface/include/constants.php - константы,
/local/php_interface/include/functions.php - общие функции.
5. Подключение классов
Собственные классы должны храниться в папке /local/php_interface/lib/.
Для подключенных классов использовать функции автозагрузки.
Настоятельно рекомендуется подключать свои классы внутри собственного модуля, либо используя composer.
6. Общие правила и частые ошибки
6.1 Файлы, к которым нельзя обращаться напрямую (они не должны выполняться, будучи вызванными напрямую по адресу в браузере), должны содержать в начале следующий код проверки:
<?if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true)die();?>
К таким файлам относится все, что работает внутри продукта, например: шаблоны сайтов, шаблоны компонента, файлы .parameters.php и .description.php.
6.2 Избегать использования запросов в цикле.
https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&LESSON_ID=3594
6.3 С пониманием использовать методы GetNextElement, GetNext, Fetch для CIBlockResult. А также GetNext и Fetch для CDBResult.
6.4 Стили устанавливать методом \Bitrix\Main\Page\Asset::addCss, скрипты \Bitrix\Main\Page\Asset::addJs .
6.5 Переменные, такие как ID инфоблоков, свойств и значений свойств, используемые в коде, следует выносить в константы. Такие константы описывать в отдельном блоке, например, в отдельном php файле, подключаемом в init.php (/local/php_interface/constants.php). Это позволит легко и просто менять параметры, делает код более читабельным, тем более, если одно значение используется в нескольких местах.
6.6 Должна присутствовать защита от CSRF атак (англ. Сross Site Request Forgery — «межсайтовая подделка запроса»), там где это нужно. Защищаться должны все запросы, изменяющие данные на сервере, а также запросы, возвращающие персональные или иные деликатные данные. Защита осуществляется проверкой идентификатора сессии (функции bitrix_sessid_post(), bitrix_sessid_get(), check_bitrix_sessid()).
7. Оформление кода
Следует следить за порядком в коде с самого начала. Группируйте код. Используйте код повторно, но не копируйте его, а оформляйте его в виде отдельного метода и т. д.
При написании кода стоит придерживаться актуальных стандартов PSR.
Названия переменных, констант, классов и функций - должно быть осмысленным.
Следите за табуляцией во вложенных блоках.
Разделяйте логические блоки кода одной пустой строкой.
8. Копия проекта для разработки
Разработка на боевом сайте неизбежно связана с неработоспособностью сайта во время отладки, ошибками и иногда даже падением сервера. Для того, чтобы этого избежать, разработку необходимо вести на копии проекта. Исключением служат небольшие доработки на проектах на поддержке или проектах, для которых проблематично развернуть тестовую копию.
9. Git
Необходимо использовать систему контроля версий (Git).
