Новая документация Bitrix Framework: тихая революция, которую мы ждали

Что изменилось: видно движение и виден темп

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

Вот небольшой фрагмент обновлений за начало 2026 года:

• 13 января — новые материалы и крупное обновление контроллеров.
• 29 января — сразу несколько существенных дополнений (инфоблоки, команды консоли, контроллеры, валидация, 2FA).
• 5–10 февраля — серия обновлений и новые статьи (включая гайд для контрибьюторов).

Этот ритм говорит о многом. Документацию перестали воспринимать как статичную «энциклопедию на годы». Ее начали развивать как продукт: маленькими, понятными инкрементами.

И это первый признак того, что экосистема перестает жить «как получится» и начинает перенимать практики больших фреймворков вроде Laravel и Symfony: регулярные обновления, примеры, правила оформления.

Почему отсутствие «громких релизов» — это нормально

У Битрикса много лет нет громких релизов по БУС. Большинство проектов живет не в режиме «обновились — переписали половину приложения», а в режиме «поддерживаем, развиваем, не ломаем».

Поэтому рост документации — это и есть тот самый «глобальный релиз», просто без фанфар:

1. Фокус на инженерии, а не на презентациях. Уточняют детали, добавляют примеры, закрывают пробелы.
2. Сдвиг к нормальной коммуникации с сообществом. Есть Issues, Pull Requests, публичные изменения, отдельная инструкция для контрибьюторов.
3. Нормализация D7-мышления. Документация постепенно формирует «правильный центр тяжести»: не вокруг магии ядра, а вокруг подходов, которые позволяют строить поддерживаемые системы.

Тут важно подчеркнуть: это не «новая дока ради доки». Это попытка наконец договориться об общем языке, чтобы в 2026 году обсуждать решения, а не гадать, «как оно там на самом деле устроено».

Что мне нравится особенно: Documentation as Code и открытый процесс

Репозиторий документации построен по подходу Documentation as Code: Markdown, контроль версий, прозрачные правки. Для нас это не «деталь». Это фундамент.

Почему?

• Прозрачность. Видно, что добавили, когда и почему.
• Возможность влиять. Ошибку можно не только заметить, но и исправить.
• Нормальные правила. Есть единые требования к примерам кода и оформлению, чтобы дока не превращалась в свалку стилей.

Это переход от модели «документация — это где-то там» к модели «документация — это часть экосистемы».

Но есть и проблема: «как пользоваться» есть, а «как проектировать» часто нет

Официальная документация закономерно объясняет что существует и как этим пользоваться: контроллеры, роутинг, Service Locator, консольные команды, новые статьи по отдельным подсистемам.

Но разработчику на реальном проекте не хватает другого слоя:

• Как принять архитектурное решение, когда проект гибридный (старое ядро + D7)?
• Как изолировать легаси так, чтобы оно не заражало новые части системы?
• Где границы ответственности: сервисы, репозитории, DTO, обработчики событий, компоненты?
• Как строить контракты и окружение, чтобы команда не скатывалась в «правку файлов»?

Это не претензия к документации. Это нормально: официальный источник редко уходит в «почему так» и «как думать», потому что это уже территория инженерной практики, компромиссов и контекста.

Именно поэтому BXMax будет еще сильнее смещаться в сторону:

• объяснения архитектурных процессов,
• разборов типичных ошибок и анти-паттернов,
• перевода «модульных возможностей» в «понятные сценарии проектирования».

Если в официальной доке написано недостаточно полно — я буду стараться дополнять это практикой: понятными схемами, примерами и словами, которые можно принести в команду.

Как я собираюсь помогать документации

Вторая важная мысль: если документация стала живой — с ней можно работать как с живым продуктом. И я хочу участвовать в этом активнее.

Мой план простой:

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

Если вы тоже хотите помочь — это стало реально удобным: Issues и Pull Requests, плюс отдельные правила для контрибьюторов. Это важный шаг: документация перестает быть монологом.