ildar r. khasanshin

В настройках инфоблока свойство "Режим просмотра разделов и элементов"

Запрос в цикле - ай-яй-яй, как плохо.

А вообще вот прямо для этого решения:

foreach ($arResult['ITEMS'] as $key => $arItem) {
    $arSectionList = array();
    $rsSections = CIBlockElement::GetElementGroups($arItem['ID']);
    while ($arSection = $rsSections->Fetch())
    {
        $arSectionList[] = array(
                'ID' => $arSection['ID'],
                'NAME' => $arSection['NAME'],
            );
        $arResult['ITEMS_BY_GROUP'][$arSection['ID']][] = $key;
    }
    $arItem['SECTION_NAME'] = $arSectionList;
    $arResult['ITEMS'][$key] = $arItem;

}

И на выходе получишь $arResult['ITEMS_BY_GROUP'] где ключами будут ID разделов, а значениями массивы содержащие ключи элементов ITEMS принадлежащих этому разделу.
Но если много элементов то вот это вот: CIBlockElement::GetElementGroups надо выносить за пределы цикла.

Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:

• организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
• Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
• Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
• Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.

Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

• У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
• С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
• Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
• Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.

Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.

Думаю причины популярности Битрикса примерно такие:
1. Бренд
2. Админка
3. Интеграция с 1С
4. Для партнеров скидка на CMS около 50%
5. Достаточно высокая скорость разработки типовых решений без нестандартного функционала одним разработчиком(как и в других CMS).
При этом проблемы разработчиков и сложность создания нестандартных высокопроизводительных решений никого не интересуют.

Из минусов:
1. Сложно сделать то, что не заложено изначально
2. Не все возможности документированы.

Эльдорадо недавно отказались от Битрикс в пользу Hybris — e-commerce на Java. Думаю это о многом говорит.

С точки зрения разработчика у Битрикс хорошая идея, но реализация осталась где то на уровне процедурного подхода. Т.е. многое делается через ассоциативные массивы, хотя классы там были бы более уместны. Например повсеместно встречается массив $arResult хотя было бы приятнее видеть что то вроде $news, $cartItems и т.п.

И конечно главный недостаток Битрикс с точки зрения разработчика это структура базы данных. По умолчанию Битрикс создает не простые таблицы на каждый инфоблок, а сложную структуру , которая ОООЧЕНЬ(1-2 сек) тормозит без кеширования и из которой не очень весело получать данные — никаких news->last(15)->order(DESC) как например в рельсах или в любом обычном active record.
И ещё Битрикс делает около 60 запросов к базе данных на простой страничке с выводом новостей.

Но опять же проблемы разработчиков никого кроме разработчиков не интересуют.

Плюсы Битрикса в данном случае перевешивают минусы для менеджеров и собственников веб-студий.
А для разработчика конечно есть системы лучше.

Это платная CMS и студии получают процент за продажу лицензий.

utf8 без bom
и не оставляем в конце и начале всех скриптов строк пустых.

Эти уровни - абстракция, причем зависящая от компании. Пройдите несколько собеседований и спросите, что думает о вас интервьюер.

Юниор чаще всего - это программист с в основном теоретическими знаниями, либо наоборот только практическими знаниями. Он умеет решать более-менее стандартные задачи. Юниора обязательно надо учить. При получении нового задания он "создает" свое решение.

Мидл - знания уже подкреплены опытом, может (в отличии от юниора) предсказывать последствия тех, или иных решений. Может решать задачи по проектированию модуля, или его части. Получив новое задание - может скомпоновать из уже существующих решений свое и реализовать его.

Синьйор - понимает не только то зачем использовать ту, или иную технологию, а еще и как она работает, например почему при HL форин ключи сожрут io hdd. Может спроектировать и вести средний по размерам проект. Получив новое задание он уже знает как его решить кучей способов, выбор заключается только в правильности интеграции решения.

-----------------

Многое зависит от интервьюера.
У меня был случай, собеседование на php senior developer: поговорили про HL оптимизации, архитектурные предложения для решения неких задач, способы оптимизации и т.д., а потом:
- перейдем к практике: что произойдет в таком коде:
$a = 5 + '5abc' + 'abc5';
- произойдет следующее: я посмотрю blame скрипта и поговорю с автором этой строчки, что бы узнать, что такого хренового в жизни может произойти, что бы он позволил себе это написать.
- ну, тут вопрос на приведение типов
- 10, но вы в своей практике с подобным сталкивались?
- нет
- вот и я не сталкивался...