Как пройти монитор качества битрикс

Обновлено: 25.01.2025

3. Настройки компонентов - отделены и описаны . При чем выполнены рекомендации - во все кастомные компоненты внесен файл описнаия этого компонента.

в описании Рекомендаций вот что

В собственных компонентах используется управляемое кеширование в режиме "Авто+Управляемое" с установкой длительного периода кеширования (1-12 месяцев) или "Авто" кеширование.
Как тестировать

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

Все дело в производительности веб-проекта при одновременной работе с ним множества пользователей. Если компонент 2.0 отрабатывает без кеширования за 0.1 сек, выполняя, допустим, 100 запросов к базе данных, то, при одновременной работе 100 пользователей не только резко возрастет нагрузка на сервер базы данных, но и время отработки компонента может вырасти, к примеру, до 5-10 секунд!

Не менее важный момент, на который стоит обратить внимание - скорость отработки компонента при получении данных из кеша. Если без кеширования компонент отрабатывает за 2 сек. для каждого пользователя, то при использовании кеширования компонент для одного пользователя отработает за 2 сек., а для остальных 100 пользователей в ближайшие полчаса, допустим, будет отрабатывать 0.1 сек.

На какой период времени кешировать информацию в собственных компонентах 2.0? Если используется "Авто+Управляемое" кеширование - информация будет отдаваться из кеша до тех пор, пока она не поменяется в базе данных и кеш сбросится автоматически. Если используется "Авто" кеширование - рекомендуется устанавливать максимально допустимый с учетом бизнес-логики интервал кеширования. Например, для редко обновляемого "списка статей" можно установить интервал кеширования в 12 часов, а для часто обновляемого - 10 минут.

Таким образом, при использовании кеширования в собственных компонентах 2.0:

резко увеличивается производительность веб-проекта и его устойчивость к нагрузкам, т.к. нагрузка на базу данных качественно минимизируется и веб-решение сможет обслужить уже, к примеру, не 50 000 пользователей в сутки, а 1 000 000 и больше.
веб-страницы загружаются в браузер пользователя значительно быстрее (десятые доли секунды), т.к. информация для их построения сохранена на сервере и не берется из базы данных

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

Обычно настройки расположены в разделе "Настройки кеширования" и называются "Тип кеширования" и "Время кеширования (сек.)". Тип кеширования должен быть установлен в "Авто+Управляемое" или "Авто". Если тип установлен в значение "Кешировать" - рекомендуется для удобства администрирования системы поменять его на "Авто".

В административной части в разделе "Настройки > Настройки продукта > Автокеширование" на вкладке "Кеширование компонентов" должно быть включено автокеширование, а на вкладке "Управляемый кеш" должно быть включено управляемое кеширование (в большинстве типовых веб-проектов его рекомендуется не выключать).

Время кеширования для режима "Авто+Управляемое" - должно быть большим, к примеру, 1 год. Время кеширования для режима "Авто" зависит от частоты обновления информации - для некоторых компонентов 2.0 устанавливается период в 24 часа, а для часто обновляемых либо рекомендуется использовать управляемое кеширование или установить значение, к примеру, в 10 минут.
но файл описания в кастомные компоненты уже помещены!

Цитатник веб-разработчиков В тексте курса вы встретите цитаты, высказанные в разное время разработчиками системы и разработчиками проектов на базе Bitrix Framework. Надеемся, что такие неформальные замечания внесут некоторое разнообразие в процесс изучения. Заодно опытные специалисты поделятся и своим опытом.

Имена авторов цитат даются в том написании, в каком авторы зарегистрировали себя на сайте "1С-Битрикс". .

Курс для разработчиков - продолжение линейки учебных курсов по Bitrix Framework. Получение сертификата по курсу рекомендуется после успешной сдачи тестов по всей линейке курсов, так как без понятия о работе Контент-менеджера и Администратора создание успешных сайтов будет затруднено.

Чтобы научиться программировать в Bitrix Framework, нет необходимости изучать всю линейку курсов. Но есть моменты, которые необходимо знать разработчикам о системе, они раскрыты в начальных курсах:

Интерфейс программы - в главе Элементы управления курса Контент-менеджер.
Компоненты 2.0 (начальные сведения) в главе Компоненты 2.0 (начальные сведения) курса Контент-менеджер.
Информационные блоки - в главе Информационные блоки (начальные сведения) курса Контент-менеджер.
Управление доступом к файлам, элементам контента, модулям и другие права доступа в главе Управление доступом курса Администратор. Базовый.
Работа с инструментами системы - в главе Работа с инструментами курса Администратор. Базовый.
Модуль Поиск - в главе Поиск курса Администратор. Базовый.
Вся информация по администрированию модулей размещена в курсах:
Как построен курс

Общепринятая градация квалификации разработчиков в рамках курса обозначает что:
- Junior сможет создавать простые сайты работая со штатными компонентами и модифицируя их шаблоны.
- Middle разработчик может работать с API Bitrix Framework.
- Senior умеет работать над производительностью и безопасностью сайтов, создавать свои модули и компоненты.
Примечание: Такое построение удобно для пошагового изучения принципов работы Bitrix Framework. По этому же принципу построены и тесты. Но такая структура не очень удобна для использования содержания курса как постоянного источника информации. Что бы переключить курс в режим Справочника, воспользуйтесь переключателем в верхнем правом углу шапки курса.
Начальные требования к подготовке

Для успешного изучения курса и овладения мастерством разработки сайтов на Bitrix Framework необходимо владеть (хотя бы на начальном уровне):
- основами PHP, баз данных;
- основами HTML, CSS.
У нас часто спрашивают, сколько нужно заплатить

Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов - ничего из этого оплачивать не нужно.

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат - это если общее число набранных Вами баллов отличается от максимального на 1-2%.

Тесты

После изучения курса вам будет предложено пройти тесты на сертификацию. При успешной сдаче последовательности тестов на странице Моё обучение можно просмотреть результат обучения и загрузить сертификат в формате PDF.

Комментарии к статьям

Что дальше?

Одновременно с изучением курса Разработчик Bitrix Framework вам придётся обращаться к информации о других технологиях Bitrix Framework. Эта информация размещена в следующих курсах:

Для преподавания оффлайн

Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 5 дней (40 академических часов).

Если нет интернета

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса.

Сегодня поговорим о причинах, побуждающих создавать и внедрять методики и инструменты обеспечения качества, заглянем в историю проблемы, осветим известные риски и постараемся «устаканить» в сознании выигрышную стратегию обеспечения достаточного качества веб-решения. В заключении я расскажу о новом инструменте в 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. Релиз веб-проекта быстро вводится в эксплуатацию. Посетители быстро тестируют решение и оно за короткий срок переходит из beta в адекватное требованиям состояние.
2. На всех этапах производства используется чеклисты. Суть проста — некогда писать и читать многостраничные руководства, чтобы «выжить», нужно выполнить данные пункты не задавая лишних вопросов. Прямая аналогия с боевым уставом.
Очевидно, что т.к. такой процесс разработки балансирует на грани «управляемого хаоса», а иначе работать часто не позволяет рынок, значимую роль в обеспечении порядка и предсказуемости принадлежит максимальной автоматизации тестирования, дополняемой контрольными списками (чеклистами). Система должна уметь проверять сама себя и быстро выявлять критичные ошибки — а также мы должны знать что и где нужно быстро проконтролировать (если это сложно автоматизировать) на разных этапах производства: от верстки до эксплуатации под нагрузкой.
1. За 2-3 недели проектируется и выпускается новый релиз веб-решения
2. Анализируется опыт итерации(ий) и вносятся улучшения в чеклисты разных этапов производства
3. Часть костылей, поставленных в предыдущих итерациях — переписывается
4. Новые модули системы покрываются сеткой модульных и функциональных тестов
Со временем, процесс развития веб-проекта стабилизируется, вносить изменения становится «не так страшно» — их ждут, система постоянно обновляется, улучшается, относительно здорова не только снаружи, но и внутри. Наступает фаза «эффективного мира», которую остается блюсти — т.к. любой перекос может сбросить производство либо в хаос либо начнется бестолковая формализация и рост издержек.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Монитор качества: Ядро проекта не модифицировалось

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

Сначала посмотрим какие файлы система считает модифицированными. Для этого заходим в "Монитор качества", открываем тест "Ядро проекта не модифицировалось"

Открываем подробный отчет.

Вот варианты, которые мне помогали решать проблему с данным тестом:

1) Если у Вас установлена не последняя версия Битрикса, обновите ее стандартными средствами. "Marketplace" - "Обновление платформы" - "Установить рекомендуемые обновления". Так как проверка идет с эталонными файлами системы последней версии.

2) Перезакачать все установленные модули. Для этого мы находясь на странице "Marketolace" - "Обновление платформы" в адресную строку добавляем "BX_SUPPORT_MODE=Y", чтобы получилось "ваш_сайт/bitrix/admin/update_system.php?BX_SUPPORT_MODE=Y" и нажимаете "Перезагрузить все файлы".

3) Если не помогли два выше указанных способа, остается поставить демонстрационную версию Битрикса той же редакции, что и Ваш сайт. При установке выбираем типовой вариант сайта, а не варианты сайтов из Marketplace и проверяем после установки, проходит ли демоверсия тест. Если проходит, то можно оттуда взять не модифицированные файлы, тем более где они лежат вы уже знаете из подробного отчета.

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

Один из вариантов Вам поможет, главное сами специально не исправляйте служебные файлы.

Читайте также: