Монитор качества — повышаем удовольствие от разработки

    Коллеги, добрый день!

    Сегодня поговорим о причинах, побуждающих создавать и внедрять методики и инструменты обеспечения качества, заглянем в историю проблемы, осветим известные риски и постараемся «устаканить» в сознании выигрышную стратегию обеспечения достаточного качества веб-решения. В заключении я расскажу о новом инструменте в 11 версии платформы Битрикс — «Мониторе качества».

    Идеальный мир — Водопад



    Да, да. Существует методика обеспечения высокого качества веб-проекта, при соблюдении которой он не будет глючить, а Клиенты не будут атаковать вас сообщениями об ошибках на форумах и твиттере.

    Для этого нужно всего лишь:

    1. Найти программиста(ов), сертифицированного для разработки на языке PHP, с опытом работы от 5 лет и большим портфолио успешных проектов.
    2. Найти верстальщика(ов), в тонкостях разбирающегося в особенностях HTML/CSS во всех популярных браузерах последних версий, висящего с утра до обеда на профессиональных форумах (пишу, а в глазах появляются слезы :-) ). Но этого не достаточно, т.к. верстальщик должен уметь программировать для javascript (и знать диалекты этого языка для всех популярных браузеров), т.е. быть «по совместительству» опытным программистом.
    3. Найти системного администратора(ов), хорошо разбирающегося хоть в одной операционной системе и с опытом работы от 10 лет.
    4. Найти тестировщика, который сумеет организовать систему со 100% покрытием создаваемого кода веб-проекта модульными тестами и функциональными тестами. Этот тестировщик должен будет в тонкостях разбираться в предметной области веб-проекта, знать его лучше Клиента.
    5. И, конечно же, найти Клиента, который а) знает в тонкостях что он хочет лучше любого аналитика в данной предметной области, б) не меняет свои требования до запуска веб-проекта в эксплуатацию.
    6. Как только команда собрана, вы начинаете проектировать веб-сайт, отрисовываете, верстаете и включаете в ТЗ описание каждой веб-страницы как в админке, так и публичной части, с точностью до пикселя и разными вариантами страницы в зависимости от разрешения экрана Пользователя. В итоге получается иллюстрированное ТЗ страниц, эдак, на 500, написанное примерно за полгода.
    7. Затем нужно оценить каждую страницу в ТЗ, составит подробный план разработки на каждый день, назначить дату ввода веб-проекта в эксплуатацию.
    8. Конечно, перед запуском выделяется время на тщательное тестирование сделанного веб-сайта на соответствие ТЗ и дизайн-макетам, с точностью до пикселя и буквы в ТЗ. Придется тестировать долго, в несколько подходов, нельзя же открывать функционал с ошибками для Клиентов — скорее всего многофазовое тестирование займет месяца 2-3, если не больше.


    И тогда в веб-проекте скорее всего не будет ошибок и система будет запущена в срок! Но сайт, скорее всего, морально устареет, уже не будет нужен Пользователям, а Клиент получит не то, что он хочет, а то, что он написал в ТЗ :-)

    Многие в настоящее время, к сожалению, забывают, что веб-проект является программной системой с жесткой «булевой» логикой прикладной математики и не обладает чувством прекрасного. Эта инженерная конструкция как любая другая конструкция (мост, дом, самолет) — должна, по-хорошему, проектироваться вплоть до винтика, тестироваться до винтика, а любое изменение потребует пересмотра всей проектной документации. И так, обстоятельно и научно, раньше и делали программные системы — Каскадный подход (Водопад).

    Но интуиция подсказывает, что запускать веб-сайт таким способом очень дорого и видимо очень долго. Да и найти высококлассных специалистов в команду — задача не из простых. Хочется найти способ «схалтурить подешевле», не выполнить домашнее задание по математике: как-то же запускают веб-проекты быстро и с достаточным качеством без многотомных ТЗ? :-)

    Разведка боем — Итерационный подход



    Люди осознали, что сесть с Клиентом и не выходя из переговорки спроектировать веб-решение за 2-3 дня — невозможно. И даже запирание системных аналитиков в офисе на неделю — не решит задачу. Пришло понимание, что эффективнее каждый раз обсуждать и делать систему частями, разбирать результаты завершенного этапа и учитывать их при проектировании следующего. Идти вперед небольшими шагами, не заглядывая в будущее дальше, к примеру, 3 месяцев.

    Для многих Клиентов так работать удобнее — видишь результат и корректируешь план. Для разработчиков и тестировщиков это, конечно, серьезно добавляет хлопот:
    1. Не получается поддерживать в актуальном состоянии всю проектную документацию, скриншоты, диаграммы, ТЗ — т.к. через небольшой период времени скорее всего нужно будет вносить изменения. Поэтому идут на «хитрость» — ведут менее формальное описание системы, например в wiki, без отслеживания зависимостей между компонентами, полагаясь на память коллег :-)
    2. Нужно так программировать/верстать, чтобы внесение ожидаемых изменений было простым, мало рискованным процессом. А это значит, что а) нужно знать и грамотно использовать паттерны проектирования (а найти знающих эту область разработчиков — не просто), б) нельзя поддаться искушению и создавать универсальную и расширяющуюся во все места систему, т.к. это серьезно увеличит сроки разработки
    3. Нужно уметь тестировать эту, периодически меняющуюся систему. Знать где и что поменялось, где это проявится. Т.е. повышается нагрузка на тестировщиков — нужно описывать изменения, вносить изменения в модульные и интеграционные тесты и т.п.


    Видим, что, в итерационном подходе с одной стороны стало удобней Клиенту и, возможно, работающему с ним менеджеру проекта, а с другой стороны — повысилась нагрузка на разработчиков и специалистов по качеству, а также возросли требования к их квалификации.



    Можно организовать подобный процесс как более формально (RUP и т.п.), так и менее формально. Все зависит от конкретного веб-проекта. Соответственно, можно использовать специализированный софт, а можно все построить «на коленках» (эксельки, вики, стенки в листиках и т.п.).

    Высший пилотаж… на гране хаоса — Гибкий процесс (Agile)



    В настоящее время — интенсивно набирающий популярность процесс разработки веб-сайтов. Постулируется следующее:
    1. Требования постоянно меняются, т.к. рынок меняется, поэтому писать, а еще страшнее — менять и поддерживать в актуальном состоянии детальное ТЗ — трата времени. Иначе потребуется отдел системной аналитики, отдел дизайна и департамент проектирования архитектуры
    2. Т.к. требования меняются, изменения в проект будут вносится постоянно, поэтому нужно сделать всё, чтобы это не разрушало проект и изменения вносились быстро и дешево.
    3. Клиент или его представитель должен быть постоянно доступен и открыт для общения, отвечать на вопросы команды проекта.
    4. Разработчики и другие участники проекта постоянно общаются и обмениваются информацией, бюрократия сведена к минимуму, люди высокоорганизованны и действуют заодно (не нужно принуждать к труду).
    5. Веб-проект релизится часто, итерациями в 2-3 недели. В тестировании активное участие принимают Посетители сайта.


    Очевидно, чтобы такое «поперло», нужны самоорганизованные люди в команде, профессионалы своего дела и лидер, поддерживающий данную суперкреативную атмосферу от атак деспотирующих, преследующий личные корыстные цели бюрократов и т.п. Иначе, при любом хлопке — все снова разбегутся по офисным столам и начнут бросаться письмами и страдать буквоедством.

    Клиенту, ориентированному на результат, данный процесс очень удобен, т.к. веб-решение можно менять и развивать постоянно, не отставая от конкурентов — иначе Клиент становится заложником ТЗ, как написал год назад, так и сделаем. Если команда сильная с прогнозируемой производительностью, то Клиент постепенно начинает эффективно планировать ближайшие релизы веб-решения.


    С другой стороны, очень резко увеличивается техническая сложность решения, т.к. поддержка постоянно меняющейся системы в состоянии «технического здоровья» (когда ты знаешь, что ее можно уверенно развивать дальше, и стоимость внесения изменений не начнет расти экспоненциально) — задача не для слабонервных и требует высокой квалификации разработчиков.

    Для управления качеством такой системы (нередко без формальной техдокументации) используется арсенал эффективных методик:
    1. Автоматизированные модульные (unit) тесты. Программисты создают код, тестирующий их код.
    2. Функциональные тесты или автоматизированные приемочные тесты — тестируются выполненные фичи и процессы.
    3. Релиз веб-проекта быстро вводится в эксплуатацию. Посетители быстро тестируют решение и оно за короткий срок переходит из beta в адекватное требованиям состояние.
    4. На всех этапах производства используется чеклисты. Суть проста — некогда писать и читать многостраничные руководства, чтобы «выжить», нужно выполнить данные пункты не задавая лишних вопросов. Прямая аналогия с боевым уставом.



    Очевидно, что т.к. такой процесс разработки балансирует на грани «управляемого хаоса», а иначе работать часто не позволяет рынок, значимую роль в обеспечении порядка и предсказуемости принадлежит максимальной автоматизации тестирования, дополняемой контрольными списками (чеклистами). Система должна уметь проверять сама себя и быстро выявлять критичные ошибки — а также мы должны знать что и где нужно быстро проконтролировать (если это сложно автоматизировать) на разных этапах производства: от верстки до эксплуатации под нагрузкой.

    Здоровая эволюция данного процесса обычно протекает по следующему сценарию:
    1. За 2-3 недели проектируется и выпускается новый релиз веб-решения
    2. Анализируется опыт итерации(ий) и вносятся улучшения в чеклисты разных этапов производства
    3. Часть костылей, поставленных в предыдущих итерациях — переписывается
    4. Новые модули системы покрываются сеткой модульных и функциональных тестов


    Со временем, процесс развития веб-проекта стабилизируется, вносить изменения становится «не так страшно» — их ждут, система постоянно обновляется, улучшается, относительно здорова не только снаружи, но и внутри. Наступает фаза «эффективного мира», которую остается блюсти — т.к. любой перекос может сбросить производство либо в хаос либо начнется бестолковая формализация и рост издержек.

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



    Подробнее о чеклистах



    Мы бегло повторили эволюцию методик разработки веб-проектов (да и не только «веб») и увидели, что в настоящее время никто, как правило, не выделяет достаточно времени для формальной методичной разработки систем (однако «водопад» и матрицы зависимостей продолжают эксплуатироваться в отраслях, где цена ошибки очень высока — при строительстве домов, мостов, самолетов, при разработке ПО для здравоохранения в США и т.п.), поэтому команды выживают и борются со страхом используя ограниченный набор высокоэффективных инструментов, один из которых — чеклист.





    Чеклисты обычно составляются опытными сотрудниками, системными и бизнес-аналитиками, функциональными менеджерами. По мере накопления интеллектуального багажа компании в базах знаний, развиваются и совершенствуются и чеклисты. Суть проста — сэкономить время и деньги, не позволив сотрудникам непроизвольно (а иногда и произвольно) наступать на грабли 2 и более раз.



    Пример элементарного чеклиста для программиста:
    1. Пойми, что нужно реализовать. Если остаются вопросы, тряси аналитика/менеджера/клиента до победного конца.
    2. Подумай как это реализовать. Не торопись кодировать. Составь логическую модель данных, пару тройку диаграмм UML — отражающих как логику, так и поведение системы.
    3. Посоветуйся с ведущим разработчиком.
    4. Спроектируй таблицы базы данных. Обсуди с коллегой/рук.отдела.
    5. Подумай, как ты будешь тестировать систему.
    6. Вспомни паттерны проектирования, может что-то из них тебе пригодиться.
    7. Закодируй функционал, раньше или сразу пока помнишь напиши юнит-тесты.
    8. Юнит-тесты должны выполняться перед добавлением кода в основной репозиторий
    9. Опиши логику в вики.


    Каждый пункт — может быть ссылкой на методику в wiki.

    Ничего вроде сложного, но как часто многие из этих пунктов — игнорируются.

    А когда дело касается чеклистов по подготовке веб-проекта к нагрузочному тестированию или обслуживанию серверов… Там столько важных мелочей, которые повторяются из проекта в проект. Люди часто говорят, что помнят их — на самом деле опыт показывает, что не помнят, пропускают важные моменты и занимаются «наступанием на грабли» из проекта в проект, на одно и то же, тратя кучу времени. Не зря опытные руководители проектов закрывают этапы/релизы только при наличии оформленных ответственными сотрудниками чеклистов-отчетов: начиная от верстальщиков, заканчивая системными администраторами.

    Монитор качества — в 11 версии платформы Битрикс



    При разработке веб-проекта на коробочной платформе «1С-Битрикс: Управление сайтом» можно использовать любой из вышеперечисленных процессов. При этом снижаются следующие риски:
    1. Разработчикам не обязательно иметь «высшую степень посвящения»: сертификат ZCE и в деталях разбираться в ООП и паттернах проектирования. Все самое сложное находится в ядре платформы, разрабатывается и тестируется внутри компании Битрикс. Программисту PHP и верстальщику достаточно обладать базовыми навыками, минимальным опытом и пройти обучающие курсы (можно уложиться в несколько дней).
    2. Не нужно заниматься актуализацией документации к системе, т.к. платформа очень подробно описана в официальной документации как для клиентов, так и для разработчиков. Нужно только описать доработки/изменения функционала, выполненные при интеграции веб-проекта.
    3. Тестировщикам не нужно тестировать всё веб-решение. Платформа тщательно тестируется внутри компании. Необходимо лишь тестировать доработки/изменения функционала. Это существенно сокращает сроки и риски.


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

    Для защиты команд разработчиков от вышеперечисленных рисков в платформу с 11 версии встроен «Монитор качества».

    Для сдачи релиза веб-проекта требуется пройти процедуры автоматизированного и ручного контроля на всех этапах производства: от верстки до развертывания на хостинге или облаке и нагрузочного тестирования.



    Каждый тест может находиться в нескольких состояниях, часть тестов, особенно рутинных — автоматизирована:





    Руководитель проекта или разработчик, по сути, должен для сдачи релиза/итерации «позеленить» дерево тестов — выполнив все тесты и автотесты:



    Когда релиз сдан, это видно на рабочем столе и списке отчетов по тестированию:



    Особо хочу выделить чеклист для «продвинутых» разработчиков. Данные пункты будут особенно востребованы в Aglle/XP командах, уделяющих серьезное внимание качеству кода и архитектуре:



    Команды разработки могут добавлять свои обязательные и необязательные пункты чеклиста и автотесты, например кастомизировать проверку CodeStyle, корректность интеграции с системой контроля версий, наличию и покрытию кода UnitTests и документации в стиле PHPDocumentor:



    Факт модификации ядра и библиотек платформы также проверяется автоматизированно:



    Идеи на будущее



    Разработка, как творческий процесс, должна приносить удовольствие. Тогда и веб-проекты не будут рождаться мертвыми и страшными, и поддерживать их будет легче и интересней :-)

    Чеклисты, покрывающие весь процесс разработки на платформе Битрикс, расширяемые внутренними чеклистами команд — мы сделали. Это серьезно снизит риски, связанные с недостаточным знанием и пониманием платформы и вообще «правильных практик» и позволит командам на ретроспективах совершенствовать процесс, добавляя новые пункты в «Монитор качества».

    Многие интересные задачи, среди которых прозрачная и эффективная интеграция с распределенными системами контроля версий (Mercurial, git), поддержка средств сборки типа phing, поддержка многоступенчатых сред разработки (dev, testing, stage, production), поддержка систем непрерывной интеграции, поддержка эффективной работы географически распределенных команд — активно обсуждаются.

    Искренне надеюсь, что «Монитор качества» позволит командам раскрыть внутренний потенциал, сосредоточиться на творческом процессе разработки и совершенствовании архитектуры, станет своего рода базой знаний, полученных на ретроспективах.

    По поводу «устаканивания» в сознании выигрышной стратегии обеспечения достаточного качества сайта… Убежден, что за выделение времени на детальное проектирование и формализацию при разработке сложных и больших веб-решений (или рефакторинге/переписывании таких систем) — нужно бороться, иначе качество не обеспечишь и в производстве начнется хаос. Для средних проектов при наличии «открытого современного» Клиента хорошо подойдет Итерационная методология. Для небольших проектов отлично себя зарекомендовали Гибкие методологии. Не бойтесь экспериментировать и идти вперед. Удачи!
    1С-Битрикс
    Company

    Comments 35

      –10
      Дальше, в продолжении развития битрикс, стоит ждать статью: Мониторинг контроля за мониторингом качества битрикс проектов — превращает вашу работу в сплошное удовольствие.
      Ну и новая линейка продуктов от битрикс 12 версии: Легкое создание сайта для контроля(ссылка) за сайтом контроля создания(ссылка) сайта в битрикс-корпоративное управление качеством (ссылка)…
        –1
        почитаем…
          +5
          Контроль качества – это правильное направление развития Битрикса, чек-листы хорошая вещь и будет полезна при сдаче новых проектов.

          Обсуждаемые вами задачи, упомянутые в конце статьи, на данный момент очень актуальны для интеграторов: проекты на Битриксе все крупнее, и требуется автоматизация процесса тестирования и деплоинга. Сейчас, например, проблема проводить функциональное тестирование т.к. нет средств по развертыванию тестового окружения под запускаемые тесты. Также для нас пока вопрос по удобной организации потока работ в случае, когда разработка ведется в отдельных ветках. Тут всплывает проблемы удобного хранения проекта в системе версионного контроля (т.к. часть файлов относится к логике, часть к ядру, а часть — это данные) и накатывания обновлений, что требует механизма миграций.

          Я надеюсь, что на эти вопросы обратят внимание, т.к. без их решения сложно организовать поддержку сложных и динамично изменящихся проектов.
            0
            Спасибо. Полностью согласен.
            0
            Отличный функционал, жаль только, что не допилен до конца (специально создавал сложный пароль к бд к запятой, но монитор выдал, что «Неправильно настроены политики безопасности БД (в пароле нет знаков препинания)». И ещё много подобных мелочей.

            Самая неясный момент — это обязательность наличия модуля «Проактивная защита». Иначе монитор выдает ошибку. Получается, что ни один сайт на редакции «Старт» (где отстуствует данный модуль) не может пройти проверку собственным монитором качества. Как мне это клиенту объяснять, если он запустит тест?
              +2
              Ошибка с проверкой пароля уже исправлена.

              Что касается обязательных пунктов — их можно пропускать, если для данного проекта он не может быть выполнен в силу адекватных и обоснованных причин. В частности, про «Проактивную защиту

                0
                … Если модуль проактивной защиты не предусмотрен для вашей редакции — тест можно перевести в статус «Пропущен» — это описание к пункту. Т.е. про обязательность модуля никто не говорит.
                  –1
                  Именно.
                    0
                    Согласен. Но поставьте себя на место клиента: скорее всего он, увидев зеленькую кнопку «Зпустить автотест», запустит тест и увидит вот что: floomby.ru/content/akAbNDsESU.
                      0
                      Точка в конце к ссылке не относится.

                      Опять же к теме. Данный тест по умолчанию относится к обязательным, насколько я понял. Вам не кажется, что это по простой логике не очень правильно (не касаясь тонкостей): делать обязательный тест, который не может быть пройден?
                        +1
                        Чеклист — не приговор. Обязательность означает, что данный пункт должен быть обязательно проштудирован, но перевод его в статус «Пройден» обязателен только в случае отсутствия веских причин, которые препятствуют этому (отсутствие модуля, особенности проекта и т.д.). В итоге клиент должен видеть результат по обязательному пункту + комментарии разработчика и может с ним согласится, либо не согласиться.
                        0
                        Изначально именно Вы сдаете проект клиенту, прогоняете все пункты и формируете отчет. У Вас есть возможность комментировать ситуацию. Вся информация для клиента должна быть именно в отчете. В комментариях можно подробно описать почему тот или иной пункт не выполняется. В будущем мы подумаем как избежать этой ситуации, возможно, реализуем зависимость показа пункта от наличия модуля или других условий.
                          0
                          Ну да, надо хотя бы сделать, чтобы в редакциях, где нет модуля, чтобы этот тест был бы необязательным.
                  +1
                  Дефолтный дистриб Битрикс.Бизнес. Сразу после установки запускаю обновление системы и тест. На очередном шаге вылезает ошибка, мол модифицированы файлы ядра. При том, что файлы модифицировались самой же системой при апдейте.

                  Получается, что кроме самой разработки надо будет еще тратить время и ублажать тест системы, который не всегда адекватно показывает ситуацию.
                    +1
                    Должны были решить эту проблему в последних обновлениях. С ходу было непросто научиться определять модификацию кода ядра.
                    0
                    А какой подход использовался при разработке системы битрикс? Описанный в статье или какой-то другой?

                    Ну и мне кажется, в «идеальном» примере вы преувеличили. Чтобы сделать примитивный корпоративный сайт (что является, если не ошибаюсь, основной целью применения битрикс), никакие специалисты с 5 годам опыта (и тем более админы с 10 годами и сертификатом redhat) не нужны, тут хватит 2-3 студентов, у которых мозг присутствует на нужном месте.

                      0
                      Я постарался описать простой процесс разработки решения на платформ в разделе «Монитор качества — в 11 версии платформы Битрикс». Именно там можно обойтись без гуру.
                      0
                      У меня в редакции «Стандарт» контроль качества требует повысить уровень проактивной защиты, хотя в эту редакцию (по описанию) модуль проактивной защиты не включен. Недоработка?
                        0
                        В редакции «Стандарт» есть модуль проактивной защиты. Возможно, он у вас не установлен?
                          0
                          Ошибся в наименовании, извините. Редакция «Старт»
                        0
                        Что-то нестандартное (например, фильтр по всему каталогу товаров, от корня, случай из практики), и для решения задачи приходится отправлять патч для ядра разработчикам битрикса, ждать обновления, и после этого сдавать проект. Либо объясняя, почему у него тесты красненькие.
                          0
                          Зачем для «фильтра по всему каталогу товаров, от корня» править ядро? Ужасы какие-то рассказываете…
                            –1
                            Из обращения в техподдержку:

                            Описание задачи
                            Возможно ли осуществить вывод всех элементов инфоблока, которые находятся в корне (сам список товаров), включая те, что в подкаталогах, тоесть, по сути, все элементы инфоблока, но отфильтровнные фильтром, тоесть фильтр+список товаров.
                            Технически, нужен фильтр, в котором, введя артикул товара/название, пользователь нашёл бы все соответствия, найденные в каталоге.
                            Допустим, имеем дерево
                            корень
                            -бизнес литература
                            -художественная
                            --классики
                            --современники
                            -методическая
                            Если мы находимся в разделехудожественаня, то стандартный фильтр решает проблему, но(!) если мы находимся в корне, и хотим искать не только по разделу «художественная литература, включая подразделы», а по корневому разделу, включая все элементы во вложенных разделах, фильтр не выводится, ему невозможно задать IP каталога, потомучто корень инфоблока не имеет ID, попытка задать нулевой ID просто скрывает фильтр.
                            Обращаю внимание, что в демонстрационной виртуальной лаборатории фильтр также появляется только при входе в подкаталог, отсутствуя на главной странице. например,
                            хххх.demo.1c-bitrix.ru/e-store/books/
                            в настройках компонента явно указано, «выводить фильтр», в общем, довольно странно.
                            Вообще, задача стоит следующая: вывести фильтр, стандартный с двумя полями: название и артикул, который бы искал/фильтровал по всем разделам. Переместить все разделы в один раздел, который бы находился в корне и искать по нему мы не можем.
                            Если это возмжно, то подскажите, пожалуйста, как и в какую сторону искать.
                            Какие источники использованы при решении проблемы
                            Форум разработчиков, справка, виртуальная лаборатория.

                            Ответ:

                            Добрый день!
                            Вам необходимо либо переносить все элементы в один раздел и фильтровать по этому разделу, либо кастомизировать компонент.
                            Кастомизировать компонент предпочтительней.
                              0
                              А что сложного кастомизировать или написать компонент с нуля на базе гибкого АПИ ядра инфоблоков? В ядро лезть разумеется не нужно.
                                0
                                Часть битрикса менять нежелательно, ибо перестанут корректно работать обновления.
                                Я же не шаблон меняю и не через API данные доставать предлагаю.
                                Вы правы в том, что речь идёт не о ядре. Но речь идёт о получении данных низкоуровневыми методами, через SQL или выше уровнем, и тут либо тест покажет красную лампочку, либо обновления не будут работать (при сменене структуры) даже при зелёной лампочке.
                                  0
                                  В итоге тогда получали список ID директорий в корне, получали данные через APIC и потом их склеивали до передачи шаблону, всё это без кастомизации.
                                  Можете представить, сколько там было N+1, где N-количество директорий в корне, и какова была производительность.
                                  0
                                  Вот так и рождаются небылицы…

                                  RTFM!

                                  «Компоненты являются блоками, с помощью которых строится публичная часть сайта. Они в полной мере реализуют паттерн проектирования Carrier Rider Mapper. „
                                  dev.1c-bitrix.ru/api_help/main/general/component20/01.components.php

                                  “Ядро системы состоит из функций, событий и следующих классов»
                                  dev.1c-bitrix.ru/api_help/main/reference/index.php
                                    0
                                    Ок.
                                    Изменю компонент интернет-магазина на уровне модели (т.е. при получении данных, ибо АПИ привязано к директории), думаете, при обновлении ничего не отвалится?
                                      0
                                      Я компоненты рассматриваю как примеры работы с АПИ. Если вы можете использовать АПИ ядра более эффективно или нужна гибкость — всегда пишутся свои компоненты допустим со строгим ООП, юнит-тестами и т.д. При обновлении гарантируется полная обратная совместимость ядра по АПИ между версиями Битрикс.
                                0
                                Зато сколько понту «патч для ядра разработчикам битрикса» он отправил… и эту чушь порет «Старожил» хабра…
                                  0
                                  Я НЕ отправиил никакого патча. Речь идёт о том, как НАДО поступать для зелёного теста. Внимательнее.
                                  Ну, тогда перейдём к конкретике. В битриксе фильтр прикручивается к любой директории, включая вложенные. В корне каталога — несколько директорий. Как сделать фильтр по каталогу (даже в демо-сайте этой элементарной штуки нет, в АПИ для привязки фильтра я обязан указывать директорию (её ID))? ID передаётся из GET, можно указать вручную или найти и потом указать. Не указывать ID директории нельзя.
                                  Айда писать компонент каталога интернет-магазина и компонент фильтра (а это таблица, дерево с ценами, картинками, кнпокой купить и т.д.).
                                  Патчи отправляют конторы, которые пишут на битриксе что-то серьёзное.
                                  Кастомизировать компонент — переписывать какой-либо кусок самого битрикса, не контроллера и не лаунчера (функция с массивом параметров), и не шаблона. При этом забивая на возможность обновления компонента интернет-магазина.
                                    0
                                    Я не бесплатная ТП помогать вам тут, тем более после вашего первого сообщения. Скажу только что это элементарно. RTFM.
                                      0
                                      Я и не прошу, тут не форум, где клянчут сделать за них, да это всё в прошлом, сейчас MVC фреймворки (т.е. вообще не CMS). Пример то давний.
                                      Элементарно — это когда фильтр по всему каталогу интернет-магазина есть из коробки.
                                      RTFM подразумевает указывать DirectoryID, которого нет и быть не может.
                                      На этом предлагаю дискуссию считать оконченной.
                                        0
                                        Думаю, что ваша проблема решилась бы если бы в параметре идентификатора категории вписали '0', но если сильно хочется «писать компонент каталога интернет-магазина и компонент фильтра (а это таблица, дерево с ценами, картинками, кнпокой купить и т.д.)»
                                        — кто же вам запретит…
                                          0
                                          Не, это я тоже пробовал, ошибка была, кажется, ненайденной директории с таким ID. Не суть важно.
                                          Возможно, в новом битриксе и продумали, это всё таки не вчера было.
                                          Да и решили тогда проблему, через тот же API, выше я отписал, как, пусть и запросов было много.

                              Only users with full accounts can post comments. Log in, please.