Просмотров: 91351
Дата последнего изменения: 02.02.2024
Роберт Басыров
Сложность урока:
4 уровень - сложно, требуется сосредоточиться, внимание деталям и точному следованию инструкции.
1
2
3
4
5
Недоступно в лицензиях:
Ограничений нет
Цитатник веб-разработчиков.
Степан Овчинников: Неописуемы безобразия, которые можно увидеть в коде человека, знающего мало, а делающего много.
Перед тем как начать работать в Bitrix Framework, необходимо понять основные правила, следование которым поможет избежать многих и многих ошибок:
Что важно помнить при работе над сайтом:
Нельзя править на "боевом" сайте. Необходимо вести разработку на копии сайта с использованием режима
Установка для разработки
Начиная с версии 16.5.7 и старше, в продуктах «1С-Битрикс» можно пометить новую или существующую установку продукта специальным маркером Установка для разработки. Маркер позволяет проводить тестирование, не устанавливая продукт локально.
Если в силу каких-то причин
приходится править
При должном уровне квалификации и обоснованных доводах почему именно так нужно.
на живом сайте, то нужно всегда иметь доступ к FTP или SSH, так как административная часть из-за ошибок в коде может оказаться недоступной.
Всегда должен быть наготове свежий бекап.
Для случая, когда доработки значительны, когда работает команда из нескольких человек крайне рекомендуется использовать
систему контроля версий
Организовать сопровождение проекта с помощью системы контроля версий не сложно, если ограничиваться файлами. Для этого можно использовать, например, Mercurial - кроссплатформенную распределённую систему управления версиями, разработанную для эффективной работы с очень большими репозиториями кода.
Если вы хотите внести какие-то изменения в работе сайта, то:
Сначала формализуйте свои требования на листе бумаги, а не кидайтесь править код.
После этого заново просмотрите все случаи использования на сайте модифицируемого вами блока. Убедитесь, что всё логично. Очень часто делают небольшие, казалось бы, изменения, а потом оказывается, что страдает связанный функционал, о котором не подумали или забыли.
После того, как вы формализовали потребности в изменениях, посмотрите, какие сущности эти требования затрагивают.
Только после этого подумайте, какие средства использовать для достижения своих целей.
Способы внесения изменений и желательный порядок их применения:
если предыдущее невозможно, то попытайтесь сделать это средствами редактирования страницы сайта;
Примечание: К этому пункту нужно подходить крайне осторожно. Бездумное добавление кода может привести к тому, что компоненты будут обрамляться кодом, который должен быть в шаблоне компонента, а не на странице. Размещение php-кода на странице грозит проблемами. Если контент-менеджер откроет страницу через визуальный редактор, то легко можно "все сломать":
визуальный редактор на этапе разбора и визуализации содержимого страницы может допустить ошибки,
контент-менеджер может случайно внести правки "несовместимые с жизнью" в php-код и даже не поймет этого.
Не рекомендуется писать код HTML в код PHP для изменения представления данных. В компонентах 2.0 разделены логика и представление. Логика - это сам компонент, представление - это шаблон вывода компонента. Шаблон существенно проще, чем компонент в целом. Нет необходимости изменять логику компонента для изменения особенностей показа его данных. Для одной логики может быть несколько представлений, в том числе зависящих от шаблона текущего сайта. Представление (шаблон вывода) может быть написано на любом шаблонном языке, который можно подключить из PHP. Например, шаблоны могут быть на PHP, Smarty, XSL и т.д. Использование стороннего шаблонизатора должно быть четко обосновано, его использование должно давать какие-то преимущества перед штатными средствами.
Собственные компоненты и шаблоны - в собственном пространстве имен. Кастомизируя штатные компоненты и шаблоны, разрабатывая собственные, размещайте их в собственном пространстве имен. При обновлении системы все внесенные изменения в пространстве bitrix затираются.
При работе с компонентами не надо обращаться к базе напрямую. Концепция работы с продуктом предполагает работу с данными через функции API. Структура данных может меняться от версии к версии, а функции сохраняют обратную совместимость. Мы настоятельно не рекомендуем использовать прямые запросы к БД, т.к. это может нарушить целостность данных и привести к неработоспособности сайта. В силу вышесказанного структура таблиц не афишируется.
Запрещается
Напрямую это не запрещено Лицензионным соглашением. Но при изменениях в ядре вы одновременно можете полностью нарушить работу системы и потерять право на техподдержку. То есть изменения станут необратимыми.
править код ядра в силу нескольких причин:
при обновлении системы внесенные изменения затрутся;
при изменении ядра владелец лицензии теряет право на техническую поддержку;
при изменении ядра разработчиком сайта возможна некорректная работа системы, так как ядро - сложная система, требующая учета работы всех модулей.
Ядро продукта - файлы, находящиеся в директории /bitrix/modules/ а так же файлы системных компонентов: /bitrix/components/bitrix/.
Модификация ядра - это мера, которая возможна только в крайних случаях. Допустимо только разработчиками уровня Senior при полном понимании:
- зачем это нужно и
- последствий в виде потери возможности штатного обновления через систему обновлений и отказа вендора от технической поддержки такого сайта.
Если вы сопровождаете живой сайт и заказчик просит провести работы по доделке-расширению функционала, то сначала проверьте, а пользуются ли вообще этим функционалом. Проверить можно так:
Артефакты внутри Bitrix Framework: результаты веб-форм, заказы, скачивания (в Яндекс.Метрике есть нужный отчёт и отлично работает) и т.д.
Карты кликов в Яндекс.Метрике.
Если блок мёртвый, то лучше его вообще убрать или
переформулировать ТЗ
В большинстве случаев это задача не разработки, а проектного отдела, проект менеджеров, руководства, в крайнем случае тим лида, если он контактирует с клиентами.
Кроме того, зачастую заказчик хочет доделать функционал, вне зависимости от того, пользуются или нет им, он платит за это деньги. А экспертиза обычного разработчика может быть вовсе не достаточна для такой оценки. Возможно клиент планирует дальнейшие шаги, рекламу и т. п.
.
Внимание! Файлы, к которым нельзя обращаться напрямую (они не должны выполняться, будучи вызванными напрямую по адресу в браузере), должны содержать в начале следующий код проверки: