| name | bitrix-analyst |
| description | Анализ и архитектура задач под 1С-Битрикс (сайт/интернет-магазин): разбор задачи, определение где искать функционал (какой модуль ядра — main/iblock/catalog/sale/highloadblock, старое ядро vs D7, компонент vs API), оценка влияния доработки (что затронет, где уже реализовано), подготовка ЧТЗ (ожидаемое поведение + модель данных + критерии приёмки) и архитектурных решений. ОБЯЗАТЕЛЬНО используй, когда анализируешь/уточняешь задачу по Битрикс, определяешь модуль и слой (/local vs ядро), оцениваешь влияние изменения, готовишь/проверяешь ЧТЗ, формулируешь уточняющие вопросы или проектируешь на уровне архитектуры (не написания PHP). Срабатывай даже без слова «анализ», если речь о понимании задачи, влиянии или подготовке требований. Правило: искать в ОБОИХ слоях (ядро + /local) и проверять по РЕАЛЬНОМУ коду, не по памяти. Написание кода — bitrix-dev; производительность — bitrix-performance.
|
Анализ и архитектура под 1С-Битрикс
Читать при проектировании (обязательно)
references/design-method.md — конвейер: требования (поведение) → критерии приёмки Given/When/Then →
impact-чеклист под Битрикс → дерево выбора точки расширения (result_modifier → событие → свой компонент →
копия → модуль → НИКОГДА ядро) → ADR → план миграции с откатом.references/adr-template.md — формат архитектурного решения (контекст с замерами, альтернативы, последствия,
план миграции, техдолг).- Глубина решения (когда НЕ усложнять) и слои —
../bitrix-dev/references/architecture.md.
Правило: спроси инструмент, не угадывай
Прежде чем делать вывод об архитектуре/влиянии — проверь по реальному коду (Grep/Serena по ядру и /local) и справке
dev.1c-bitrix.ru. Не делай вывод об отсутствии функционала по непросмотренному слою.
Где искать функционал (карта ядра)
- main — ядро D7: ORM, события, приложение, кэш, сервис-локатор, HTTP, работа с файлами.
- iblock — инфоблоки (контент, каталог-сущности), свойства, разделы.
- catalog — торговый каталог: цены, склады, торговые предложения (SKU), единицы измерения.
- sale — магазин: корзина, заказы, оплата, доставка, скидки, правила корзины.
- highloadblock — highload-справочники (большие объёмы, D7 ORM).
- Компонент vs API: UI-логика (вывод) — в компонентах/шаблонах; бизнес-логика — в своих сервисах/классах
/local поверх API ядра.
Слои — искать в ОБОИХ
Функционал может быть в ядре (/bitrix/modules) ИЛИ переопределён в /local. Приоритет /local → /bitrix.
Правки планируй только в /local; структуру инфоблоков/HL — миграциями.
ЧТЗ = поведение, не реализация
Хорошее ЧТЗ: (1) ожидаемое поведение (сценарии: что видит пользователь/админ, крайние случаи), (2) модель данных
(какие инфоблоки/свойства/HL/сущности затронуты), (3) критерии приёмки (проверяемые условия готовности).
Реализацию (какие классы/компоненты) фиксируй отдельно — тех-решение.
Оценка влияния доработки
- Какие модули/компоненты/шаблоны затронет; есть ли типовой компонент, который проще скопировать в
/local, чем писать с нуля.
- Влияние на производительность (кэш, запросы, объёмы) — при сомнении подключай
bitrix-performance.
- Обновляемость: не ломает ли правка обновление продукта (правки только в
/local).
- Совместимость версий ядра: доступен ли нужный метод D7 в версии проекта (проверяй по реальному коду ядра).
Уточняющие вопросы (/clarify)
Прежде чем проектировать — уточни неоднозначное: объём данных (влияет на архитектуру каталога), требования к
персонализации (влияет на кэш/композит), интеграции (1С, платёжки, CRM), нагрузку, сроки.
