В этом топике содержатся краткие советы по ИДЕОЛОГИИ разработки. Стараемся сделать советы максимально лаконичными и простыми к пониманию. Если очередной совет вызывает обсуждение, то он «сжимается», а всё обсуждение переносится в отдельный топик.
Хозяйственные советы Если на текущем проекте сбоит штатный функционал, то следует попробовать смоделировать аналогичную ситуацию в демо-лаборатории от 1С-Битрикс. Эта ссылка должна быть всегда под рукой.
Первое правило работы с незнакомым кодом/компонентом/модулем - вывод переменных на экран - часто в них содержится ответ на ваш вопрос.
Я применяю такую функцию:
Код
function ec($str, $die=false)
{
if ($GLOBALS['USER']->GetID()==1)
{
if (is_array($str))
{echo '<pre>';print_r($str);echo '</pre>';}
else
echo $str;
if ($die !== false)
{echo $die;die();}
}
}
ec($arResult); ec($arFilter);
Не забывайте про кеширование. Если компонент кешируется, а вы сделали вывод (вроде бы только для себя), то он попадет в кеш и может показаться другим пользователям.
Если переменная неизвестна, то ее класс можно определить таким образом:
Код
var_dump($APPLICATION):
object(CMain)...
И далее уже ищем в документации по классу CMain. (это курс PHP как бы, но для кучи)
И самое главное - не бояться лезть в код. Это очень сильно добавит вам скилов, и вы намного быстрее въедете в систему. По сравнению с крутяцкими фреймворками код Битрикса написан довольно просто и без выкрутасов.
Примечание Почитать развёрнутое обсуждение о тонкостях отладки под 1С-Битрикс можно в топике «Отладка под Битрикс».
Изменено: Месилов Максим - 05.03.2011 12:33:17(Перенос части сообщений)
В 1С-Битрикс есть производительная система кеширования. Она используется как в стандартных компонентах системы, так может быть применена и при самостоятельной разработке. Основная её задача - снизить время отклика сайта и повысить его устойчивость при нагрузках.
Осторожно относитесь к функциям Битрикса, которые вроде бы удобно использовать в повсеместно (в том числе в итерациях). Их довольно много (функции работы с датой, временем, и т.д.).
Например, CompareDates, сравнивает даты. Помимо сравнения дат, она подарит вам +1 запрос.
Но и не забывайте, что в то же время, такое многообразие функций сделано для обеспечения многосайтовости и многоформатности времени.
Совет только один - включайте голову и думайте что в данном конкретном случае лучше вставить копипастом, а над чем лучше поломать голову.
По поводу CHECK_PERMISSIONS в GetList инфоблоков. Я бы не рекомендовал его ставить бездумно, если вы не уверены, что данный инфоблок в дальнейшем может быть закрыт. Если это единственная лента новостей на сайте, то наверняка это не случится.
Почему - потому что это дает +1 join:
Код
case "CHECK_PERMISSIONS":
if($val == "Y" && !$USER->IsAdmin())
{
$BlockMinPerm = (strlen($arFilter["MIN_PERMISSION"])==1 ? $arFilter["MIN_PERMISSION"] : "R");
$arIBlockFilter[] = "(
IBG.GROUP_ID IN (".$USER->GetGroups().")
AND IBG.PERMISSION >= '".$BlockMinPerm."'
AND (IBG.PERMISSION='X' OR B.ACTIVE='Y')
)";
}
break;
В связи с этим, рекомендую отказаться от использования официально устаревших функций публичной части инфоблоков. Например, GetIBlockElementList. Ибо она по умолчанию ставит данный фильтр.
Отказаться от них стоит еще и по другой причине - они возвращают только активные элементы. И вместо того, чтобы (для вывода неактивных элементов) вы в своем компоненте просто комментируете фильтр активности, вам придется переписывать код.
И в завершении блока публичного API строжайшее наставление - проверяйте данные. Если выводите элемент подробно, то проверяйте принадлежность к типу инфоблока, или к инфоблоку, а не просто ID=>$ID.
Иначе это чревато утечкой данных, когда перебирая ID в запросе, можно случайно наткнуться на инфоблок клиентов, ФИО которых забито в NAME, и выведется в title.
Также все методы GetNext() и для инфоблоков GetNextElement() имеют два очень полезных параметра, которыми я предпочитаю пользоваться. Первый параметр, установленный в false, отменит парсинг текстовых полей (замена ссылок, расстановка переносов и т.п.). Если есть желание оптимизировать парсер, то очень рекомендую. А второй параметр, установленный в false, отменит добавление тильда-полей. Этот параметр очень хорошо экономит память на больших выборках, да и вернуть начальное значение в случае необходимости (а она бывает достаточно редко) можно в любой момент битриксовым методом htmlspecialcharsback(). В общем, вторым параметром я рекомендую пользоваться постоянно.
Изменено: Leshchenko Sergey - 11.03.2011 23:42:23(убрал Fetch(), у него нет параметров)
Глобальные для сайта всего сайта вещи не стоит хранить непосредственно в init.php Старайтесь разбить их на классы-функции и разнести по типу-назначению, а в файле init.php оставьте только инклуды ваших файлов.
Всегда минимизируйте запросы, если в цикле идет запрос к элементу ИБ, к примеру, то уже думайте над минимизацией. Да, это займет больше времени, но и вы возьмете больше денег, а вам скажут спасибо.
Нельзя:
Код
foreach($arResult["ORDERS"] as $key => $val)
{
foreach($val["BASKET_ITEMS"] as $vvval)
{
$rsEls = CIBlockElement::GetGetByID();
}
}
Следует:
Код
foreach($arResult["ORDERS"] as $key => $val)
{
foreach($val["BASKET_ITEMS"] as $vvval)
{
$arIDs[] = $vvval["PRODUCT_ID"];
}
}
$rsEls = CIBlockElement::GetList(array(), array("ID" => $arIDs));
....
foreach($arResult["ORDERS"] as $key => $val)
{
foreach($val["BASKET_ITEMS"] as $vvval)
{
//наполняем данные, налаживая соответствие ID-ков
}
}
Фактически, вы сводите порой 10-ки, если не сотни, запросов к одному. Разве это не круто?
Если вы столкнулись с ситуацией когда код выполняется аномально долгое время, а профайлер битрикса не может показать ничего внятного, то не стесняйтесь применять тяжёлую артиллерию в виде профилировщиков кода - xDebug или похожих инструментов.
При работе с инфоблоками удобнее все коды свойств именовать заглавными буквами.
В таком случае вы сможете избежать небольших несостыковок в своей работе
(например значение свойства с кодом foto при работе с компонентами часто доступно через [PROPERTIES][foto][VALUE]? а при использовании GetList вы можете получить PROPERTY_FOTO_VALUE)
Если есть возможность, то ведите разработку с использованием систем контроля версий. Это может быть как проверенная Subversion так и «новые» Git или Mercurial
Если для какого-либо изменения в БД предусмотрен спец.метод, следует использовать именно его, а не более общий метод изменения БД.
Хорошие пример - модуль интернет-магазина и работа с заказом: можно изменить флаг оплаты заказа путем CSaleOrder::Update(), а можно путем CSaleOrder::PayOrder(). Так вот, следует применять именно PayOrder, потому что в нем произойдет вызов соответствующих обработчиков.
Даже если вам надо изменить множество полей (того же заказа) и флаг оплаты, то произведите изменение через Update, а потом вызовете узкоспециализированный метод. Это наглядно применяется в скриптах-обработчиках статусов ПС магазина.
Антон Долганин пишет: Даже если вам надо изменить множество полей (того же заказа) и флаг оплаты, то произведите изменение через Update, а потом вызовете узкоспециализированный метод. Это наглядно применяется в скриптах-обработчиках статусов ПС магазина.
Не соглашусь здесь, пожалуй. Если выполнить сначала апдейт по всем изменяемым полям, включая поле PAYED, то метод PayOrder() выполнен не будет. Поэтому лучше сначала выполнить PayOrder, а затем уже апдейт остальных полей. Собственно, заглянул в пару обработчиков, там везде так и делается.
Я бы сказал, что методами CSaleOrder::PayOrder(), DeliverOrder(), CancelOrder() и StatusOrder() следует пользоваться при выполнении соответствующих операций над заказом (оплата, доставка, отмена, изменение статуса) по той причине, что они являются хелпер-методами. Т.е. выполняют помимо самого апдейта полей заказа еще и ряд сопутствующих задач для своей операции. Например, выполнение проводок в личном счете пользователя, отправку почтовых сообщений, добавление событий в веб-аналитике, вызов других методов и колбэк-функций.
Если вы сопровождаете живой сайт и заказчик просит провести работы по доделке-расширению функционала, то сначала проверьте, а пользуются ли вообще этим блоком.
Как можно проверить: 1 - статистка посещаемости - Внутреняя статистика, Метрика, GA или Ливинтернет. 2 - артефакты внутри Битрикса: результаты веб-форм, заказы, скачивания (в метрике есть нужный отчёт и отлично работает) итд. 3 - карты кликов в метрике. Это действительно удобно.
Если блок мёртвый, то лучше его вообще убрать или переформулировать ТЗ.
Помимо просто порядка, вы еще получите стандартное API для работы с cookie: $APPLICATION->get_cookie('BLABLA'); (сама подставляет префикс из главного модуля)
Если вы автоматизируете бизнес-процессы клиента, то никогда не бросайтесь кодировать пока не будет нарисована схема бизнес-процесса и не будет понимания как вы её будете сопровождать.
Цитата
Пример из жизни — Модератор заявок. Когда его делали, то модуля БП ещё не было. Поэтому собрали на ИБ + развесистый многошаговый мастер.
Процесс сделали однонаправленным т.е: 1. Проклацал мастер, он собрал кучу данных 2. Данные необратимо переколбасили и положили в ИБ (заявка принята) или заявку отклонили. 3. На основании данных в ИБ податель заявки получил по заслугам.
Всё было стройно и красиво пока клиент не решил отклоненные заявки показывать в виде очереди с возможностью повторно пройти мастер.
Как вы понимаете - на основании данных из ИБ мастер не инициализнуть повторно.
Не нужно стесняться задавать вопросы которые вертятся на языке в момент проектирования.
При работе с файлами следует придерживаться функций и класса CFile, а не php-функций fwrite, copy и прочее.
Причин на то две: события (настоящие и будущие), на которые могут быть повешены обработчики, а системными функциями вы пройдете мимо них; счетчик свободного места, выделенного для продукта.
Исключения есть, но использовать их надо с умом - например, если вы помещаете в /upload/tmp/, то его можно удалить и unlink'ом.
При вставке в JS-код ланг-файлов с помощью GetMessage не забывайте слешить кавычки. Даже если в вашей фразе нет кавычек, они могут появиться потом, при переводе.
Чтобы не греть голову, используйте стандартную функцию:
Не забывайте, что управляемый кеш ИБ очищается только при вызове Update. При изменении, например, свойств с помощью SetPropertyValueCode очистки не произойдет. Делаем вручную после изменения:
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».